Hide Forgot
Description of problem: Anaconda faithfully delivers the entire liveimg payload as it appears, including the contents of /boot The problem in this case is that liveimg payloads built with lorax (or packer) on EFI systems include /boot/efi/EFI/$vendor as part of the payload. When this is used with Anaconda on an EFI installation, it's treated correctly. However, if this is used with Anaconda on a legacy installation, the liveimg leaves a structure like: boot ├── config-3.10.0-327.22.2.el7.x86_64 ├── efi │ └── EFI │ ├── BOOT │ │ ├── BOOTX64.EFI │ │ └── fallback.efi │ └── redhat │ ├── BOOT.CSV │ ├── fonts │ │ └── unicode.pf2 │ ├── gcdx64.efi │ ├── grubenv │ ├── grubx64.efi │ ├── MokManager.efi │ ├── shim.efi │ └── shim-redhat.efi ├── grub2 │ ├── device.map │ ├── device.map.anacbak │ ├── fonts │ │ └── unicode.pf2 │ ├── grub.cfg │ ├── grubenv -> /boot/efi/EFI/redhat/grubenv grub2 expects grubenv to be exactly 1024 bytes, in $prefix (so a symlink fails to load -- grub2 doesn't appear to understand symlinks) Version-Release number of selected component (if applicable): anaconda-21.48.22.56-1.el7 How reproducible: 100% Steps to Reproduce: 1. Use redhat-virtualization-host-4.0-20160811.0.x86_64.liveimg.squashfs as a liveimg payload on a legacy/BIOS system 2. ls -l /boot/grub2/grubenv 3. attempt to "load_env" from a grub console Actual results: /boot/grub2/grubenv is a symlink to /boot/efi/EFI/$vendor/grubenv grub2 load_env fails Expected results: /boot/grub2/grubenv is not a symlink on legacy installations grub2 load_env works Additional info:
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.