Rocky 9.3 to 9.4 upgrade issues

[jeevanal]

We have created different templates with disks according to app requirement. When VMs are provisioned out of the template, yum update from 9.3 to 9.4 is going to grub mode after the reboot. This is happening on all the servers for those templates.

What are the parameters that causes these issues?

[jbkt23]

How recently did you install rl9.3, was it the initial install?
There have been several kernel updates since the initial 9.3 release so did you have to run this command before reboot after each new kernel.

grub2-mkconfig -o /boot/grub2/grub.cfg --update-bls-cmdline

There are exceptions to this if you have an up to date /etc/kernel/cmdline file but that will only exist if you’ve run the above command at least once since 9.3 was installed. Without any log output everyone will make wild guesses as to the issue you face.

[jeevanal]

@jbkt23 I tried running the above command after the yum update and rebooted but still the server is going to grub prompt.

Below are the logs that i captured when updating the OS.

Output of /etc/default/grub below;

[jbkt23]

There is some miss configuration in the initial install because dracut is looking in the wrong place to update the initrd image. /boot/efi/<machineID-kernelVer> is not a valid path in default rocky install. In the default install kernels and initrd images are on /boot and the EUFI definitions are in /boot/loader/entries/<machingID-kernelVer> . Did you override the initial install with your own paths?

[jeevanal]

@jbkt23 The default boot path is /boot/efi when we did the OS installs. Since the boot path is /boot/efi , do we need to perform any changes to the grub before we upgrade?

I have also tried the below command after the OS update and before the reboot but still goes to grub prompt.

grub2-mkconfig --update-bls-cmdline -o /etc/grub2-efi.cfg

[jbkt23]

It’s probably quicker to reinstall because it will take too many screen shots to figure out.

[jbkt23]

@jeevanal

grub2-mkconfig --update-bls-cmdline -o /etc/grub2-efi.cfg

/etc/grub2-efi.cfg is a link which should point to /boot/grub2/grub.cfg. You should always use the actual path which is /boot/grub2/grub.cfg

The file /boot/efi/EFI/rocky/grub.cfg should have contents similar to this:

search --no-floppy --root-dev-only --fs-uuid --set=dev 7277c17d-6897-497b-9390-1153c9bff018
set prefix=($dev)/boot/grub2
export $prefix
configfile $prefix/grub.cfg

I’m using tree below to show the abbreviated contents of /boot including the mount point /boot/efi, read the man page so that you understand how the options limit the scope of decent into the file system.

# tree -xL 1 /boot
/boot
├── config-5.14.0-427.26.1.el9_4.x86_64
├── config-5.14.0-427.31.1.el9_4.x86_64
├── config-5.14.0-427.33.1.el9_4.x86_64
├── efi
├── grub2
├── initramfs-5.14.0-427.26.1.el9_4.x86_64.img
├── initramfs-5.14.0-427.31.1.el9_4.x86_64.img
├── initramfs-5.14.0-427.33.1.el9_4.x86_64.img
├── loader
├── symvers-5.14.0-427.26.1.el9_4.x86_64.gz -> /lib/modules/5.14.0-427.26.1.el9_4.x86_64/symvers.gz
├── symvers-5.14.0-427.31.1.el9_4.x86_64.gz -> /lib/modules/5.14.0-427.31.1.el9_4.x86_64/symvers.gz
├── symvers-5.14.0-427.33.1.el9_4.x86_64.gz -> /lib/modules/5.14.0-427.33.1.el9_4.x86_64/symvers.gz
├── System.map-5.14.0-427.26.1.el9_4.x86_64
├── System.map-5.14.0-427.31.1.el9_4.x86_64
├── System.map-5.14.0-427.33.1.el9_4.x86_64
├── vmlinuz-5.14.0-427.26.1.el9_4.x86_64
├── vmlinuz-5.14.0-427.31.1.el9_4.x86_64
└── vmlinuz-5.14.0-427.33.1.el9_4.x86_64

# tree -xL 1 /boot/loader/entries/
/boot/loader/entries/
├── ba3fd5ffa1514c2bb468fa289f69faa0-5.14.0-427.26.1.el9_4.x86_64.conf
├── ba3fd5ffa1514c2bb468fa289f69faa0-5.14.0-427.31.1.el9_4.x86_64.conf
└── ba3fd5ffa1514c2bb468fa289f69faa0-5.14.0-427.33.1.el9_4.x86_64.conf

# tree /boot/efi
/boot/efi
└── EFI
    ├── BOOT
    │   ├── BOOTX64.EFI
    │   └── fbx64.efi
    └── rocky
        ├── BOOTX64.CSV
        ├── grub.cfg
        ├── grubx64.efi
        ├── mmx64.efi
        ├── shim.efi
        ├── shimx64.efi
        └── shimx64-rocky.efi

# tree -xL 1 /boot/grub2/
/boot/grub2/
├── device.map
├── fonts
├── grub.cfg
├── grubenv
├── i386-pc
└── locale

Use this for your own evaluation. Do a default install on another machine to compare the directory structure with what is on the problem machine.
Mount your system with a usb spin so you can copy text output and then post it in a code block in your forum post. Screen images are too limiting for effective evaluation.

[jlehtone]

man dracutwrites:

…, depending on bootloader specification, the default location can be /efi/<machine-id>/<kernel-version>/initrd, /boot/<machine-id>/<kernel-version>/initrd, /boot/efi/<machine-id>/<kernel-version>/initrd, /lib/modules/<kernel-version>/initrd or /boot/initramfs-<kernel-version>.img.

The error message shows failure to generate /boot/efi/<machine-id>/<kernel-version>/initrd. Normal Rocky installation writes /boot/initramfs-<kernel-version>.img.

GRUB entry (if proper) loads kernel and image. If the image file does not exist, then GRUB cannot do that and shows the prompt.

---

What is the custom bootloader specification in your templates that does mess up your initrd generation?