Problem with 8.7 cloud image

Rocky Linux Help & Support
1

I’ve recently noticed a problem since the release of 8.7 and hoping someone can help point me in the right direction. I have a job that uses the openstack/diskimage-builder project to help build updated customized qcow2 images periodically, based on the image
Rocky-8-GenericCloud.latest.x86_64.qcow2

Something significant seems to have changed with that image between 8.6 and 8.7. The original 8.6 image size was ~2.67 GB, while the 8.7 version of the same image is ~1.66 GB. The size difference is pretty significant, but I’m not sure if it actually relates to my problem or not - just something I noticed, but I normally don’t expect to see such size differences going from one minor release to another.

The main problem I see is that once the new 8.7 image is processed through the diskimage-builder job, the resulting customized qcow2 image no longer contains any kernel-related files in /boot/, so if I try to launch an openstack instance with the new image, it simply fails to boot and stops at a grub console prompt.

For the time being, I modified my job to work with the archived (vault) 8.6 image, and the job once again completes successfully with a bootable image.

So far, I’ve not been able to determine the root of the problem. It’s possible that the structure of the new cloud images has changed in some way and the diskimage-builder project needs to be updated to accommodate that change, or something is fundamentally missing in the images starting with 8.7.

Anybody have clues as to what may be going on?

2

I would take a look here: kickstarts/Rocky-8-GenericCloud-Base.ks at r8 - kickstarts - Rocky Enterprise Software Foundation Git Service

When we released 8.7 and 9.1, we attempted to make the images boot universally. This means that if someone boots the generic cloud image on BIOS or UEFI, it should just work. To do this, the gpt had to be set for the disk image and additional partitions were set. This was done intentionally to try to inherit what Fedora does with their cloud images.

As for the package reduction, this is because we use templates now to build our images. Most cloud images inherit the same package set now as a result, and this is likely why you’re seeing a reduced size.

3

Thanks for that info - makes sense. Based on that, it does seem like its the diskimage-builder job that needs to be updated.

I can see that the original 8.7 cloud image does show 4 partitions and a GPT label:

# fdisk -l /dev/nbd0
Disk /dev/nbd0: 10 GiB, 10737418240 bytes, 20971520 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 1EBFE1B6-33F2-4878-A2BB-996868440D06

Device        Start      End  Sectors  Size Type
/dev/nbd0p1    2048   206847   204800  100M EFI System
/dev/nbd0p2  206848  2254847  2048000 1000M Linux filesystem
/dev/nbd0p3 2254848  2256895     2048    1M BIOS boot
/dev/nbd0p4 2256896 20969471 18712576  8.9G Linux filesystem

And then post-processing by diskimage-builder, the resulting image is the “old style” single partition, but obviously missing key bits:

# fdisk -l /dev/nbd1
Disk /dev/nbd1: 2.8 GiB, 2956328960 bytes, 5774080 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x783ac85d

Device      Boot Start     End Sectors  Size Id Type
/dev/nbd1p1 *     2048 5772031 5769984  2.8G 83 Linux

Thanks again for pointing me in the right direction!

1 Like
4

For reference, I filed a bug report with diskimage-builder here:

5

Hi @guzzijason,

I maintain the rocky images in DIB, and I think there might be some confusion here.

The Rocky Linux images built in DIB are not built using the genericcloud qcow2 image, but rather by starting from the Rocky Linux Container images and buidling on top.

Either here (or preferably in the launchpad bug), can you describe exactly what it is you are doing with the QCOW to run it through DIB?

For reference, the images produced by DIB are run in CI on the OpenStack projects many times a day with BIOS/UEFI boot.

Best,
Neil