Duplicated GRUB entries on Silverblue/Kinoite

See How to delete old deployments in Silverblue - Ask Fedora

I think there might be a problem with how the grub.cfg is being generated. I see duplicated grub entries in my system, and 2 fresh VM installs:

The first 2 options work, but the second set give an error if selected:

I traced it back to /etc/grub.d/15_ostree generating these last 2 entries, which I think is in error? Seems like the codepath from this patch to generate the hidden file /boot/grub2/.grub2-blscfg-supported isn’t being created. Manually creating that hidden file fixes it on my system.

I’m wondering if this is actually a bug, or if it’s working as intended?

Edit: Everything above applies to UEFI-based systems/VMs. Just tried it on a BIOS VM and although the same duplicated items appear, the second set are actually usable/don’t error out in that BIOS VM.

I can confirm the copy of the menu entries in a standard BIOS booted Fedora Silverblue bare metal install will boot the system. I am now using a UEFI based BIOS, and haven’t tried to boot a duplicate entry. This seems to happen when layer(ed) packages get updates, I don’t see it after every time I update, just occasionally.

As for my VMs, they are clean installs with no layered packages, so I don’t think that is related (at least for my cases).

That would appear to be the case indeed. In mine it doesn’t always happen after an update requiring a reboot, but sometimes. I should pay closer attention to what could be the issue at those times and check the boot log perhaps.

I admit I don’t recall where I found the bulk of the logic for this snippet (maybe a discussion on Github or the like?), but I have this in my post-install script after I do my Kickstart-initiated Silverblue or Kinoite installs. Basically the first block runs if you’re on an EFI system, and otherwise it runs the second block. I haven’t done a build in about a month, but it works on all of the workstations I build anyway. Obviously give it a go on a VM or unimportant system first to make sure it behaves as you expect.

if [ -d /sys/firmware/efi ]; then
  grub2-switch-to-blscfg
  grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
else
  block_device=$(lsblk -spnlo name $(grub2-probe --target=device /boot/grub2) | tail -n1)
  grub2-install $block_device
  touch /boot/grub2/.grub2-blscfg-supported
  grub2-mkconfig -o /boot/grub2/grub.cfg
fi
1 Like

I traced it back to /etc/grub.d/15_ostree generating these last 2 entries, which I think is in error? Seems like the codepath from this patch to generate the hidden file /boot/grub2/.grub2-blscfg-supported isn’t being created. Manually creating that hidden file fixes it on my system.

I’m wondering if this is actually a bug, or if it’s working as intended?

I’ve no proof, but my hunch is that behavior is a bug. It seems like BLS capability should be detected and that /boot/grub2/.grub2-blscfg-supported should also be written in the case of a UEFI system.

I need to test, but recently I had issues writing a new grub.cfg on my own UEFI hardware. My system was not detected as a UEFI system, and linux16 and initrd16 lines ended up in my grub.cfg.

I ended up using…

# WITH_MODERN_GRUB=1 grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

…In order to get a valid UEFI grub.cfg created (full story: 1, 2, 3).

That said WITH_MODERN_GRUB=1 is currently exported as a global variable on my system, so I want to bar it from instantiation and reboot to test adding /boot/grub2/.grub2-blscfg-supported (which is not currently present).

Okay, so I’ve tested with /boot/grub2/.grub2-blscfg-supported present and without:

Without

# grub2-mkconfig > grub-without-blscfg-file-present.cfg

# grep -E '(linux|initrd)16' grub-without-blscfg-file-present.cfg
 
linux16 /ostree/fedora-06001f603ad4e290e14fc32c517a16e13cef2ac16a38759e3434cef52c8dda8b/vmlinuz-5.15.7-200.fc35.x86_64 rd.luks.uuid=luks-8c20fbb2-ff0e-4192-a004-cccfa09f53c8 radeon.cik_support=0 amdgpu.cik_support=1 root=UUID=b3d495a2-c874-472a-85ff-32d4bec26119 rootflags=subvol=@ ostree=/ostree/boot.1/fedora/06001f603ad4e290e14fc32c517a16e13cef2ac16a38759e3434cef52c8dda8b/0
initrd16 /ostree/fedora-06001f603ad4e290e14fc32c517a16e13cef2ac16a38759e3434cef52c8dda8b/initramfs-5.15.7-200.fc35.x86_64.img
linux16 /ostree/fedora-0ce6da105f3a3d5c717d7b0b0d6864a61b215fa60c9b53c50f752d59f82d04af/vmlinuz-5.15.6-200.fc35.x86_64 rd.luks.uuid=luks-8c20fbb2-ff0e-4192-a004-cccfa09f53c8 radeon.cik_support=0 amdgpu.cik_support=1 root=UUID=b3d495a2-c874-472a-85ff-32d4bec26119 rootflags=subvol=@ ostree=/ostree/boot.1/fedora/0ce6da105f3a3d5c717d7b0b0d6864a61b215fa60c9b53c50f752d59f82d04af/0
initrd16 /ostree/fedora-0ce6da105f3a3d5c717d7b0b0d6864a61b215fa60c9b53c50f752d59f82d04af/initramfs-5.15.6-200.fc35.x86_64.img

With

# touch /boot/grub2/.grub2-blscfg-supported
# grub2-mkconfig > grub-with-blscfg-file-present.cfg
# grep -E '(linux|initrd)16' grub-with-blscfg-file-present.cfg

no output

So @guiltydoggy, it does seem like /boot/grub2/.grub2-blscfg-supported ought to be created by default on UEFI systems… :man_shrugging:

Definitely related; though not sure where this piece fits: grub2: Exit gracefully if the configuration has BLS enabled by martinezjavier · Pull Request #1929 · ostreedev/ostree · GitHub

EDIT 1: okay still reading, but this thread seems to give the full contexts about the double entries.

EDIT 2: not a bug…

Something that I forgot to mention is that only changed the grub2-switch-to-blscfg script to update the GRUB bootloader and drop the hidden .grub2-blscfg-supported file for EFI machines.

This is because updating GRUB for legacy BIOS machine is more error prone (e.g: users may be using the GRUB from another distro, don’t want their MBR bootstrap code area to be overwritten, etc).

So I would prefer for legacy BIOS users to do this explicitly by running grub2-install and creating the /boot/grub2/.grub2-blscfg-supported file themselves.

1 Like