Hi there,
We have a process in place to build Rocky Linux 9.2 AMI’s in AWS.
We use the Rocky 9 ami-07d75f492ac3a326f as root and then chroot into a secondary volume to build our base scratch OS of Rocky9 as per our requirement.
Recently after an update to this new kernel( 5.14.0-362.13.1.el9_3.x86_64) things started to break on builds as on boot the ami built with the chrooted(secondary volume) would constantly look out for the root uuid stating Warning: /dev/disk/by-uuid/06230a70-4636-4663-8179-0597f0245374 does not exist
I noticed that this is the uuid of the root partition of ami-07d75f492ac3a326f.
On investigating everywhere I could see that the uuid of the new root partion is updated on grub.cfg file when mkconfig is executed. However the entry is still not updated when I look at entries in the
grubby info all commands.
I had to manually override this using chroot "{{ rootfs }}" grubby --update-kernel=ALL --args=root="UUID={{ blkid_root.stdout }}"
Wanted to check if this is already a known issue, because we had perfectly normal builds before.
Has anything changed which does not propagate the updated root uuid to grubby.
grub2-mkconfig does not touch the /boot/loader/entries. Grubby is the tool to do that or “kernel-install” on new kernel installs. The first time you run grubby --update-kernel=ALL --args=<> it should populate the file:
/etc/kernel/cmdline
then on subsequent kernel updates those commandline parameters should populate the new entry in /boot/loader/entries.
The man page for kernel-install describes some of the new kernel install routine. There is no documentation on how or why the /etc/kernel/cmdline file is created.
Actually I did not touch any ami build code while moving to kernal 5.14.0-362.13.1.el9_3.x86_64
But things started to break irrespectively and I wasn’t able to get my ami’s too boot up initially without updating the uuid of the chrooted root device using grubby.
Hence was wondering if there has been any change while making the grub in the chrooted device