| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-10-22 | |||
| 09:07:27 | zigo | raise SafetyCheckFailed(failures) | |
| 09:07:29 | zigo | oslo_utils.imageutils.format_inspector.SafetyCheckFailed: Safety checks failed: mbr | |
| 09:07:31 | zigo | Is this known, and should I backport some patches? | |
| 09:08:30 | zigo | https://review.opendev.org/c/openstack/oslo.utils/+/928448 maybe ? | |
| 09:50:37 | zigo | This doesn't fix my issue ... :/ | |
| 09:51:30 | sean-k-mooney | zigo: i think there is a glance config option related to funky mbrs | |
| 09:51:56 | zigo | sean-k-mooney: The issue for me is in nova-compute. | |
| 09:52:04 | zigo | When it spawns the VM. | |
| 09:52:19 | sean-k-mooney | oh ok | |
| 09:52:40 | sean-k-mooney | is that the full traceback | |
| 09:52:53 | zigo | Nope. | |
| 09:53:22 | zigo | https://paste.opendev.org/show/bwgoYQ6LeWlUFYcIZ998/ | |
| 09:53:30 | zigo | That's what I have in "server show" | |
| 09:55:24 | sean-k-mooney | ah, and form that i tatke it the image is in raw? format based on the call to fetch_to_raw | |
| 09:56:01 | zigo | Correct. The image is an upload from another cloud's /var/lib/nova/instance/<uuid>/disk | |
| 09:56:52 | zigo | Will it go nicer if I convert to Qcow2 first? | |
| 09:57:47 | sean-k-mooney | it would work in either case | |
| 09:58:10 | sean-k-mooney | i suspect its failing somehwere here https://github.com/openstack/oslo.utils/blob/master/oslo_utils/imageutils/format_inspector.py#L1388-L1421 | |
| 09:58:29 | sean-k-mooney | however i woudl expect a more verbose excetion message in that case | |
| 09:59:20 | zigo | The image is, as much as I can tell, made from the Debian one, with grub-cloud, dual boot (ie: UEFI + mbr). | |
| 09:59:49 | zigo | At least it looks like it, I didn't check much, but it has all of the usual partitionning. | |
| 10:03:40 | sean-k-mooney | is it publicly aviable or would you beable to provide say the first 1mb of the image which has the format info so we coudl inspect it | |
| 10:04:08 | zigo | I'll investigate myself first. It's not a public image, it's customer's data. | |
| 10:04:09 | sean-k-mooney | we dont actully need the full image all the gpu info is in the first few KBs | |
| 10:04:14 | sean-k-mooney | ack | |
| 10:05:07 | sean-k-mooney | on master we provided a cli that you can use to run the inspector https://github.com/openstack/oslo.utils/blob/master/oslo_utils/imageutils/cli.py | |
| 10:05:45 | sean-k-mooney | so you can do python -m oslo_utils.imageutils -i /path/to/image [-v|--verbose] | |
| 10:05:48 | zigo | Ah, nice ! :) I can try it in my Flamingo virtualized test cluster then. | |
| 10:06:07 | sean-k-mooney | its in epoxy too | |
| 10:06:21 | sean-k-mooney | just not 2024.2 | |
| 10:06:39 | sean-k-mooney | https://github.com/openstack/oslo.utils/blob/stable/2025.1/oslo_utils/imageutils/cli.py | |
| 10:07:29 | zigo | It's a shame there's no script entry point then. | |
| 10:07:31 | sean-k-mooney | the master just has type hints | |
| 10:08:20 | sean-k-mooney | well there is a __main__.py for the module | |
| 10:08:35 | zigo | Yeah, but something in /usr/bin would have been much nicer. | |
| 10:08:37 | sean-k-mooney | but you can basiclly just copy paste it somehwere and run it with the older version of oslo | |
| 10:08:44 | zigo | I'll see if I can push such patch ! :) | |
| 10:09:06 | zigo | Oh, I see. Ok, thanks. | |
| 10:09:07 | sean-k-mooney | i think we did that to not pullute /usr/bin with a debug helper | |
| 10:09:34 | sean-k-mooney | but i dont really have a strong opionion either way | |
| 10:10:29 | sean-k-mooney | if we wanted it to be a cli in /bin all that really needed is addting the console_scripts entry point ot setup.cfg to point at the cli module | |
| 10:11:12 | sean-k-mooney | although on master yo uwoudl now do that via pyproject.toml i think | |
| 10:12:10 | zigo | python3 -m oslo_utils.imageutils -i /path/to/disk <--- Shows nothing, just exists. This means validated in Flamingo ? | |
| 10:13:08 | sean-k-mooney | zigo: anyway my hunch is the mbr is subtlly invalid and not fully complient with the gpt spec | |
| 10:13:19 | sean-k-mooney | am thatm mean our error handleing sucks :) | |
| 10:13:25 | sean-k-mooney | try adding -v | |
| 10:13:53 | zigo | # python3 -m oslo_utils.imageutils -v -i /path/to/disk | |
| 10:13:53 | zigo | SAFETY_CHECK_PASSED=False | |
| 10:13:53 | zigo | VIRTUAL_SIZE=262144 | |
| 10:13:53 | zigo | ACTUAL_SIZE=262144 | |
| 10:13:55 | zigo | IMAGE_FORMAT="gpt" | |
| 10:13:57 | zigo | OSLO_UTILS_VERSION="9.1.0" | |
| 10:14:00 | zigo | FAILURE_REASONS='mbr: GPT MBR has invalid start CHS' | |
| 10:14:14 | sean-k-mooney | there you go | |
| 10:14:23 | zigo | Great, that was very helpful sean! | |
| 10:14:26 | sean-k-mooney | lookign at the code it exits 0 on success and 1 on failure by default | |
| 10:15:09 | sean-k-mooney | so that is form here https://github.com/openstack/oslo.utils/blob/stable/2025.2/oslo_utils/imageutils/format_inspector.py#L1267-L1270 | |
| 10:19:05 | sean-k-mooney | so that path means that the os type is 0xEE a protective MBR https://uefi.org/specs/UEFI/2.10/05_GUID_Partition_Table_Format.html#os-types | |
| 10:25:15 | sean-k-mooney | the check that is failign is "(starth, starts, startt) != (0x00, 0x02, 0x00):" thats StartHead StartSector and StartTrack | |
| 10:25:47 | sean-k-mooney | https://uefi.org/specs/UEFI/2.10/05_GUID_Partition_Table_Format.html#protective-mbr-partition-record-protecting-the-entire-disk | |
| 10:26:09 | sean-k-mooney | StartingCHS is 3 bytes Set to 0x000200, corresponding to the Starting LBA field. | |
| 10:42:31 | zigo | I probably will propose a patch to accept more valid values. | |
| 10:43:33 | opendevreview | Stephen Finucane proposed openstack/nova master: db: Remove legacy placement tables from API DB https://review.opendev.org/c/openstack/nova/+/889086 | |
| 10:43:34 | opendevreview | Stephen Finucane proposed openstack/nova master: db: Remove legacy tables from main DB https://review.opendev.org/c/openstack/nova/+/889087 | |
| 10:43:34 | opendevreview | Stephen Finucane proposed openstack/nova master: db: Remove legacy columns from main DB https://review.opendev.org/c/openstack/nova/+/889088 | |
| 10:49:12 | opendevreview | Stephen Finucane proposed openstack/nova master: Remove unused 'shutdown_terminate' flag https://review.opendev.org/c/openstack/nova/+/773156 | |
| 10:49:47 | zigo | stephenfin: Gosh, thanks for the placement db cleanup. It's not like if it was a 5 years old technical dept ... :/ | |
| 10:58:14 | opendevreview | Stephen Finucane proposed openstack/nova master: objects: Remove custom comparison methods https://review.opendev.org/c/openstack/nova/+/472285 | |
| 11:05:14 | sean-k-mooney | zigo: that is unlikely to be accpeted as there arent more _valid_ vlaues | |
| 11:05:43 | zigo | There sure is! | |
| 11:05:52 | zigo | https://uefi.org/specs/UEFI/2.10/05_GUID_Partition_Table_Format.html | |
| 11:05:55 | sean-k-mooney | if the os type is declared as 0xEE then it must be that value or its not a valid GPT partion table acrodign to the spec | |
| 11:05:56 | zigo | Search for CHS. | |
| 11:06:25 | sean-k-mooney | no the other value are only valid if the mbr is a legacy mbr not a protective mbr | |
| 11:06:50 | zigo | In the case of "Protective MBR Partition Record" their are some other valid values. | |
| 11:07:17 | zigo | Right, but then why would OpenStack prevent using "Protective MBR" ? | |
| 11:07:37 | sean-k-mooney | we dont protective mbr requeis it to be exactly 0x000200 | |
| 11:08:16 | zigo | My image is perfectly valid and has 0x00, 0xee, 0xfe | |
| 11:08:33 | zigo | (starth, starts, startt) | |
| 11:08:38 | sean-k-mooney | legacy mbr allows other value but you cant mix thet 2 | |
| 11:09:17 | zigo | I believe the Debian image is mixing them to allow both MBR *AND* uefi. | |
| 11:09:32 | sean-k-mooney | this is somtihng that is often done incorectly when trying to create a image that is both bootable as uefi and bios | |
| 11:09:57 | zigo | This is maybe incorrect, but existing in the wild at least. | |
| 11:10:19 | sean-k-mooney | yep we have encounedre that in other cases too. | |
| 11:10:28 | sean-k-mooney | those are not techinially allowed by the gpt spec | |
| 11:10:33 | sean-k-mooney | there is a way to do it | |
| 11:10:44 | sean-k-mooney | but its often not done correctly | |
| 11:11:05 | sean-k-mooney | we had this dicussion with at leat one other disto | |
| 11:11:13 | zigo | Ok, but then, what our format_inspector is trying ot acheive is *not* checking if some images aren't respecting the GPT specs. We're trying to check if nova/cinder/glance is being hacked... | |
| 11:12:12 | zigo | I wouldn't mind fixing the Debian if it's broken, that's probably the case, but that wont fix the "I cannot migrate my VMs from my old cloud" use case... | |
| 11:12:31 | zigo | (and that's what I'm currently trying to fix) | |
| 11:12:32 | sean-k-mooney | we are tryign to require "valid" boot image and currently that includes a valid GPT partion table | |
| 11:12:51 | sean-k-mooney | let me see if i can find the perio bug | |
| 11:13:00 | sean-k-mooney | i have forgotten much of the context ath this point | |
| 11:13:30 | zigo | Right. We aren't trying to prevent border-line wrongly not respecting the spec images. | |
| 11:13:49 | zigo | Just something that Qemu can boot safely. | |
| 11:14:38 | zigo | It'd be ok to be more respecting the spec if we were writing a spec validation tool for qemu, but that's not our goal ... | |
| 11:14:47 | sean-k-mooney | https://bugs.launchpad.net/oslo.utils/+bug/2091114 | |
| 11:15:03 | zigo | Thanks, reading. | |
| 14:36:01 | Uggla | Does someone knows about https://review.opendev.org/c/openstack/nova-specs/+/964444 ? I mean do we have the owners of this patch around ? | |