#13

@mzimmermann you are welcome and sorry for the inconvenience.

yes, my guess is that you did a SB 30 install (and that’s why you had GRUB_ENABLE_BLSCFG=true) and got hit by a grub2 bug in Fedora 30 that was preventing the menu entry to be populated from BLS when /boot/loader was a symlink (this got fixed quickly but since ostree doesn’t update the bootloader, the user needs to update it).

#14

That would explain it.

#15

I see, probably 30 if you had that config option set.

Kind of, the BLS snippets are used as the source of truth but were not used directly. Instead, they were parsed and a grub.cfg was generated adding a menuentry command for each BLS in /boot/loader/entries.

Now that grub2 has BLS support, this step was not needed anymore but changing that is what probably caused an issue for you due not having the latest version of grub2 with all the fixes for the blscfg module.

#16

I have the same problem and can’t use my computer (at work).
I’ve launched a Fedora live from USB but I can’t figure out how to access the files of my installation. I mean, I’ve opened the file manager and I could mount both the home and the root partition, but I can’t understand the root partition and find files. I’m new to OSTree… Can you give me some hint?

Also, I didn’t understand what’s the recommended fix: disabling BLS or updating the grub2 binary?

Quite annoyed by this bug… I thought OSTree was more stable than regular Fedora…

#17

I suppose a potential fix would be to copy the efi files from sysroot/ostree/deploy/fedora/deploy/*/usr/lib/ostree-boot/efi/EFI/fedora to the boot/efi/EFI/fedora folder.

You’ll have to mount the folders from your install.

This is a bug resulting from SB not updating the bootloader files (yet).

#18

Thanks but didn’t work. I can’t wait further, I’ll have to reinstall…

#19

Hi.
Have you checked the UEFI entries order? Maybe it just changed. You can check from a live media with efibootmgr or the boot menu key from your system. With efibootmgr you can change the order.

#20

For users hitting this issue, could you please check if your grubenv (in /boot/grub2/grubenv for legacy BIOS installs or /boot/efi/EFI/fedora/grubenv for EFI installs) has a blsdir variable set? If that’s the case, you should disable it with ‘sudo grub2-editenv - unset blsdir’

#21

Yes, it is. And that’s also the reason why OSTree doesn’t update the bootloader to make sure that regressions don’t happen in the boot path and can be fallback to the previous kernel and rootfs.

But the bootloader not being updated is what caused the issue in this case since it means that contains any bugs that were fixed during the F30 release.

#22

@pluto thank you for the chroot instructions!

@javierm my original installation was also 29 or 30, EFI dual booting with Windows.

#23

How can I run this command if I am looking at files in a mounted partition through a live disk?

Within the mounted partition I see a grubenv symlink to a missing grubenv file

# ls -l usr/lib/ostree-boot/grub2
total 4
lrwxrwxrwx. 3 root root   25 Apr 11 13:06 grubenv -> ../efi/EFI/fedora/grubenv


# ls -l usr/lib/ostree-boot/efi/EFI/fedora/
BOOTX64.CSV         grubx64.efi         shim.efi            shimx64-  fedora.efi
fonts/              mmx64.efi           shimx64.efi

but it may be in abinary file here

# grep -iR blsdir usr/lib/ostree-boot/efi/EFI/fedora/
Binary file usr/lib/ostree-boot/efi/EFI/fedora/grubx64.efi matches
#24

Cross-posting this here too:

It looks like people who used f30 install media with an older grub2 that can’t read from the /boot/loader symlink will hit the “no boot entries” issue after updating to f31. And I’m guessing a lot more people are going to hit this once f31 hits GA. My suggestion now is to:

  1. revert this patch (probably just in dist-git for now?)
  2. document double boot entries (and possibly just a manual workaround by setting GRUB_ENABLE_BLSCFG=false )
  3. enhance grub2-switch-to-blscfg , OSTree, and Anaconda as mentioned above
  4. publicize that grub2-switch-to-blscfg on FSB now works

Should do at least do (1) and (2) before GA, and we could do (3) and (4) later. Does that make sense?

1 Like
#25

That’s strange, the grubenv is supposed to be in the /boot/efi/EFI/fedora/ directory.

#26

@javierm I’m now playing with grub2 shell, as suggested in this article, and I can see the grubenv file in the /grub2 directory, which contains blsdir=/loader.0/entries.

#27

BTW, the entries - two .conf files - are actually in /loader.1. Is this also a bug?

#28

Yes, that’s exactly the bug I was talking about. That’s why I mentioned that you should unset the blsdir variable since that’s wrongly set (grub2-mkconfig getting confused about /boot/loader/ being a symlink).

#29

If you are in the grub shell, the following should work also:

grub> unset blsdir
grub> blscfg

Then pressing Esc should show you the boot menu.

1 Like
#30

Thanks. I run the two commands, but Esc doesn’t produce anything.

#31

You can get debug information about the blscfg command if you do set debug=blscfg and then run the blscfg command.

Maybe there’s more than one bug here, it would be good if you can test with the latest version of the grub2 efi binary as mentioned in a previous comment.

#32

Note we’re reverting the OSTree change in https://bodhi.fedoraproject.org/updates/FEDORA-2019-b7dfe3a592. As well, we’ve added it to the list of common bugs at https://fedoraproject.org/wiki/Common_F31_bugs#silverblue-iot-double-entries.