Use bootupd and remove ostree-grub2 (was: All deployments are shown twice in grub)

[YaLTeR]

Updated issue

Bootupd is now included and enabled by default on Atomic Desktops: https://fedoraproject.org/wiki/Changes/FedoraSilverblueBootupd

The duplicate entry part of this issue remains and will be fixed once we move to a static GRUB config. This should happen alongside the composefs migration. See: https://gitlab.com/fedora/ostree/sig/-/issues/35

---

Original issue

F33, ThinkPad T495s

[felipeborges]

I can reproduce this too.

[jlebon]

See https://fedoraproject.org/wiki/Common_F31_bugs#On_Fedora_Silverblue.2FIoT.2C_the_GRUB_menu_shows_duplicate_entries (I've added an "Update:" section there).

[YaLTeR]

See https://fedoraproject.org/wiki/Common_F31_bugs#On_Fedora_Silverblue.2FIoT.2C_the_GRUB_menu_shows_duplicate_entries (I've added an "Update:" section there).

So... should I migrate to BLS? If I should then maybe it should rather be done by default in Silverblue?

[jlebon]

So... should I migrate to BLS? If I should then maybe it should rather be done by default in Silverblue?

If you can, yes. I'm not sure if it's worth forcing a migration at this point because of the potential risks (see e.g. https://discussion.fedoraproject.org/t/boot-entries-gone-after-upgrade/8026). And as mentioned in the wiki, the migration script only works on EFI because it might not be safe to do it automatically on BIOS (see ostreedev/ostree#2044 (comment)).

[Jmennius]

What about systems that did not upgrade to F31 (clean install F31+)?
I did not find any place that creates /boot/grub2/.grub2-blscfg-supported for new installations.
I have BLS enabled (Silverblue) but there is no such file (probably this system started with F31).

I am also concerned that .grub2-switch-to-blscfg does not work well with https://fedoraproject.org/wiki/Changes/UnifyGrubConfig.

cc @jlebon @martinezjavier

[dustymabe]

I'm seeing this on a fresh install of F35 Silverblue. I guess we need to track down what used to create the /boot/grub2/.grub2-blscfg-supported and see why it's not getting created any longer.

[dustymabe]

Found it: https://src.fedoraproject.org/rpms/grub2/blob/9fdaa794e06846f1426bd15360401a8b1a5017a9/f/0065-Add-grub2-switch-to-blscfg.patch#_362

[jlebon]

I'm seeing this on a fresh install of F35 Silverblue. I guess we need to track down what used to create the /boot/grub2/.grub2-blscfg-supported and see why it's not getting created any longer.

I think... nothing ever actually created that for new installs. The idea we discussed was to have Anaconda do it, but it looks like we never actually followed through with it.

The other option is to just assume GRUB is new enough, but that can break people upgrading from an old install with old GRUB. The failure mode here is particularly bad: they'll get no boot entries.

Maybe we just need to be really loud about it and say that you need to make sure that your GRUB is up to date before $date using either the migration script or bootupd, and then we rip out this check.

[jlebon]

Maybe we just need to be really loud about it and say that you need to make sure that your GRUB is up to date before $date using either the migration script or bootupd, and then we rip out this check.

A prerequisite for that is of course to ship bootupd in FSB, which we currently don't.

[jlebon]

Yeah, I think bootupd is probably the cleanest path forward for this and for possible future issues like it. So my strawman is something like:

• add bootupd in FSB
• teach Anaconda to call out to bootupctl
• teach 15_ostree to read bootupd metadata to know if GRUB supports blscfg (but really, if bootupd metadata exists, it surely does, so this might just be test -f /boot/.bootupd-state.json)
• tell upgrading users that this bug is fixed in the latest bootloader, and they can update using bootupctl adopt-and-update

@cgwalters @martinezjavier WDYT?

[travier]

This might need a Fedora Change for F36 (Silverblue & Kinoite).

[martinezjavier]

@cgwalters @martinezjavier WDYT?

This makes sense to me. In fact, it would be great if even the non-ostree Fedora variants could adopt bootupd.

[travier]

The change deadline is mid January if we think this is a self contained change: https://fedorapeople.org/groups/schedule/f-36/f-36-key-tasks.html

[ormandj]

This would be quite a nice change - I was surprised to see the duplicate entries on a clean 35 Silverblue installation, and ran across this issue while researching resolution.

[travier]

How do all of you feel about trying to make that happen for F37 and maybe opt-in for F36 (ship bootupd but not enabled by default)? I can start the change request.