Bug 1366785

I've tested and confirmed this bug also exists, exactly as Ryan describes, on current Fedora Rawhide images - I tested with Fedora-Workstation-Live-x86_64-Rawhide-20160811.n.2.iso . /boot/grub2/grubenv on the installed system is a symlink to /boot/efi/EFI/fedora/grubenv , and load_env from the grub console fails.

This is breaking functionality in RHVH

Hi Robert,

Please let us know if you need any data from our side (RHVH).

So, I think this means something installed on the non-EFI machines just needs to own the /boot/efi/EFI/$vendor/ directory.  We should probably just make "filesystem" own it.

I realize that seems strange, but the point of using a symlink here is so that nothing has to have code to decide where the file should be, so that the two bootloaders can share the location.

Will this work with grub2? IIRC Ryan investigated this, and the problem was that grub2 expects a real file.

Specifically, grub2 expects grubenv to be exactly 1kb, and doesn't follow symlinks

We can't actually avoid the symlink problem here, because the two packages are created from the /same/ build tree.  So we actually can't include one (or zero) file at /boot/grub2/grubenv in one and a symlink in the other.

But the problem isn't that the /file/ is missing - that's normal and it copes fine.  The problem is the directory isn't there.  So the answer here is that you should just create /boot/efi/EFI/$vendor/ for the BIOS image as well.

(Note that this will only effect x86, because there's no other platform where there's two different firmwares that grub builds from the same tree.)

(In reply to Ryan Barry from comment #6)
> Specifically, grub2 expects grubenv to be exactly 1kb, and doesn't follow
> symlinks

No, it does follow symlinks.

reply to Peter Jones from comment #7)
> We can't actually avoid the symlink problem here, because the two packages
> are created from the /same/ build tree.  So we actually can't include one
> (or zero) file at /boot/grub2/grubenv in one and a symlink in the other.
> 
> But the problem isn't that the /file/ is missing - that's normal and it
> copes fine.  The problem is the directory isn't there.  So the answer here
> is that you should just create /boot/efi/EFI/$vendor/ for the BIOS image as
> well.

This is already the case (see comment#1)

> 
> (Note that this will only effect x86, because there's no other platform
> where there's two different firmwares that grub builds from the same tree.)


(In reply to Peter Jones from comment #8)
> (In reply to Ryan Barry from comment #6)
> > Specifically, grub2 expects grubenv to be exactly 1kb, and doesn't follow
> > symlinks
> 
> No, it does follow symlinks.

In initial testing (it's been a while since I filed this/tested), this doesn't seem to work.

/boot/grub2/grubenv -> /boot/efi/EFI/redhat/grubenv

However, "loadenv" from a grub shell fails. My assumption was that this was because a symlink is not exactly 1024 bytes (or whatever grub2 looks for).

If "loadenv" followed symlinks, that would also be an acceptable resolution.(In

Any update?

In reply to Peter Jones from comment #8)
> (In reply to Ryan Barry from comment #6)
> > Specifically, grub2 expects grubenv to be exactly 1kb, and doesn't follow
> > symlinks
> 
> No, it does follow symlinks.

Just thinking here.

The layout is something like this:
sda1 /boot/efi
sda2 /boot
sda3 /

The symlink (sda2)"/grub2/grubenv" points to "/boot/efi/EFI/redhat/grubenv".
But there is no (sda2)"/boot/efi/EFI/redhat/grubenv", the file that would correspond it in OS is (sda1)"/EFI/redhat/grubenv".

Isn't this the issue?

I'm having problems reproducing this bug. I'm just not able to build squashfs.img that would have this issue. I also couldn't find mentioned redhat-virtualization-host-4.0-20160811.0.x86_64.liveimg.squashfs. Could you please point me to it or better provide me lorax command how to build it so that we can reproduce this? We're testing lorax, but I wasn't able to reproduce this and tried basically everything I know :(
And yes, I was building it on UEFI system.

Thanks

I haven't tried to reproduce this locally -- it's just something that I've noticed in brew/koji (the Fedora cloud images have the same problem). Can we check to see how brew/koji are invoking Lorax?

This missed 7.2.z -> 7.6; can we have a target milestone for this? 7.6.z? 7.7?

Anaconda is not doing Z streams but we will look on this during 7.7 planning.

Ying, can you reproduce this? Not sure grub/grubby still doesn't understand symlinks anymore.

(In reply to Sandro Bonazzola from comment #18)
> Ying, can you reproduce this? Not sure grub/grubby still doesn't understand
> symlinks anymore.

@Qin,

Could you please help to work on this?

Thanks.

Tested with redhat-virtualization-host-4.3-20181206.0.el7_6.x86_64.liveimg.squashfs, /boot/grub2/grubenv is a file of 1024 bytes, not a symlink, and load_env works.

(In reply to Qin Yuan from comment #20)
> Tested with
> redhat-virtualization-host-4.3-20181206.0.el7_6.x86_64.liveimg.squashfs,
> /boot/grub2/grubenv is a file of 1024 bytes, not a symlink, and load_env
> works.

Tested on BIOS system.

Based on c#20 and after talking with Sandro, I'm going to close this since this seems acceptable now. Please re-open if you feel the issue was not resolved.