composefs: Fix uki boot with grub2 on fedora aarch64 - #2527
alexlarsson wants to merge 1 commit into
Conversation
In Fedora 44 (at least), the grub2 EFI binary for aarch64 doesn't include the chainloader module (but the x84 one does). We insmod this in our menu files, which means we get this at boot: ``` error: ../../grub-core/fs/fshelp.c:find_file:257:file `/grub2/arm64-efi/chain.mod' not found. error: ../../grub-core/script/function.c:grub_script_function_find:119:can't find command `chainloader'. ``` In general, we don't know what modules are built in for any particular bootc image, so to be safe we copy all the modules we're using (that exist) into /boot/grub2. Signed-off-by: Alexander Larsson <alexl@redhat.com>
| // The menu config files insmod some modules, these may be either built | ||
| // into the GRUB EFI binary, or loaded from /boot/grub2. For example, the | ||
| // fedora aarch64 grub doesn't include chain.mod. We install all the modules | ||
| // we can find to avoid potential problems. |
There was a problem hiding this comment.
This should be bootupd's job
There was a problem hiding this comment.
How can bootupd know that we're using these particular grub modules though? Maybe it should copy all modules?
There was a problem hiding this comment.
I guess it could copy all modules? Its not that big anyway.
There was a problem hiding this comment.
Right now if a static grub config is used (which is the default for bootupd) that static config is embedded in that package. And that static config should certainly include or install modules it needs.
I really want to avoid having bootc know too many details of grub because it's a huge mess, that stuff should get squirreled away in bootupd so we can keep this project kind of detached from the reality of the so many years of technical debt.
One hope is that grub-cc fixes some of this.
But actually though,
fedora aarch64 grub doesn't include chain.mod.
Isn't that just something to fix there?
I mean let's at least weigh options like that
There was a problem hiding this comment.
Honestly, i think for fedora we should probably fix it in the grub build. However, we might want to support non-fedora bootc images that aren't built that way? I'll have a look at the bootupd side.
There was a problem hiding this comment.
I filed a fedora bug, lets see what they think: https://bugzilla.redhat.com/show_bug.cgi?id=2545182
There was a problem hiding this comment.
Here is the bootupd version of this: coreos/bootupd#1165
|
OK closing as I think we're in agreement the fix lives in one of the other two places. |
|
We had a live chat about testing and ARM and just to followup on that more: I think we absolutely should have some booting tests on ARM run by default; our main test suite relies on nested virt which is cheap and works well. Problem is GHA doesn't support nested virt on ARM (because Azure doesn't). Though CNCF has sponsored cloud credits we could use in some clouds to use "metal" instances which would. There's also the "reprovision existing system" path or minting new cloud images - all of these would make sense to test in postsubmits. That said, zooming out a little bit, in my opinion this is really CI that should primarily be with the the operating system, not bootc. Again knowing about grub modules is not something I think bootc should be doing, and the chance that we somehow break something only on aarch64 is certainly nonzero, but it's IMO not very high either. Our Packit/TMT testing is doing reprovisioning on ARM, but probably not yet transitioning to a UKI. It would likely be doable. A key thing is that at least midstream Fedora CI pipelines etc could speak TMT, giving us a way to reuse the tests there outside of GHA (ideally in Konflux). |
2 participants
In Fedora 44 (at least), the grub2 EFI binary for aarch64 doesn't include the chainloader module (but the x84 one does). We insmod this in our menu files, which means we get this at boot:
In general, we don't know what modules are built in for any particular bootc image, so to be safe we copy all the modules we're using (that exist) into /boot/grub2.