Repository navigation
fix(test): boot the UKI from an ESP under OVMF, not qemu -kernel - #84
Merged
Merged
Conversation
qemu-run.sh and the Phase 1 integration harness booted the UKI with
qemu -kernel <uki>. -kernel uses the Linux bzImage boot protocol, but a UKI is
a PE/EFI executable, so OVMF rejects it ("Bad kernel image: Load error") and
the node never boots. Present the UKI the way firmware expects instead: on a
FAT EFI System Partition at the removable-media fallback path
EFI/BOOT/BOOTX64.EFI (served via QEMU VVFAT, fat:rw:<dir>), which OVMF
auto-launches. Drop the -kernel flag.
Verified under OVMF: the UKI now loads and executes (BdsDxe starting Boot0001,
no load error) where -kernel previously failed. Full ceremony e2e additionally
needs QEMU guest drivers (serial/virtio-net), tracked in #33.
Closes #74
Contributor
Author
|
Closing summary: qemu-run.sh and the integration harness now boot the UKI from a FAT ESP (EFI/BOOT/BOOTX64.EFI via QEMU VVFAT) instead of qemu -kernel, which OVMF rejected as a non-bzImage. Verified: OVMF now loads and starts the UKI under TCG with no 'Bad kernel image' error. Full ceremony e2e still needs QEMU guest drivers (serial/virtio-net), tracked in #33. |
Bugs5382
added a commit
that referenced
this pull request
Sep 25, 2026
qemu-run.sh and the Phase 1 integration harness booted the UKI with
qemu -kernel <uki>. -kernel uses the Linux bzImage boot protocol, but a UKI is
a PE/EFI executable, so OVMF rejects it ("Bad kernel image: Load error") and
the node never boots. Present the UKI the way firmware expects instead: on a
FAT EFI System Partition at the removable-media fallback path
EFI/BOOT/BOOTX64.EFI (served via QEMU VVFAT, fat:rw:<dir>), which OVMF
auto-launches. Drop the -kernel flag.
Verified under OVMF: the UKI now loads and executes (BdsDxe starting Boot0001,
no load error) where -kernel previously failed. Full ceremony e2e additionally
needs QEMU guest drivers (serial/virtio-net), tracked in #33.
Closes #74
Co-authored-by: Bugs5382 <12115015+Bugs5382@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What and why
build/ci/qemu-run.shand the Phase 1 integration harness booted the UKI withqemu -kernel <uki>.-kerneluses the Linux bzImage boot protocol, but a UKI is a PE/EFI executable, so OVMF rejects it withBad kernel image: Load errorand the node never boots. This presents the UKI the way firmware expects: on a FAT EFI System Partition at the removable-media fallback pathEFI/BOOT/BOOTX64.EFI(served via QEMU VVFAT,fat:rw:<dir>), which OVMF auto-launches. Drops the-kernelflag in both places.Verification
gofmtclean;go vet -tags=integration ./test/integration/...compilesbash -nclean onqemu-run.shBdsDxe: starting Boot0001with noBad kernel image: Load error— where the-kernelmethod previously failed at exactly that pointNote
This fixes the boot method. Full first-boot ceremony e2e (guest reaches PID 1, brings up
eth0, serves gRPC on :443) additionally needs QEMU guest drivers (serial console, virtio-net) in the kernel config — deferred hardware/driver work tracked in #33.Closes #74