Additionally, the absolute symlink with /boot in the name is invalid when GRUB2 boots on a non-UEFI boot; installing the package causes even a valid grubenv file contents to not get used, as at GRUB2 boot time "/boot" is "/" to it's world view. A relative symlink instead of absolute would solve this problem, which is actually how we discovered the problem (GRUB2 failed to find it's environment block due to dangling symlink).

(In reply to troy.engel from comment #1)
> Additionally, the absolute symlink with /boot in the name is invalid when
> GRUB2 boots on a non-UEFI boot; installing the package causes even a valid
> grubenv file contents to not get used, as at GRUB2 boot time "/boot" is "/"
> to it's world view. A relative symlink instead of absolute would solve this
> problem, which is actually how we discovered the problem (GRUB2 failed to
> find it's environment block due to dangling symlink).

This is a problem not only at boot time but also at install time. We discovered this in ReaR, which restores the system to disks mounted under /mnt/local and then calls grub2-install --root-directory=/mnt/local, which fails with "grub2-install: error: cannot rename the file /mnt/local/boot/grub2/grubenv.new to /mnt/local/boot/grub2/grubenv: No such file or directory.", see bz1498748.

There are two problems here:
- even if the symlink target /boot/efi/EFI/redhat/grubenv exists in the target filesystem hierarchy, it is accessible only as /mnt/local/boot/efi/EFI/redhat/grubenv, so the symlink is dangling during the restore operation. Converting the symlink to relative would help here.
- if the symlink target does not exists (as mentioned in the original report), the symlink will be always dangling and grub2-install will fail as well (it has no support to create a symlink target even if the symlink points to a nonexinstent file in an existing directory). Here converting the symlink to relative does not help.

As a result the restored system is left unbootable. The second case actually even prevents reinstallation of Grub into MBR using grub2-install in a running system.

I am still seeing this with grub2-2.02-0.73.el7.x86_64, using lorax-composer (an API on top of livemedia-creator) that is trying to build a disk image. The kickstart includes both versions of grub2 because we don't know how the image will be booting.

Anaconda logs this when running grub2-install

22:24:11,171 INFO program: Running... grub2-install --no-floppy /dev/loop0
22:24:13,322 INFO program: Installing for i386-pc platform.
22:24:13,322 INFO program: grub2-install: error: cannot rename the file /boot/grub2/grubenv.new to /boot/grub2/grubenv: No such file or directory.
22:24:13,322 DEBUG program: Return code: 1
22:24:13,324 INFO program: Running... grub2-set-default 0
22:24:13,370 INFO program: /usr/bin/grub2-editenv: error: cannot rename the file /boot/grub2/grubenv.new to /boot/grub2/grubenv: No such file or directory.
22:24:13,371 INFO program: /usr/bin/grub2-editenv: error: cannot rename the file /boot/grub2/grubenv.new to /boot/grub2/grubenv: No such file or directory.
22:24:13,371 INFO program: /usr/bin/grub2-editenv: error: cannot rename the file /boot/grub2/grubenv.new to /boot/grub2/grubenv: No such file or directory.
22:24:13,371 DEBUG program: Return code: 0
22:24:13,371 INFO program: Running... grub2-mkconfig -o /boot/grub2/grub.cfg
22:24:13,910 INFO program: /usr/bin/grub2-editenv: error: cannot rename the file /boot/grub2/grubenv.new to /boot/grub2/grubenv: No such file or directory.
22:24:13,911 INFO program: Generating grub configuration file ...
22:24:13,911 INFO program: Found linux image: /boot/vmlinuz-3.10.0-918.el7.x86_64
22:24:13,911 INFO program: Found initrd image: /boot/initramfs-3.10.0-918.el7.x86_64.img
22:24:13,911 INFO program: done

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

The part which was problematic for ReaR was fixed. Absolute symlink was converted to a relative one and this is sufficient for us. Dropping bz1498748

I'm running into issues with grub2-efi trying to use a /boot/grub2/grubenv symlink on current Fedora systems as well. In my case, I've used my ESP as $BOOT as recommended in the new boot loader specification (https://systemd.io/BOOT_LOADER_SPECIFICATION#technical-details):

"... if the OS is installed on a disk with GPT disk label, and no ESP partition exists yet, a new suitably sized (let’s say 500MB) ESP should be created and should be used as $BOOT."

However, because this forces $BOOT to be formatted with a VFAT file system, the symlink does not work. IMHO, grub2-efi should not be trying to write to /boot/grub2/grubenv. It should be writing directly to $ESP/efi/fedora/grubenv. As it is currently, I have to manually copy /boot/grub2/grubenv to /boot/efi/fedora/grubenv every time I update my kernel parameters.

(In reply to Gregory Lee Bartholomew from comment #16)
> I'm running into issues with grub2-efi trying to use a /boot/grub2/grubenv
> symlink on current Fedora systems as well. In my case, I've used my ESP as
> $BOOT as recommended in the new boot loader specification
> (https://systemd.io/BOOT_LOADER_SPECIFICATION#technical-details):
> 
> "... if the OS is installed on a disk with GPT disk label, and no ESP
> partition exists yet, a new suitably sized (let’s say 500MB) ESP should be
> created and should be used as $BOOT."
> 
> However, because this forces $BOOT to be formatted with a VFAT file system,
> the symlink does not work. IMHO, grub2-efi should not be trying to write to
> /boot/grub2/grubenv. It should be writing directly to
> $ESP/efi/fedora/grubenv. As it is currently, I have to manually copy
> /boot/grub2/grubenv to /boot/efi/fedora/grubenv every time I update my
> kernel parameters.

I would recommend filling a separate bug for Fedora, as this bz is for RHEL 7, and it does not implement blscfg, your issue also doesn't look related to the specific issue in this bz. In addition Fedora implements blscfg slightly different than the original specification that you linked, you can view the differences here. https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault#Differences_from_BootLoaderSpec 

Also you can symlinks to a file located on a vfat fs, you just can't create symlinks from a vfat fs. So as long as /boot is not vfat, which it shouldn't be, you can create a symlink from /boot/grub2/grubenv to /boot/efi/EFI/fedora/grubenv.

Verified on RHEL-7.7-20190403.0 and grub2-2.02-0.80.el7.x86_64.rpm.

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:2014