-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use bootupd and remove ostree-grub2 (was: All deployments are shown twice in grub) #120
Comments
I can reproduce this too. |
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? |
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)). |
What about systems that did not upgrade to F31 (clean install F31+)? I am also concerned that |
I'm seeing this on a fresh install of F35 Silverblue. I guess we need to track down what used to create the |
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. |
A prerequisite for that is of course to ship bootupd in FSB, which we currently don't. |
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:
@cgwalters @martinezjavier WDYT? |
This might need a Fedora Change for F36 (Silverblue & Kinoite). |
This makes sense to me. In fact, it would be great if even the non-ostree Fedora variants could adopt |
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 |
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. |
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. |
It was great to see @martinezjavier 's option and if he's in favor, then I'm as well. Thank you @travier for looking into this! |
SGTM, thanks for picking this up! |
It would be good to tackle this after the recent round of the grub2 CVEs. We might also need to fix coreos/bootupd#108 . But it looks like there was some work done by @cgwalters , but might be not finished - what's the current state of it Colin? |
I ran into this problem while debugging why firmware updates weren't applied. If anyone runs into the same issue, before there is a cleaner fix it's possible to update shim like this:
|
I'm not sure if
|
It's just so that rpm can write to the database, of course it will be discarded on next reboot, but the changes to /bin/efi will effectively be kept as they are not managed by ostree and as rpm reinstall the same version of the package, the content of the persistent database (the one managed by rpm-ostree) is now coherent with the content of /bin/efi. |
With https://pagure.io/workstation-ostree-config/pull-request/288, we now have bootupd in Rawhide but not enabled by default. Let's track what's missing here and make a Change request for F38. For reference, the commit message from Jonathan:
|
I executed the three lines that you mention in the above comment and when I now execute (after a reboot) |
Is this still in current Silverblue/Kinoite? I am not seeing it in either 39 or Rawhide, but if so what to look for? |
This is still planned to be included in F39 but not there yet due to https://pagure.io/workstation-ostree-config/pull-request/330#comment-190406 (the PR has been reverted). The test images (gitlab.com/fedora/ostree/ci-test) include this already. The Universal Blue images should as well. |
Pushed back to Fedora 40. Might come as an update to F39 if we backport the support. |
bootupd support in Anaconda got merged 🎉 |
@Verhoeckx Did you find any solution to this? I've just stumbled upon this error too. @travier Is this a problem? While I got the same error, |
With the new bootupd installation path in Anaconda, the `/etc/default/grub` config file is not written anymore as we are only using BLS configs with new enough bootloaders. We thus don't need to generate (duplicated) legacy boot entries. We still need to keep this logic in place in Atomic Desktops (Silverblue, etc.) until we've actually landed bootupd there and forced a bootloader update for everybody. See: fedora-silverblue/issue-tracker#530 See: fedora-silverblue/issue-tracker#120 See: https://fedoraproject.org/wiki/Changes/FedoraSilverblueBootupd
See #543 (comment) for a lightly tested set of commands to update your EFI bootloader until we have full bootupd support in Fedora Atomic Desktops. |
I'm confused 😕, did
Under the assumption |
I researched that exact question about deferral earlier today. I found at least one comment (I think on Bugzilla) that confirmed deferral to F41. I also noticed that most F40 docs fail to reflect that. |
I've updated everything to point to F41 as we did not land it in F40. We'll try to backport things to F40 as much as possible. |
Hello @travier, any update about the backport to F40? |
We can only consider backporting to F40 after it lands in F41. Status is tracked in https://gitlab.com/fedora/ostree/sig/-/issues/1 |
Remove ostree-grub2 to avoid issues with composefs. We can not remove it yet from the classic ostree ones as we need at least two Fedora releases where bootupd is included and enabled by default as a transition period to make sure we don't break users. See: https://gitlab.com/fedora/ostree/sig/-/issues/35 See: fedora-silverblue/issue-tracker#120 See: https://gitlab.com/fedora/ostree/sig/-/issues/1
With bootupd landing in Fedora 41, the first part of this issue is done. Now we have to wait for F42 to be able to remove the |
Nice work, folks. I just updated to Fedora Silverblue 41, and it looks like
|
F33, ThinkPad T495s
The text was updated successfully, but these errors were encountered: