Boot entries gone after upgrade

Project Discussion
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 Common F31 bugs - Fedora Project Wiki.

33

If I type “grub> normal” instead of pressing Esc I get to the longed for boot menu

34

here the logs:

blscfg-1
blscfg-12000×1304 920 KB

blscfg-2
blscfg-22000×1287 1.02 MB

35

Thanks, that was the missing bit!
I’ve booted the system.

36

I still have the problem that every time reboot i have to go through the process again to find my boot entries,
did you figure out how to solve it permanently once you get in to the operating system?

37

Do you have the blsdir variable set in the grubenv? If that’s the case you need to unset it (grub2-editenv - unset blsdir) and that might solve your issue if you are facing the same bug.

1 Like
38

Awesome thanks, that solved the problem