Fedora Account System
Red Hat Associate
Red Hat Customer
This bug was initially created as a copy of Bug #1497918 I am copying this bug because: It's also present in Fedora. Description of problem: /boot/grub2/grubenv is a regular file on Non-uEFI machine. (NOTE: it's a symlink to /boot/efi/EFI/redhat/grubenv on uEFI machine) grub-efi package is not installed by default on Non-uEFI machine. But, It can be installed on Non-uEFI by intent. One example is to create a PXE environment for uEFI client on Non-uEFI machine. bootloader for uEFI client is included in grub2-efi. But, when grub2-efi is installed, /boot/grub2/grubenv was recreated as a symlink. And, the original content in /boot/grub2/grubenv was lost. Version-Release number of selected component (if applicable): Red Hat Enterprise Linux 7 How reproducible: Always Steps to Reproduce: 1. Install RHEL7.3 2. Install a newer kernel from RHEL7.4 repo 3. change the default kernel to be booted with grubby command. # grubby --set-default=/boot/vmlinuz-3.10.0-514.el7.x86_64 4. check the status in /boot/grub2/grubenv # ls -l /boot/grub2/grubenv -rw-r--r--. 1 root root 1024 Oct 3 14:59 /boot/grub2/grubenv # grub2-editenv list saved_entry=Red Hat Enterprise Linux Server (3.10.0-514.el7.x86_64) 7.3 (Maipo) 5. install grub2-efi from RHEL7.4 repo. (NOTE: grub2-efi-x64 is installed actually) 6. check the status in /boot/grub2/grubenv # ls -l /boot/grub2/grubenv lrwxrwxrwx. 1 root root 28 Oct 3 15:05 /boot/grub2/grubenv -> /boot/efi/EFI/redhat/grubenv # ls -l /boot/efi/EFI/redhat/grubenv ls: cannot access /boot/efi/EFI/redhat/grubenv: No such file or directory 7. /boot/efi/EFI/redhat/grubenv is created by "grub2-editenv list". But, it's empty. The original content was lost. Actual results: The original content of /boot/grub2/grubenv was lost by installing grub2-efi on Non-uEFI machine. Expected results: The original content is not lost by installing grub2-efi. Additional info:
grub2-2.02-72.fc30 grubby-8.40-29.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-80aeacc4a7
grub2-2.02-72.fc30, grubby-8.40-29.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-80aeacc4a7
grub2-2.02-72.fc30, grubby-8.40-29.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 1716193 has been marked as a duplicate of this bug. ***
I filed bug 1716193 against grub2-efi-x64-2.02-81.fc30.x86_64, where /boot/grub2/grubenv is still a symlink to ../efi/EFI/fedora/grubenv. My case is an UEFI machine (with a separate EFI partion) which for some reason now only boots via the legacy BIOS method. Having a symlink to a different partition makes the system fail at legacy boot. In order to get a bootable system I replaced the symlink with a copy of /boot/efi/EFI/fedora/grubenv. Now, when a new kernel gets installed, /boot/grub2/grubenv gets updated with a new "saved_entry". However, after booting the "boot_success" and "boot_indeterminate" parameters are updated in /boot/efi/EFI/fedora/grubenv. So right now, my boot proces is sort of a Schroedingers cat. If you really think this bug and bug 1716193 are resolved, can you give me a pointer to any grub2 documentation on how to repair my boot setup?
Sorry, I got that the wrong way around. When a new kernel is installed it seems to update /boot/efi/EFI/fedora/grubenv when it detects an EFI system and /boot/grub2/grubenv otherwise. However, systemd always updates /boot/grub2/grubenv in its "Mark boot as successful" unit file (grub-boot-success.service). When /boot/grub2/grubenv is a symlink to /boot/efi/EFI/fedora/grubenv, this wouldn't matter. However, whith a symlink on an EFI system the legacy boot method will not work as a fallback, as I reported in bug 1716193. I think /boot/grub2/grubenv and /boot/efi/EFI/fedora/grubenv should be copies of the same file and *both* should be updated by kernel install and systemd. (BTW, I managed to repair my EFI boot method. The boot disk had both a GPT partioning and an MBR bootsector, which meant the efi firmware refused to recognise it. Found this out and repaired it with gdisk.)