feat(virtio-linux): EFI-bootable kernel + vmlinuz-efi output#208
feat(virtio-linux): EFI-bootable kernel + vmlinuz-efi output#208norrietaylor wants to merge 2 commits into
Conversation
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
📝 WalkthroughWalkthroughThis PR extends virtio-linux kernel packaging by adding EFI-bootable kernel support. The build script now defines architecture-specific EFI targets, configures the kernel with EFI options, builds both normal and EFI variants, and publishes them as separate outputs. The build specification declares the new EFI artifact. ChangesEFI bootable kernel support
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
OVMF launches the EFI-stub kernel with empty LoadOptions, so a built-in, forced cmdline is required or the kernel boots with no root= and panics. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
| # the in-VM agent (/sbin/init) in a later iteration. | ||
| $CFG --enable CMDLINE_BOOL | ||
| $CFG --set-str CMDLINE "console=hvc0 root=/dev/vda2 rootfstype=ext4 ro init=/sbin/stub-init" | ||
| $CFG --enable CMDLINE_FORCE |
There was a problem hiding this comment.
Baking the cmdline here ties this kernel to the VM-image disk convention (root=/dev/vda2, init=/sbin/stub-init). That's intentional for a purpose-built microVM kernel and needs zero extra packages.
The alternative, if this kernel ever needs to stay generic (multiple image variants with different cmdlines, an initrd, or secure/measured boot): drop CMDLINE* here and supply the cmdline at the image-assembly layer via a UKI — ukify/systemd-stub embeds a .cmdline section into the EFI binary, set per-image without recompiling the kernel. Costs a systemd-stub package (+ deps), so deferred until one of those needs it. init=/sbin/stub-init also becomes the in-VM agent (/sbin/init) later.
There was a problem hiding this comment.
You can typically also set the kernel command line when you load the kernel, so i guess most of the time this is mostly a default
|
|
||
| outputs = { | ||
| vmlinuz = { glob = "usr/share/virtio-linux/vmlinuz" } | OutputData, | ||
| vmlinuz_efi = { glob = "usr/share/virtio-linux/vmlinuz-efi" } | OutputData, |
There was a problem hiding this comment.
Do we want to just ship vmlinuz_efi and skip the non-efi one, if we need efi for minvmd?
2 participants
Makes the
virtio-linuxkernel directly EFI-bootable, so it can boot under EFI firmware (e.g. OVMF, as used bylibkrun-efi/krunkit) in addition to the existing direct-kernel-load VMMs.Changes:
CONFIG_EFI,CONFIG_EFI_STUB,CONFIG_ACPI,CONFIG_DMI,CONFIG_EFIVAR_FS— adds the PE/COFF EFI-stub entry point and the ACPI/DMI support EFI firmware needs. Additive: the kernel still boots qemu/cloud-hypervisor/firecracker unchanged.vmlinuz-efi: the EFI-firmware-bootable image (uncompressedImageon arm64, since OVMF cannot unwrapImage.gz; the samebzImageon x86). The existingvmlinuzis unchanged.CONFIG_CMDLINE_FORCE+console=hvc0 root=/dev/vda2 rootfstype=ext4 ro init=/sbin/stub-init). OVMF launches the EFI-stub kernel with empty LoadOptions, so without a built-in cmdline the kernel has noroot=and panics. This is a purpose-built microVM kernel for the Minimal VM image, whose disk convention is GPT { p1=ESP, p2=ext4 root } on/dev/vda— fair to bake.init=/sbin/stub-initis the current boot-verification entrypoint and becomes the in-VM agent (/sbin/init) later.Context: consumed by the
alpine-virtio-linuxpackage, which assembles an EFI-bootable GPT disk (ESP + ext4 root) that krunkit boots.Validation: validated end-to-end against krunkit 1.2.1 (libkrun-efi) on Apple Silicon — OVMF → kernel 6.12.43 → ext4 root → init. The
minimal buildCI check (external Linux build) is green, andminimal check --packages virtio-linuxpasses all 14 checkers locally (the artifact contains bothvmlinuzand the EFIvmlinuz-efi).