Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
grub2-pc is for legacy installations, but it's always installed, even on EFI systems.
This causes a broken symlink to be created, which may confuse customers:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
# ls -l /etc/grub2.cfg /etc/../boot/grub2/grub.cfg
ls: cannot access '/etc/../boot/grub2/grub.cfg': No such file or directory
lrwxrwxrwx. 1 root root 22 Dec 19 2018 /etc/grub2.cfg -> ../boot/grub2/grub.cfg
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
Version-Release number of selected component (if applicable):
Anaconda RHEL8
How reproducible:
Always
Steps to Reproduce:
1. Install a UEFI system
Actual results:
"grub2-pc" package is installed
Expected results:
No "grub2-pc" package installed
Additional info:
This is due to the way the booloader python code works:
- GRUB2 class is used as base class, which leads to installing "grub2" and "grub2-tools" packages
- EFIGRUB class is derived from GRUB2, causing packages from base class to be installed at well:
/usr/lib64/python3.6/site-packages/pyanaconda/bootloader.py:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
1439 class GRUB2(GRUB):
:
1461 # grub2 is a virtual provides that's provided by grub2-pc, grub2-ppc64le,
1462 # and all of the primary grub components that aren't grub2-efi-${EFIARCH}
1463 packages = ["grub2", "grub2-tools"]
:
1892 class EFIGRUB(EFIBase, GRUB2):
:
1921 @property
1922 def packages(self):
1923 if self._is_32bit_firmware:
1924 return self._packages32 + self._packages_common + \
1925 super().packages
1926 return self._packages64 + self._packages_common + \
1927 super().packages
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
In the code excerpt above, we can see on line 1927 that "packages" attribute from base class ("GRUB2") are appended to the list of packages for EFI.
IMHO the super().packages should be removed and "grub2-tools" specified instead.
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 (anaconda bug fix and enhancement update), 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-2020:4729
Description of problem: grub2-pc is for legacy installations, but it's always installed, even on EFI systems. This causes a broken symlink to be created, which may confuse customers: -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- # ls -l /etc/grub2.cfg /etc/../boot/grub2/grub.cfg ls: cannot access '/etc/../boot/grub2/grub.cfg': No such file or directory lrwxrwxrwx. 1 root root 22 Dec 19 2018 /etc/grub2.cfg -> ../boot/grub2/grub.cfg -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- Version-Release number of selected component (if applicable): Anaconda RHEL8 How reproducible: Always Steps to Reproduce: 1. Install a UEFI system Actual results: "grub2-pc" package is installed Expected results: No "grub2-pc" package installed Additional info: This is due to the way the booloader python code works: - GRUB2 class is used as base class, which leads to installing "grub2" and "grub2-tools" packages - EFIGRUB class is derived from GRUB2, causing packages from base class to be installed at well: /usr/lib64/python3.6/site-packages/pyanaconda/bootloader.py: -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- 1439 class GRUB2(GRUB): : 1461 # grub2 is a virtual provides that's provided by grub2-pc, grub2-ppc64le, 1462 # and all of the primary grub components that aren't grub2-efi-${EFIARCH} 1463 packages = ["grub2", "grub2-tools"] : 1892 class EFIGRUB(EFIBase, GRUB2): : 1921 @property 1922 def packages(self): 1923 if self._is_32bit_firmware: 1924 return self._packages32 + self._packages_common + \ 1925 super().packages 1926 return self._packages64 + self._packages_common + \ 1927 super().packages -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- In the code excerpt above, we can see on line 1927 that "packages" attribute from base class ("GRUB2") are appended to the list of packages for EFI. IMHO the super().packages should be removed and "grub2-tools" specified instead.