Bug 2051555
| Summary: | Cannot change default kernel when BLS is disabled | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Renaud Métrich <rmetrich> | ||||
| Component: | grub2 | Assignee: | Bootloader engineering team <bootloader-eng-team> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Release Test Team <release-test-team> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 8.5 | CC: | fmartine, jaredz, pjanda, sbarcomb | ||||
| Target Milestone: | rc | Keywords: | TestCaseNeeded | ||||
| Target Release: | --- | Flags: | rmetrich:
needinfo?
(fmartine) |
||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2023-07-26 14:37:45 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
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. |
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.