Skip to content

Switch to systemd-boot for raw-efi builds#4183

Merged
deitch merged 2 commits intolinuxkit:masterfrom
ChrisIgel:systemd-boot
Nov 9, 2025
Merged

Switch to systemd-boot for raw-efi builds#4183
deitch merged 2 commits intolinuxkit:masterfrom
ChrisIgel:systemd-boot

Conversation

@ChrisIgel
Copy link
Contributor

- What I did
Replaced grub with systemd-boot and make use of the systemd-efistub together with a UKI. Only for raw-efi and amd64 and aarch64 for now. Unfortunately, I could not keep the riscv64 support because alpine does not have systemd-boot packages built for riscv64. I'm not sure if this would be a dealbreaker or if we maybe could just compile them quickly ourselves.

Also I initially thought enabling CONFIG_EFI_STUB in the kernel would not be necessary because I made use of the systemd-efistub but without the configuration I get the following error during boot:

../src/boot/linux.c:120@linux_exec: Bad kernel image: Load error
../src/boot/boot.c:2640@image_start: Failed to execute LinuxKit (\EFI\Linux\linuxkit.efi): Load error

The PR is related to these two issues, with the latter one being the reason for this PR: #4123 #4125

- How I did it
I added a new tools package systemd-boot that contains the EFI stubs for both amd64 and aarch64. This is then used in the mkimage-raw-efi package instead of the grub image. Inside the make-efi script the grub config was replaced with a systemd-boot config and the kernel and initrd together with the cmdline were combined into a single UKI, that is then put into the ESP and is being auto-detected by systemd-boot.

- How to verify it
Build the new kernel (only necessary for amd64) and build a simple image with the kernel and with the raw-efi output. Let the resulting image run in UEFI mode, e.g. with:

linuxkit run qemu \
	--uefi \
	--fw /usr/share/ovmf/OVMF.fd \
	--cpus 2 \
	--mem 2048 \
	linuxkit-efi.img

If the resulting image is really small this PR would also be required for the file to be valid: #4139

- Description for the changelog
Replaced grub with systemd-boot for raw-efi output

@deitch
Copy link
Collaborator

deitch commented Oct 9, 2025

I really like this idea. I have been looking into systemd-boot and UKIs for other purposes, and would like to see them here.

A few points on this PR. Some will make it easier, some will make it more complex.

First, I don't think you need a tools/systemd-boot/. If all it does is extract the correct *.EFI for the given platform, then you can just take it FROM alpine in mkimage-raw-efi directly. That should save a bit of headache. You just would need to do the multi-platform thing so you have it for all target platforms, as mkimage-raw-efi could be built for (and run on) amd64 while building for arm64, or vice-versa, or for its own platform, etc.

The reason we have a separate grub package, is because we need to create the artifacts in grub-dev grub-mkimage -O arm64-efi, etc., and then someplace just to get them, and it gets used in multiple places downstream.

On the other hand, if you want to build it from source so you have it for riscv64 (assuming that is doable?), then a separate package is the way to go.

Next, alpine. Updating alpine is a bit of a pain. It cannot just be updated in tools/alpine, there is a process for it, and everything downstream needs to be updated. It is documented.

Finally, kernel. It needs more than just updating the config. There is a process for updating kernel config, documented here, but it is easier to do so in the context of a new kernel version, documented here.

Unfortunately, each of those steps is some work. I would suggest handling each one in a separate PR:

  • update the kernel version (do the latest 6.6 version, or even 6.x) to include the changes you need
  • update alpine to include the packages
  • consume both of the above

@ChrisIgel
Copy link
Contributor Author

Yeah I know alpine and the kernel need more work for the full update. I just wanted to outline my ideas and the required changes without all the noise the other changes would introduce.
I could try the riscv64 build but for me personally it would not be of importance/relevance. If it's like a 10 minute thing I'll do it though.

@ChrisIgel ChrisIgel force-pushed the systemd-boot branch 4 times, most recently from bbda9f9 to 365b4eb Compare October 11, 2025 15:20
@ChrisIgel
Copy link
Contributor Author

I think the building for riscv64 works. I just have no real way of verifying it works / is correct other than maybe using qemu.

I'll update the kernel and the alpine next, now that I know what packages I really need and where I need them.

@deitch
Copy link
Collaborator

deitch commented Oct 27, 2025

And of course, I commented on the wrong PR.

@ChrisIgel
Copy link
Contributor Author

I rebased the PR on the newest version with our alpine and kernel changes.

Copy link
Collaborator

@deitch deitch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I rather like this. Should existing tests cover it? I would think so.

Can you describe what the filesystem layout looks like before and after? I can kind of reverse-engineer it from the make-efi code, but better to be explicit. Maybe a quick README in mkimage-raw-efi would be helpful.

Also, what other build formats would benefit from this?

@ChrisIgel
Copy link
Contributor Author

ChrisIgel commented Nov 3, 2025

I rather like this. Should existing tests cover it? I would think so.

I think I'd actually write an additional test for raw-efi. Maybe similar to the 020_run_efi one.

Can you describe what the filesystem layout looks like before and after? I can kind of reverse-engineer it from the make-efi code, but better to be explicit. Maybe a quick README in mkimage-raw-efi would be helpful.

Yeah sure, I'll add it.

Also, what other build formats would benefit from this?

I think basically everything that targets efi. Also the aws one.

Signed-off-by: Chris Irrgang <chris.irrgang@gmx.de>
Signed-off-by: Chris Irrgang <chris.irrgang@gmx.de>
@ChrisIgel ChrisIgel marked this pull request as ready for review November 3, 2025 23:37
Copy link
Collaborator

@deitch deitch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great!

@@ -0,0 +1,32 @@
#!/bin/sh
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a lovely and simple test.

sfdisk \
sgdisk \
xfsprogs \
py3-pefile \
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The purist in me is bothered by this. ukify is there for building low-level early-stage binaries, so why does the tool itself have to be Python (to which I don't object in general)? But I also need to be practical.

@deitch
Copy link
Collaborator

deitch commented Nov 9, 2025

And CI is clean, including your tests. Happy to merge it in, and thank you for your patience.

@deitch deitch merged commit 56e37a8 into linuxkit:master Nov 9, 2025
25 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

Comments