Bug 1671047

Summary: saved_entry is not set properly after installation from nightly ISO
Product: Red Hat Enterprise Linux 8 Reporter: Bryn M. Reeves <bmr>
Component: anacondaAssignee: Vendula Poncova <vponcova>
Status: CLOSED ERRATA QA Contact: Release Test Team <release-test-team-automation>
Severity: unspecified Docs Contact: Sharon Moroney <smoroney>
Priority: unspecified    
Version: 8.0CC: fmartine, jkonecny, jstodola, mpitt, pholica, pzatko, rvykydal, sbueno, smoroney, vponcova
Target Milestone: rc   
Target Release: 8.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: anaconda-29.19.1.4-1 Doc Type: Bug Fix
Doc Text:
.The RHEL 8 installation program now uses the entry ID to set the default boot entry Previously, the RHEL 8 installation program used the index of the first boot entry as the default, instead of using the entry ID. As a consequence, adding a new boot entry became the default, as it was sorted first and set to the first index. With this update, the installation program uses the entry ID to set the default boot entry, and as a result, the default entry is not changed, even if boot entries are added and sorted before the default.
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-11-05 21:07:54 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:
Bug Depends On:    
Bug Blocks: 1660923, 1663860, 1701002    

Description Bryn M. Reeves 2019-01-30 16:07:50 UTC
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

Comment 1 Javier Martinez Canillas 2019-01-31 14:15:47 UTC
(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.

Comment 4 Bryn M. Reeves 2019-01-31 17:05:30 UTC
> 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!

Comment 6 Vendula Poncova 2019-04-16 16:45:55 UTC
Fixed in a pull request from Javier: https://github.com/rhinstaller/anaconda/pull/1789

Comment 17 Bryn M. Reeves 2019-09-20 14:39:21 UTC
*** Bug 1663860 has been marked as a duplicate of this bug. ***

Comment 19 errata-xmlrpc 2019-11-05 21:07:54 UTC
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