Description of problem: Most of the time (not always) I get this error message from grub. setup.error: ../../grub-core/disk/loopback.c:165:can't open device. After my first bug report was closed as "duplicated": this is not bug 1699761. Version-Release number of selected component (if applicable): grub2-pc-2.02-80.fc30.x86_64 grub2-pc-modules-2.02-80.fc30.noarch grubby-8.40-30.fc30.x86_64 grub2-efi-x64-2.02-80.fc30.x86_64 grub2-tools-2.02-80.fc30.x86_64 ostree-grub2-2019.2-1.fc30.x86_64 grub2-tools-extra-2.02-80.fc30.x86_64 grub2-common-2.02-80.fc30.noarch grub2-tools-minimal-2.02-80.fc30.x86_64 How reproducible: Boot your PC. Steps to Reproduce: 1. 2. 3. Actual results: This error appears most of the time when booting instead of the boot menu. setup.error: ../../grub-core/disk/loopback.c:165:can't open device. Expected results: The boot menu should always appear and not this error. Additional info: I use Fedora 30 Silverblue. This error did not appear after updating from F29. It appeared first after a fresh installation.
Created attachment 1571355 [details] /etc/default/grub
Created attachment 1571356 [details] /boot/efi/EFI/fedora/grub.cfg
Created attachment 1571369 [details] /boot/efi/EFI/fedora/grubenv
Created attachment 1571370 [details] /boot/loader/entries/ostree-1-fedora.conf
Created attachment 1571371 [details] /boot/loader/entries/ostree-2-fedora.conf
After I copied the .efi files from /usr/lib/ostree-boot/efi/EFI/fedora/ to /boot/efi/EFI/fedora this error message seems to not appear anymore (I booted my PC twice) but the boot menu still does not appear.
I'm not sure what's going on in either case. The grub.cfg seems to be a hybrid of blscfg=true now being enabled for conventional Fedora installations, and ostree. There is a 10_linux section that executes blscfg which should then try to do something with the /boot/loader/entries/ostree*conf files (does it?) and then a separate 15_ostree section that has the ostree generated menu entries. I wonder if a bug has been introduced somewhere; as in maybe the ostree*conf files are confusing blscfg, and it gets stuck and then doesn't parse any further on to 15_ostree. A possible work around might be to just delete the entire 10_linux section, i.e. delete everything between: ### BEGIN /etc/grub.d/10_linux ### ### END /etc/grub.d/10_linux ###
(In reply to Chris Murphy from comment #7) > I'm not sure what's going on in either case. The grub.cfg seems to be a > hybrid of blscfg=true now being enabled for conventional Fedora > installations, and ostree. There is a 10_linux section that executes blscfg > which should then try to do something with the > /boot/loader/entries/ostree*conf files (does it?) and then a separate > 15_ostree section that has the ostree generated menu entries. > > I wonder if a bug has been introduced somewhere; as in maybe the ostree*conf > files are confusing blscfg, and it gets stuck and then doesn't parse any > further on to 15_ostree. A possible work around might be to just delete the > entire 10_linux section, i.e. delete everything between: > ### BEGIN /etc/grub.d/10_linux ### > ### END /etc/grub.d/10_linux ### I think that either GRUB_ENABLE_BLSCFG=true should be set in Silverblue (the blscfg module is able to parse the BLS snippets in /boot/loader/entries/ostree*conf) and the grub2-ostree package not be part of the deployment, or GRUB_ENABLE_BLSCFG should not be set. Otherwise as you mention there would be two sections attempting to populate the GRUB menu. Although that shouldn't be an issue, it should just led to duplicated entries in the boot menu. Frank, Could you please share your grubenv? The attached file named grubenv is your /etc/default/grub.
The attached /boot/efi/EFI/fedora/grubenv is actually /etc/default/grub. Please reattached. I'm wondering if you're running into the GRUB menu autohide feature? By default, I'm not getting a grub menu at all either, that's intended and a feature since Fedora 29. https://fedoraproject.org/wiki/Changes/HiddenGrubMenu When I reboot with shift, I get a GRUB menu, but the GRUB menu does show duplicate menu entries. It appears to display both the ostree entries inserted into the grub.cfg, and the ostree conf entries in /boot/loader/entries.
Created attachment 1571712 [details] corrected version of grubenv
grubenv contains menu_auto_hide=1 so not seeing the GRUB menu is normal if boot is successful. If boot fails for some reason, the next boot will show the GRUB menu. You can test it by booting and at GDM login menu immediately reboot (within 2 minutes of GDM appearing, the boot will be marked successful), and that very next boot you should see GRUB menu. If you want to always see the menu, you need to disable menu autohide, the command is listed in the wiki URL in c9.
I followed these steps which gave a perfect result: I removed this part from the grub.cfg: ### BEGIN /etc/grub.d/10_linux ### ### END /etc/grub.d/10_linux ### Since I got this error: https://bugzilla.redhat.com/show_bug.cgi?id=1625124 I recreated my grubenv and unset the auto hide: sudo grub2-editenv create sudo grub2-editenv - unset menu_auto_hide Now there is a grub menu and entries are not doubled. The question is whether this will be permanent now or overwritten with the next update. I am just wondering because the grub.cfg contains the names of the current kernel and initramfs so I guess this file will be recreated by the next kernel update.
It's likely the next Silverblue update you do will cause grub.cfg to be recreated and it might have duplicate entries. But the auto hide should now be disabled and future updates won't affect that. There needs to be a realignment in Silverblue to account for all the latest changes in GRUB and blscfg.mod. Silverblue/rpm-ostree were ahead of conventional Fedora with BLS support. But now Fedora 30 releases (excluding rpm-ostree based systems) have leap frogged, and have essentially feature complete BLS support. My expectation is Fedora CoreOS is doing that realignment work first, and then the next Silverblue will be based on CoreOS.
I am stil wondering whether it is possible to remove all this grub nonsense by bootctl. My last attempt ended with a new installation. With "normal" Fedora it was never a problem (although some effort to maintain).
(In reply to Frank Ansari from comment #14) > I am stil wondering whether it is possible to remove all this grub nonsense > by bootctl. My last attempt ended with a new installation. With "normal" > Fedora it was never a problem (although some effort to maintain). With vainilla Fedora you can use systemd-boot because you have kernel-install scripts that generate the BLS snippets in the EFI System Partition, that's the only partition where systemd-boot can read from. But in the Silverblue (or any other ostree-based system) the BLS entries are not in the ESP but in /boot, so systemd-boot is not able to read them. So you may need to customize your system in order to have it working with sd-boot, see for example https://github.com/ostreedev/ostree/issues/1719.
(In reply to Frank Ansari from comment #12) > I followed these steps which gave a perfect result: > > I removed this part from the grub.cfg: > > ### BEGIN /etc/grub.d/10_linux ### > ### END /etc/grub.d/10_linux ### > > Since I got this error: > > https://bugzilla.redhat.com/show_bug.cgi?id=1625124 > > I recreated my grubenv and unset the auto hide: > > sudo grub2-editenv create > sudo grub2-editenv - unset menu_auto_hide > > Now there is a grub menu and entries are not doubled. > > The question is whether this will be permanent now or overwritten with the > next update. > > I am just wondering because the grub.cfg contains the names of the current > kernel and initramfs so I guess this file will be recreated by the next > kernel update. Chris already answered this in Comment 13. I just want to mention that ostree now supports a sysroot.bootloader config key, that went set to none it generates the BLS snippets but doesn't re-generate the grub.cfg (or that's what I understood at least). Take a look to https://github.com/ostreedev/ostree/pull/1814/ and https://www.mankier.com/5/ostree.repo-config
(In reply to Javier Martinez Canillas from comment #15) > (In reply to Frank Ansari from comment #14) > > I am stil wondering whether it is possible to remove all this grub nonsense > > by bootctl. My last attempt ended with a new installation. With "normal" > > Fedora it was never a problem (although some effort to maintain). > > With vainilla Fedora you can use systemd-boot because you have > kernel-install scripts that generate the BLS snippets in the EFI System > Partition, that's the only partition where systemd-boot can read from. > > But in the Silverblue (or any other ostree-based system) the BLS entries are > not in the ESP but in /boot, so systemd-boot is not able to read them. So > you may need to customize your system in order to have it working with > sd-boot, see for example https://github.com/ostreedev/ostree/issues/1719. OK - I have put a comment there.
(In reply to Javier Martinez Canillas from comment #15) > With vainilla Fedora you can use systemd-boot because you have > kernel-install scripts that generate the BLS snippets in the EFI System > Partition, that's the only partition where systemd-boot can read from. Out of the box, conventional/vanilla/non-ostree Fedora puts BLS snippets on the boot volume (by default ext4). They don't go on the ESP. With modifications it can be made to work. sd-boot prefers the ESP mounted on /efi (now supported by selinux, bug 1571962) but will also mount on /boot if /efi does not exist. This requires removing the ESP from fstab so systemd manages the mounting/unmounting of the ESP. If the ESP is mounted to /boot, then existing kernel install scripts will put kernels on /boot and BLS on /boot/loader/entries, both of which are on the ESP. But in the out of the box scenario, /boot/loader/entries is the same file system as /boot, which is ext4. It's still a bit confusing. Also, none of the systemd automatic mounting of the ESP works for GRUB, at the present time it must be sd-boot.
(In reply to Chris Murphy from comment #18) > (In reply to Javier Martinez Canillas from comment #15) > > > With vainilla Fedora you can use systemd-boot because you have > > kernel-install scripts that generate the BLS snippets in the EFI System > > Partition, that's the only partition where systemd-boot can read from. > > Out of the box, conventional/vanilla/non-ostree Fedora puts BLS snippets on > the boot volume (by default ext4). They don't go on the ESP. > That's the default yes, but there are two different kernel-install plugins that generate BLS snippets: /usr/lib/kernel/install.d/20-grub.install and /usr/lib/kernel/install.d/90-loaderentry.install. Which one is executed depends on the the system setup, 20-grub.install is executed if GRUB_ENABLE_BLSCFG is set to true and the grubby-deprecated package isn't install (new-kernel-pkg doesn't exist) and 90-loaderentry.install is executed if sd-boot is installed (bootctl install was executed). The 90-loaderentry.install plugins creates the BLS snippets in the path where the ESP was mounted (/boot/efi, /efi or /boot).
OK - now also on Silverblue I got rid of grub: https://discussion.fedoraproject.org/t/getting-rid-of-grub/1816
Based on Comment 12 the menu not being shown was expected due to the menu auto hide feature so that's not a bug. The other issue of the error message being shown was fixed in bug 1699761. So I'm closing this as NOTABUG.