-
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
Dual boot support for bootupd with static GRUB config installations #530
Comments
Looks like it failed because it used a previous commit without bootupd installed thus anaconda could not detect it and use the new bootupd aware installation method. We'll give it a try again now that the compose build failures should be fixed. |
No, that diagnosis definitely does not sound right. I checked the last pass and first fail in openQA when this started happening, and bootupd being present in the ostree is exactly the difference: bootupd was not in the ostree in the last pass, and was in the ostree in the first failure. anaconda uses exactly the presence of bootupd in the ostree as its basis for deciding whether to go down this path at all: rhinstaller/anaconda@8e690d5 if bootupd isn't there, it won't go down this path, it will use its conventional bootloader install code. And the openQA test builds an ostree before it builds the ostree installer image. It cannot really 'use an old ostree' like the compose process can, it doesn't have any. The only ostree it can use is the one it builds. If that step fails, the test will die and never reach the ostree installer build phase. |
The ISO I uploaded for testing is from this openQA test. If you check its ostree build log, you will see bootupd listed there. |
Ah thanks, I had missed that this was from an image built during the openqa test run. Then this likely means that we'll have to do another Anaconda fix. CC @jkonecny12 |
I see. I wonder how to resolve this. I guess we need to add a check if it is container source? |
I wonder @travier should we use the |
Also would it be possible to remove We are currently over capacity, if possible we need to minimize our work. |
We don't have that option as the same manifests are used for both.
The goal of https://fedoraproject.org/wiki/Changes/FedoraSilverblueBootupd is to fix:
We've reverted the change so it's not in right now, but it's a core part of the Ostree Native Containers work. |
@AdamWill could you please provide us the ISO which were failing? We need something to debug the issue. |
I already did, in the initial issue description, where it says "Get or build a Silverblue installer image containing an ostree with bootupd enabled, like this one". |
I see now, I guess I'm just blind :( . Thanks! |
|
😕 |
🤔 |
🤔 🤔 🤔 |
OK, this is gone in latest Rawhide commits as well so this is not a bootupd issue. |
Somehow, this file is not installed anymore: https://src.fedoraproject.org/rpms/grub2/blob/rawhide/f/grub2.spec#_436 |
Hum, it's not there on my F39 system either. |
OK, it's anaconda writing this file in the GRUB2 installation path and likely not in the bootupd one: https://github.com/rhinstaller/anaconda/blob/c0d803edeeb8d7797492250353e52180f5ad6a33/pyanaconda/modules/storage/bootloader/grub2.py#L253 |
CC @jkonecny12 |
I suspect rhinstaller/anaconda#5350 |
OK, so we need to setup this config but only if the legacy ostree GRUB hooks/config are there (the ones that we want to remove after this change lands and people have time to update their bootloaders). |
Or we can update this condition / check here: https://github.com/ostreedev/ostree/blob/main/src/boot/grub2/grub2-15_ostree#L31 |
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
Not 100% sure yet if my understanding is correct but made: ostreedev/ostree#3150 |
you're correct that anaconda writes it, here. The thing that is AAANYHOOO, what's actually happening here is that all of this is getting skipped because we hit a check in |
Thanks for digging 🕳️ into this! |
I've verified that ostreedev/ostree#3150 fixes the installation |
And I've tested basic bootupd function as well! Will try an update now. |
Adding bootupd to a payload currently also defaults to But IMO, the right way to handle Windows at least is via the EFI bootloader, not grub. Having new desktop (silverblue, etc.) installs use bootupd in this way will be awesome because it will align everything and work the same way as FCOS and how bootc does it. But...transitioning old installs seems tricky and potentially risky. |
Considering that we "already" have dual booting issues on Silverblue (#284), I'm tempted to say that we'll not fix this for Fedora 40. We should be able to document adding a Windows boot entry to the static GRUB config for new installations. As we're not force upgrading users (yet), systems that were installed before will keep the dynamic GRUB configs for now. |
Now that we're building using unified core and that Anaconda has support for bootupd, we can enable bootupd in Silverblue & friends. See: https://fedoraproject.org/wiki/Changes/FedoraSilverblueBootupd See: https://fedoraproject.org/wiki/Changes/FedoraSilverblueUnifiedCore See: fedora-silverblue/issue-tracker#530 Previous attempts: - https://pagure.io/workstation-ostree-config/pull-request/288 - https://pagure.io/workstation-ostree-config/pull-request/293 - https://pagure.io/workstation-ostree-config/pull-request/307 - https://pagure.io/workstation-ostree-config/pull-request/313 (revert) - https://pagure.io/workstation-ostree-config/pull-request/330 - https://pagure.io/workstation-ostree-config/pull-request/402 (revert) - https://pagure.io/workstation-ostree-config/pull-request/403 - https://pagure.io/workstation-ostree-config/pull-request/452 (revert) This reverts commit 148b6d2.
I've tested installing Fedora Silverblue 37, updating all the way to 39 then rebasing to Rawhide and adopting using |
Great work @travier! Sorry that I wasn't able to help you more :(. I wonder what is the correct behavior here... Should Anaconda create the |
For bootupd installations, we don't need anaconda to create this file right now as we will use a static GRUB config and BLS to get the ostree boot entries. This will not generate boot entries for Windows, etc. for dual boot but we already don't have that working well so it's not a great loss. I'll try to document how to manually add boot entries for Windows & Co. |
Related to ostreedev/ostree#3198 for GRUB static config + dual boot with composefs enabled. |
Similar error happened to me by following QA:Testcase dualboot with macOS with the Silverblue 41 ISO (using Fedora Media Writer) on an Intel-based MacBook Pro (2017).
|
Make sure to use a distinct, empty /boot & /efi partitions for the Silverblue installation. |
bootupd & static GRUB configs don't support dual boot yet.
Previous title: Install of Silverblue installer image with bootupd enabled fails due to grub2-mkconfig failure
Describe the bug
After https://pagure.io/workstation-ostree-config/c/ad61c4d56e45eef8a7ac8af47f72fb4f463892e9?branch=main landed and the openQA ostree installer test started generating ostrees with bootupd, install of the Silverblue image built around the ostree started to fail. The
ostree admin instutil set-kargs
command that is run to configure the kernel args on the bootupd path fails, apparently because agrub2-mkconfig
command it runs fails. It does not tell me why the grub2-mkconfig run fails.To Reproduce
Please describe the steps needed to reproduce the bug:
Expected behavior
The install should complete successfully.
Additional context
I tried reproducing the issue locally, then switching to a VT and running the failing
ostree admin instutil set-kargs
command locally, afterchroot /mnt/sysroot
. That does indeed fail, with the errorerror: Bootloader write config: grub2-mkconfig: Child process exited with code 1
. It does not pass along anything about the grub2-mkconfig failure, and/mnt/sysroot
is read-only so I can't do any hacks to try and get the output from grub2-mkconfig dumped anywhere, really. If I run theostree
command with-v
it gives me more verbose output before the grub2-mkconfig command fails, but nothing more useful about the actual failure:@travier has reverted the bootupd change once more for now, but we should figure out the failure so it can be turned on. Again.
The text was updated successfully, but these errors were encountered: