Bug 1687323

Summary:	/boot/grub2/grubenv is changed into a dead symlink by installing grub2-efi package on non-uefi machine
Product:	[Fedora] Fedora	Reporter:	Javier Martinez Canillas <fmartine>
Component:	grub2	Assignee:	Peter Jones <pjones>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	30	CC:	fmartine, lkundrak, pjones, rpbikker
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	grub2-2.02-72.fc30	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-03-12 20:00:49 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Javier Martinez Canillas 2019-03-11 09:19:42 UTC

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:

Comment 1 Fedora Update System 2019-03-11 12:51:22 UTC

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

Comment 2 Fedora Update System 2019-03-11 14:42:09 UTC

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

Comment 3 Fedora Update System 2019-03-12 20:00:49 UTC

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.

Comment 4 Javier Martinez Canillas 2019-06-17 07:36:01 UTC

*** Bug 1716193 has been marked as a duplicate of this bug. ***

Comment 5 Reinier Bikker 2019-06-17 10:13:26 UTC

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?

Comment 6 Reinier Bikker 2019-06-17 19:05:21 UTC

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.)