Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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.
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.