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