Fix kernel boot on UEFI systems

[deepssin]

• Add _update_uefi_grub_config() to sync UEFI GRUB config
• Fixes issue where systems reboot into old kernel on UEFI

[djgalloway]

How does this work for non-UEFI systems? Should we maybe detect EFI vs BIOS and only run those if EFI=true?

[dmick]

I have seen suggestions that /etc/grub.cfg is always a symlink to the "right" grub.cfg. if that's true that would be better.

Also, does this code run for BLS systems? If BLS is used we should not be touching grub.cfg at all

[deepssin]

How does this work for non-UEFI systems? Should we maybe detect EFI vs BIOS and only run those if EFI=true?

Have added check https://github.com/deepssin/teuthology/blob/0408de85a4d6eca6e538f650f0963db7f75d15d3/teuthology/task/kernel.py#L983

[deepssin]

I have seen suggestions that /etc/grub.cfg is always a symlink to the "right" grub.cfg. if that's true that would be better.

Also, does this code run for BLS systems? If BLS is used we should not be touching grub.cfg at all

I verified this on my system /etc/grub.cfg doesn't exist:

[root@node1 ~]# ls -l /etc/grub.cfgls: cannot access '/etc/grub.cfg': No such file or directory

What exists is /etc/grub2.cfg, which is a symlink to /boot/grub2/grub.cfg (not a UEFI location):

[root@node1 ~]# ls -l /etc/grub2.cfglrwxrwxrwx. 1 root root 22 Aug 7 18:10 /etc/grub2.cfg -> ../boot/grub2/grub.cfg

So the symlink check isn't reliable across systems is what I understand:

• Check if the system is UEFI (via /sys/firmware/efi)
• If UEFI, copy grub.cfg to all EFI vendor directories (e.g., /boot/efi/EFI/BOOT, /boot/efi/EFI/centos)

This avoids relying on symlink configurations that vary. The code now always updates all EFI vendor directories when on UEFI systems, ensuring the correct one is updated regardless of which vendor directory the firmware uses.

[djgalloway]

I'm still confused. I am no coder but if I'm understanding what I'm reading correctly, this does not handle BLS at all. Is that right?

This commit does work but, again, I don't know how sane or valid or copacetic it is: 8ce0b02

[dmick]

You are correct, @djgalloway, and I don't understand why we're ignoring BLS either

[deepssin]

Thanks for pointing that out @dmick @djgalloway — you’re right that on BLS systems we shouldn’t be touching grub.cfg at all.

I’ve updated the logic so that:

BLS systems are handled exclusively via grubby / BLS entry IDs, and we no longer sync or rely on any grub.cfg content in that path.

The UEFI vendor grub.cfg sync is now only done in the non-BLS path, where we actually regenerate grub.cfg and kernel selection depends on it.

This keeps BLS handling fully independent of grub.cfg while still addressing the UEFI case where firmware boots directly from /boot/efi/EFI/*/grub.cfg.

Please let me know if this matches the intended split, or if you’d prefer a different UEFI handling strategy on BLS systems.

[djgalloway]

It doesn't look like this works quite yet.

See https://qa-proxy.ceph.com/teuthology/dgalloway-2026-01-12_21:37:37-rados-wip-yuri7-testing-2026-01-08-2356-distro-default-trial/6118/teuthology.log

[deepssin]

It doesn't look like this works quite yet.

See https://qa-proxy.ceph.com/teuthology/dgalloway-2026-01-12_21:37:37-rados-wip-yuri7-testing-2026-01-08-2356-distro-default-trial/6118/teuthology.log

@djgalloway Thanks for testing. I've identified and fixed the issue. On BLS systems with UEFI, we were setting the default via BLS (grub2-set-default or grubby) but not regenerating grub.cfg or syncing it to the UEFI directory. The firmware reads from /boot/efi/EFI/*/grub.cfg, so it didn't see the updated default. This should work now!

[dmick]

I don't know where we are with this for sure, but it'll be better to have it in the tree for further fixes than to keep holding it up.

Need to move forward

[djgalloway]

Confirmed works! Thanks @deepssin!