Description of problem: When disabling BLS (through removing GRUB_ENABLE_BLSCFG=true from /etc/default/grub), it's not possible to change the default kernel through using grubby, e.g.: -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- # grubby set-default /boot/vmlinuz-4.18.0-348.2.1.el8_5.x86_64 -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- The latter command updates /boot/grub2/grubenv with expected content: -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- saved_entry=29542a35af3c4f41b05de03513f1d85e-4.18.0-348.2.1.el8_5.x86_64 -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- But the Grub never finds the corresponding entry in the "legacy" grub configuration file created by grub2-mkconfig. This is due to having some unique id matching a file name in /boot/loader/entries (without ".conf" suffix) but grub2-mkconfig doesn't generate compatible entries: grub2-mkconfig, in particular /etc/grub.d/10_linux doesn't use BLS entries to create the file, but reads content of /boot/vmlinuz* files instead. Example of generated menuentry: -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- menuentry 'Red Hat Enterprise Linux (4.18.0-348.2.1.el8_5.x86_64) 8.5 (Ootpa)' --class red --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-4.18.0-348.2.1.el8_5.x86_64-advanced-8940fe00-66c7-4e12-aea2-bc253bb214b2' { ... } -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- Here above, in order for Grub to find the saved entry, the menuitem item would need to be fixed into "29542a35af3c4f41b05de03513f1d85e-4.18.0-348.2.1.el8_5.x86_64" instead of "gnulinux-something" e.g.: -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- menuentry 'Red Hat Enterprise Linux (4.18.0-348.2.1.el8_5.x86_64) 8.5 (Ootpa)' --class red --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option '29542a35af3c4f41b05de03513f1d85e-4.18.0-348.2.1.el8_5.x86_64' { ... } -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- I think this is the way to go when having /boot/loader/entries directory on the system (which is RHEL8's way). Version-Release number of selected component (if applicable): grub2-2.02-106.el8 How reproducible: Always Steps to Reproduce: 1. Disable BLS # sed -i "s/^GRUB_ENABLE_BLSCFG=true/#GRUB_ENABLE_BLSCFG=true/" /etc/default/grub # grub2-mkconfig -o /etc/grub2.cfg 2. Change default kernel # grubby set-default /boot/vmlinuz-4.18.0-348.2.1.el8_5.x86_64 # grep saved_entry /boot/grub2/grubenv saved_entry=29542a35af3c4f41b05de03513f1d85e-4.18.0-348.2.1.el8_5.x86_64 3. Reboot Actual results: Still 1st kernel selected Expected results: Wished kernel selected Additional info: NOTE: disabling BLS is **required** on Xen, so the functionality needs to work fine even when BLS is disabled.
A simple patch is to (almost) always include /etc/grub.c/10_linux_bls file in the packaging in replacement to current grub2.spec file: -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- 419 %ifarch ppc64 ppc64le 420 %exclude %{_sysconfdir}/grub.d/10_linux 421 %else 422 %exclude %{_sysconfdir}/grub.d/10_linux_bls 423 %endif -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- Indeed, I think there is confusion with what "GRUB_ENABLE_BLSCFG=true" triggers. For me, this option should always be enabled on RHEL/Fedora because we *always* ship snippets in /boot/loader/entries (at least to my knowledge). Hence content of /boot/loader/entries should always be considered, then it's up to grub2-mkconfig to distinguish between: - platforms that can use the "blscfg" Grub module, in such case generate a generic grub2.cfg file - platforms that cannot use "blscfg" Grub module (e.g. PPC64LE, Xen), in such case generate a machine specific grub2.cfg file with hardcoded "menuentries" Why "almost": it's because there is a bug on PPC64le for now: the $kernelopts default is never set which may be problematic if grubenv is corrupted. Just filed BZ #2051889 for this. Javier, am I missing something here? I don't know the whole history on BLS.
Created attachment 1859739 [details] Proposed patched /etc/grub.d/10_linux based on grub2-tools-2.02-106.el8 release
This is not in support scope, so I'm closing.