SB42 updates fail on system with 512MB /boot, 128MB /boot/efi

Ask Fedora
,
21

I’ve rebased quite early each cycle on this system. Very well possible that it picked up some weirdnesses. On the other hand, this is a great testament to the stability of Silverblue :party:

1 Like
23

So the part that is missing is:

insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root <UUID for /boot partition>
insmod part_gpt
insmod fat
search --no-floppy --fs-uuid --set=boot <UUID for EFI partition>

insmod blscfg
blscfg

which is normally in:

### BEGIN /etc/grub.d/10_linux ###

### END /etc/grub.d/10_linux ###

So you should add that there, using the UUID from sudo blkid.

Watch out because the naming is unexpected. GRUB says root for the /boot partition and boot for the EFI partition.

Make sure to make a backup of your GRUB config before making any change and have a LiveISO of Fedora Workstation ready in case you need to edit things again / revert to the backup.

Hope this will fix the issue.

1 Like
24

Hi @siosm,

Adding this part to /boot/efi/EFI/fedora/grub.cfg and rebooting fixes the issue of the grub menu entries not showing newer deployments. Just updated and indeed the newest deployment is shown as well. The workaround is showing a curious behaviour, Grub is now listing all deployments since the 41.20250216. 4 in total, with 2 of them unbootable, which is expected.

I’ve just rebased my desktop (which is a system started with Silverblue 34) and it’s not showing any issue and was auto migrated to (or always was) a very sleak 4 line grub.cfg on the ESP.

One thing I noticed is that GRUB_ENABLE_BLSCFG is true for the unaffected system and false for the affected system. Shall I do the migration steps manually for the affected system?

1 Like
25

The workaround is showing a curious behaviour, Grub is now listing all deployments since the 41.20250216. 4 in total, with 2 of them unbootable, which is expected.

It’s not an endless list. Grub will always list two dead entries, in my case 41.20250216 and 42.20250216 - the two deployments from before the manual edit. and the two latest deployments - in sync with ostree.

1 Like
26

That certainly can be a factor since one is using blscfg and the other is not.

27

Grub will always list two dead entries, in my case 41.20250216 and 42.20250216 - the two deployments from before the manual edit. and the two latest deployments

Maybe you can try to replace GRUB_ENABLE_BLSCFG=false to GRUB_ENABLE_BLSCFG=true in /etc/default/grub, and run sudo grub2-mkconfig -o grub.cfg to see if the dead entries are gone and ### BEGIN /etc/grub.d/10_linux ### part is expected (according to comment) in the new generated grub.cfg.

If the file looks good and then backup the cp /boot/efi/EFI/fedora/grub.cfg /boot/efi/EFI/fedora/grub-bak.cfg, and replace /boot/efi/EFI/fedora/grub.cfg with the new generated grub.cfg.

28

Hi @hhei,

setting GRUB_ENABLE_BLSCFG=true manually, then run sudo grub2-mkconfig -o grub.cfg leads to a /usr/bin/grub2-probe: error: failed to get canonical path of 'composefs'. error.

$ cat /etc/default/grub
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="rhgb quiet"
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true
GRUB_DISABLE_OS_PROBER=true

$ sudo grub2-mkconfig -o grub.cfg
/usr/bin/grub2-probe: error: failed to get canonical path of 'composefs'.
$ sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub-candidate.cfg
/usr/bin/grub2-probe: error: failed to get canonical path of `composefs'.
29

Sorry that I remembered Timethee said grub2-mkconfig does not work well with composefs, see 2308594 – dynamic grub2-mkconfig incompatible with composefs

In this case, could you help confirm the good entries are under /boot/loader/entries/*.conf and the dead entries are in

### BEGIN /etc/grub.d/15_ostree ###

### END /etc/grub.d/15_ostree ###

If yes, I think can remove the dead entries safely as you already have the latest good entries which are saved in /boot/loader/entries/.

1 Like
30

Using Colin’s patch from 2308594 grub2-mkconfig generates a grub.cfg without an 15_ostree block and their dead entries. There are some additional comments and a fallback generated for an empty kernelopts. No other diffs, the generated grub.cfg looks good and functional.

@siosm I’ll not do a manual migration and leave this system as an eventual tester for Static GRUB config migration does not handle GRUB configs stored in ESP · Issue #857 · coreos/bootupd · GitHub

2 Likes
31

Yes, this is likely the source of your issue here.

You can safely delete the stale entries from your grub config between:

### BEGIN /etc/grub.d/15_ostree ###

### END /etc/grub.d/15_ostree ###

This will be fixed once we do Static GRUB config migration does not handle GRUB configs stored in ESP · Issue #857 · coreos/bootupd · GitHub.

32

Your system should be migrated already since SB42 updates fail on system with 512MB /boot, 128MB /boot/efi - #8 by mershl.

I should be able to reproduce this now that we know what triggered it (disabled BLSCFG in grub default config file).

1 Like