Your browser sucks, JavaScript disabled! Gunnar's console needs JavaScript and WebAssembly. Git over SSH on port 2222 does not.

nordisk/edda

crates/storage-git-gix/parked-gix/assets/boot/README.md

korp-boot-bootx64.efi — where it comes from and why it is here

This 5 120-byte PE is the first-stage UEFI loader the appliance ISO puts at EFI/BOOT/BOOTX64.EFI. It is not gunnar's code and it was not written for gunnar. It is built from

/home/rickard/git/edda/crates/korp-installer/boot/korp-boot-efi

— korp-boot, the production first stage of the korp appliance, no_std, zero external crates, raw COM1 output plus the handful of UEFI Boot Services entries needed to read a file and start an image. Rebuild and re-vendor it with

cd ../edda/crates/korp-installer/boot/korp-boot-efi
cargo build --release --target x86_64-unknown-uefi
cp target/x86_64-unknown-uefi/release/bootx64.efi \
   ../../../../gunnar/assets/boot/korp-boot-bootx64.efi

Vendored at sha256 cd321e2d5709f69941436743dc4eb4a0dbedace9d9f9ac3109b2eadc4f0fcfec, 2026-08-03.

Why vendored rather than built from ../edda

Two rules point in opposite directions and this is where they meet.

LAW 5 — reuse, do not twin. A second UEFI chainloader written inside gunnar would be six hundred lines of unsafe duplicating something that already exists and is already proven booting in KVM (edda/crates/korp-installer/tests/first_stage_boot.rs, and the reboot-into-korp end-to-end test in dwarves). Writing one would be exactly the duplication LAW 5 forbids, in the riskiest code in the tree.

Gunnar must build standalone from a fresh clone. .nornir/appliance-design.md and crates/gunnar-cli/Cargo.toml both say it: no path dependency on a sibling checkout, not even for a convenience. cargo xtask iso on a machine with no ../edda must still produce a bootable ISO.

Vendoring the artefact satisfies both. It is also the pattern the rest of the fleet already uses for this exact file — dwarves/dwarves-demo/src/embedded/ carries the same loader as a committed blob, regenerated by an xtask.

What it does

  1. EFI_LOADED_IMAGE_PROTOCOL gives it the handle of the volume it was booted from, so nothing depends on an NVRAM Boot#### entry or a disk index.
  2. Reads the kernel command line from \korp\cmdline on that same volume. cargo xtask iso writes that file; there is no compiled-in gunnar configuration anywhere in this binary.
  3. LoadImage on a device path rooted at that volume, so the kernel's own EFI stub can resolve initrd=\initrd off the same FAT.
  4. Writes the command line into the loaded image's LoadOptions and StartImage.

Every failure prints one KORP-BOOT: FAILED <step>: … line on COM1 and halts. There is no path on which it returns success without having started the kernel, which is what makes the serial log in cargo xtask iso --prove evidence rather than decoration.