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: | anaconda | Assignee: | 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.0 | CC: | 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
(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 |