Hide Forgot
Description of problem: saved_entry is not set correctly after a fresh installation from ISO media: the value is an index rather than the id of a BLS entry. Hardware is a KVM virtual machine in virt-manager. RHEL-8.0-20190116.n.0 but other recent composes are reported to behave the same. grub2-tools-extra-2.02-66.el8.x86_64 grub2-common-2.02-66.el8.noarch grub2-tools-2.02-66.el8.x86_64 grubby-8.40-31.el8.x86_64 grub2-tools-minimal-2.02-66.el8.x86_64 grub2-pc-2.02-66.el8.x86_64 grub2-tools-efi-2.02-66.el8.x86_64 grub2-pc-modules-2.02-66.el8.noarch # grub2-editenv list saved_entry=0 kernelopts=root=/dev/mapper/rhel-root ro crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet boot_success=0 Version-Release number of selected component (if applicable): 2.02-66.el8 How reproducible: 100% Steps to Reproduce: 1. Install from ISO 2. Boot system 3. grub2-editenv list Actual results: No saved_entry Expected results: saved_entry refers to the latest system boot entry Additional info: Upgrades via the Leapp tool have not exhibited the same behaviour - in this case, saved_entry is set and any auxiliary boot entries (e.g. BLS entries created with boom) do not take precedence over the system entries. Configuration seen with Leapp upgrade (from December repos): # grub2-editenv list saved_entry=523a903dd71b4166b3ba5884464bfb1f-4.18.0-48.el8.x86_64 kernelopts=root=/dev/mapper/rhel-root ro crashkernel=auto rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet boot_success=0 boot_indeterminate=0
(In reply to Bryn M. Reeves from comment #0) > Description of problem: > saved_entry is not set correctly after a fresh installation from ISO media: > the value is an index rather than the id of a BLS entry. Hardware is a KVM > virtual machine in virt-manager. > > RHEL-8.0-20190116.n.0 but other recent composes are reported to behave the > same. > > grub2-tools-extra-2.02-66.el8.x86_64 > grub2-common-2.02-66.el8.noarch > grub2-tools-2.02-66.el8.x86_64 > grubby-8.40-31.el8.x86_64 > grub2-tools-minimal-2.02-66.el8.x86_64 > grub2-pc-2.02-66.el8.x86_64 > grub2-tools-efi-2.02-66.el8.x86_64 > grub2-pc-modules-2.02-66.el8.noarch > > # grub2-editenv list > saved_entry=0 > kernelopts=root=/dev/mapper/rhel-root ro crashkernel=auto > resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb > quiet > boot_success=0 > Agreed, I first couldn't find the culprit in the GRUB code but then realized that this is actually set by Anaconda. It has been the case since 2015, commit 8e6501377f6 Use the index in grubenv (#1209678): https://github.com/rhinstaller/anaconda/commit/8e6501377f6e This made sense with a non-BLS setup since the entries were ordered by how they were defined in the grub2.cfg file. So the order was static, but that's no longer the case with BLS. So I've proposed the following change to Anaconda fixing this: https://github.com/rhinstaller/anaconda/pull/1789 > Version-Release number of selected component (if applicable): > 2.02-66.el8 > > How reproducible: > 100% > > Steps to Reproduce: > 1. Install from ISO > 2. Boot system > 3. grub2-editenv list > > Actual results: > No saved_entry > > Expected results: > saved_entry refers to the latest system boot entry > > Additional info: > Upgrades via the Leapp tool have not exhibited the same behaviour - in this > case, saved_entry is set and any auxiliary boot entries (e.g. BLS entries > created with boom) do not take precedence over the system entries. > > Configuration seen with Leapp upgrade (from December repos): > > # grub2-editenv list > saved_entry=523a903dd71b4166b3ba5884464bfb1f-4.18.0-48.el8.x86_64 > kernelopts=root=/dev/mapper/rhel-root ro crashkernel=auto > rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet > boot_success=0 > boot_indeterminate=0 Yes, the kernel-install sets the default to the BLS id (filename without the .conf suffix) so that's why on an update you have the correct saved_entry. Only the initial grubenv as generated by Anaconda would be wrong.
> Agreed, I first couldn't find the culprit in the GRUB code but then realized that this is actually set by Anaconda. It has been the case since 2015, commit 8e6501377f6 Use the index in grubenv (#1209678): Thank you! I spent a couple of days going back and fore on this looking at the Grub changes and I couldn't figure out what was setting it to an index. I wondered whether the installer was involved (based on some older bugs I saw while looking around), but hadn't gotten to actually checking. > So I've proposed the following change to Anaconda fixing this: > > https://github.com/rhinstaller/anaconda/pull/1789 Makes sense, thanks again!
Fixed in a pull request from Javier: https://github.com/rhinstaller/anaconda/pull/1789
*** Bug 1663860 has been marked as a duplicate of this bug. ***
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:3417