Bug 1671047 - saved_entry is not set properly after installation from nightly ISO
Summary: saved_entry is not set properly after installation from nightly ISO
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: anaconda
Version: 8.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.0
Assignee: Vendula Poncova
QA Contact: Release Test Team
Sharon Moroney
URL:
Whiteboard:
: 1663860 (view as bug list)
Depends On:
Blocks: 1660923 1701002 1663860
TreeView+ depends on / blocked
 
Reported: 2019-01-30 16:07 UTC by Bryn M. Reeves
Modified: 2019-11-20 14:24 UTC (History)
10 users (show)

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.
Clone Of:
Environment:
Last Closed: 2019-11-05 21:07:54 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:3417 None None None 2019-11-05 21:08:35 UTC

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


Note You need to log in before you can comment on or make changes to this bug.