#9

@mzimmermann thanks for the information. I wonder how you had GRUB_ENABLE_BLSCFG=true since BLS wasn’t the default in Fedora 28 and 29 (one of the versions you said that installed) and according to @jlebon the /etc/default/grub file shouldn’t be updated on a ostree deployment.

I also wonder why you didn’t have a grubenv and grub.cfg in your ESP.

#10

@pluto and @tpb was this on an EFI or legacy BIOS install? Also, do you remember what Silverblue version was initially installed?

#11

First of all, thank you very much for your help!

I wonder how you had GRUB_ENABLE_BLSCFG=true since BLS wasn’t the default in Fedora 28 and 29 (one of the versions you said that installed)

This is not my main machine, and I started with SB 28. I guess then I did a clean reinstall of SB 30 and forgot about it…

I also wonder why you didn’t have a grubenv and grub.cfg in your ESP.

I am also not 100% sure, because I fiddled around with it quickly after the error occured. I am sorry that I can only provide such unreliable and incomplete information… =/

BTW: I have also decided to go with a clean reinstall to fix this issue.

#12

EFI. I started using SB on said computer when Nvidia support got added so a late 29 build or beta 30 build.

This too was in my config. If it’s any help, I did have osprober disabled as it prevents ostree-finalize-staged from taking forever on systems that have a Bitlockered Windows on another drive.

Instead of using /mnt as a chroot directory, use /mnt/ostree/deploy/fedora/deploy/<deploy id>. You’ll need to mount the dev, proc, /boot etc there too.

rpm-ostree won’t work, but grub-install does.

I thought my computer was already using BLS, based on the /boot/loader/entries

#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).