)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"fe2365975a7c4cf89007092ff09a314bb67637e5","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"b4277f3f_eaec7be3","updated":"2025-10-22 12:30:25.000000000","message":"if this is garded by a cofnig option it might be fine.\nbut i dont belive these iamges technially have valid GPT headers","commit_id":"cebceb85cbecf214c06fbffb8faf73219560c9bc"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"cd9c638fc6935324a2ad4cd2fdd3dffbcc2a6c80","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"2bd393e5_de6a22ea","in_reply_to":"b4277f3f_eaec7be3","updated":"2025-10-22 14:25:43.000000000","message":"I don\u0027t think conf knobs for oslo_utils are a thing (for good reason). In glance we have the ability to disable specific checks (which is why they are designed modularly here):\n\nhttps://github.com/openstack/glance/blob/master/glance/common/config.py#L123\n\nTo me, that\u0027s the only CONF-based skipping I think makes sense, but I also think (as it says in the doc text there) that doing this is a bad idea. Glance is just a holder of those things, but nova is the one that stands to be the main attack surface for something so I would think we\u0027d need to have a conversation about whether we want to even add that skipping functionality to it.\n\nAFAICT, the invalid CHS values in the debian images are just \"it\u0027s always been that way\" and not for any specific compatibility reason right? From the IRC discussion it seems like there\u0027s acknowledgement that Debian images are wrong and need to be (/will be) fixed. If so, I think this is working as designed - filtering out images that are invalid. The other flatcar bug about this has a workaround procedure to fix images. Removing checks from a security layer because Debian\u0027s images have been wrong for a long time is not a good plan, IMHO.","commit_id":"cebceb85cbecf214c06fbffb8faf73219560c9bc"}],"oslo_utils/imageutils/format_inspector.py":[{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"fe2365975a7c4cf89007092ff09a314bb67637e5","unresolved":true,"context_lines":[{"line_number":1413,"context_line":"                found_gpt \u003d True"},{"line_number":1414,"context_line":"                acceptable_chs_starts \u003d ["},{"line_number":1415,"context_line":"                    (0x00, 0x02, 0x00), # Standard/Conventional"},{"line_number":1416,"context_line":"                    (0x00, 0xee, 0xfe), # Common compatibility CHS"},{"line_number":1417,"context_line":"                    (0xfe, 0xff, 0xff), # Another common \"max\" CHS address"},{"line_number":1418,"context_line":"                ]"},{"line_number":1419,"context_line":"                if (starth, starts, startt) not in acceptable_chs_starts:"},{"line_number":1420,"context_line":"                    actual_chs \u003d (starth, starts, startt)"}],"source_content_type":"text/x-python","patch_set":2,"id":"82cc515d_a21fa273","line":1417,"range":{"start_line":1416,"start_character":0,"end_line":1417,"end_character":74},"updated":"2025-10-22 12:30:25.000000000","message":"as far as i am aware these are only valid with the legacy mbr type for non uefi booting which woudl use ostype 0xEF not 0xEE\n\ni dont see anything in \nhttps://uefi.org/specs/UEFI/2.10/05_GUID_Partition_Table_Format.html\nthat defiens these other values as valid.\n\ncan you site where that is teh case.\notherwise i think usign the non standared values likely shoudl be beind a config option to allow relaxed checking\n\nthis is related to https://bugs.launchpad.net/oslo.utils/+bug/2091114 as well however its a slghtly diffent nonconformity.\n\neven looking at teh 2.11 revision fo the spec relased in december\nhttps://uefi.org/specs/UEFI/2.11/05_GUID_Partition_Table_Format.html\ni do not see an indication of the validity of these other values.\n\nhttps://uefi.org/specs/UEFI/2.11/05_GUID_Partition_Table_Format.html#protective-mbr-partition-record-protecting-the-entire-disk which is the defintion of the head for protective mbr 0xEE still states it must be Set to 0x000200\n\ni belive the image that you are comparing is using a legacy mbr with the protective mbr ostype which si not valid\nhttps://uefi.org/specs/UEFI/2.11/05_GUID_Partition_Table_Format.html#lba-0-format\nrequires that we use one or the other format.","commit_id":"cebceb85cbecf214c06fbffb8faf73219560c9bc"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"cd9c638fc6935324a2ad4cd2fdd3dffbcc2a6c80","unresolved":true,"context_lines":[{"line_number":1413,"context_line":"                found_gpt \u003d True"},{"line_number":1414,"context_line":"                acceptable_chs_starts \u003d ["},{"line_number":1415,"context_line":"                    (0x00, 0x02, 0x00), # Standard/Conventional"},{"line_number":1416,"context_line":"                    (0x00, 0xee, 0xfe), # Common compatibility CHS"},{"line_number":1417,"context_line":"                    (0xfe, 0xff, 0xff), # Another common \"max\" CHS address"},{"line_number":1418,"context_line":"                ]"},{"line_number":1419,"context_line":"                if (starth, starts, startt) not in acceptable_chs_starts:"},{"line_number":1420,"context_line":"                    actual_chs \u003d (starth, starts, startt)"}],"source_content_type":"text/x-python","patch_set":2,"id":"d6913674_5c2b69d8","line":1417,"range":{"start_line":1416,"start_character":0,"end_line":1417,"end_character":74},"in_reply_to":"82cc515d_a21fa273","updated":"2025-10-22 14:25:43.000000000","message":"Agree, going down this path means we might as well just allow anything here because \"meh I found this one in the wild too\" could apply to literally anything.\n\nIt doesn\u0027t match the spec, we\u0027re checking for the spec.","commit_id":"cebceb85cbecf214c06fbffb8faf73219560c9bc"}]}