piCore64's BusyBox segfaults under QEMU virt with -cpu cortex-a72, generating
an EL0 Instruction Abort (el0_ia in the panic call trace). The binary is built
with ARMv8 extensions (likely +lse atomics, +crypto, or +fp16) that the
cortex-a72 model doesn't enable by default.
Switch to -cpu max which enables all emulated ARMv8 features. This is fine for
dev testing; the actual production hosts (Graviton, Ampere, real ARM64
hardware) all have these features natively.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Produces a UEFI-bootable raw disk image for generic ARM64 hosts (QEMU virt,
Ampere/Graviton cloud, ARM64 SBCs with UEFI). Reuses the existing 4-partition
A/B layout from x86 (EFI 256 MB FAT32 + System A 512 MB ext4 + System B 512 MB
ext4 + Data ext4 remainder).
Changes:
- build/scripts/create-disk-image.sh: TARGET_ARCH env var (amd64 default,
arm64). Selects kernel source path, grub-mkimage target (x86_64-efi vs
arm64-efi), EFI binary name (bootx64.efi vs BOOTAA64.EFI), grub.cfg variant,
and whether to also install BIOS GRUB (x86 only).
- build/grub/grub-arm64.cfg: ARM64 variant of grub.cfg. Identical A/B logic;
console=ttyAMA0+ttyS0 to cover QEMU virt PL011, Ampere PL011, and Graviton
16550-compat.
- build/Dockerfile.builder: add grub-efi-amd64-bin, grub-efi-arm64-bin,
grub-pc-bin, grub-common, grub2-common so the builder container can produce
EFI images for both architectures.
- hack/dev-vm-arm64.sh: split into kernel mode (direct -kernel/-initrd, fast
iteration) and --disk mode (UEFI firmware + GRUB + disk image, full
integration test). Probes common UEFI firmware paths on Ubuntu/Fedora/macOS.
Default kernel path now points at kernel-arm64-generic/Image with fallback
to the renamed custom-kernel-rpi/Image.
- test/qemu/test-boot-arm64-disk.sh: new CI test for the full UEFI -> GRUB ->
kernel -> stage-90 boot chain. Uses a scratch copy of the disk so grubenv
writes don't mutate the source artifact.
- Makefile: new disk-image-arm64 target (depends on rootfs-arm64 + kernel-arm64),
new test-boot-arm64-disk target, .PHONY + help updates.
Phase 3 scaffold is in place. First real end-to-end ARM64 build runs in the
next step on the Odroid runner — that's where we find out what's actually
broken.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- Dockerfile.builder: Go 1.24.0 → 1.25.5 (go.mod requires it)
- test-boot.sh: use direct kernel boot via ISO extraction instead of
broken -cdrom + -append; fix boot marker to "KubeSolo is running"
(Stage 90 blocks on wait, never emits "complete")
- test-security-hardening.sh: same direct kernel boot and marker fixes
- run-vm.sh, dev-vm.sh, dev-vm-arm64.sh: quote QEMU -net args to
silence shellcheck SC2054
- fetch-components.sh, fetch-rpi-firmware.sh, dev-vm-arm64.sh: fix
trap quoting (SC2064)
Validated: full Docker build, 94 Go tests pass, QEMU boot (73s),
security hardening test (6/6 pass, 1 AppArmor skip pending kernel
rebuild).
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Security hardening: bind kubeconfig server to localhost, mount hardening
(noexec/nosuid/nodev on tmpfs), sysctl network hardening, kernel module
loading lock after boot, SHA256 checksum verification for downloads,
kernel AppArmor + Audit support, complain-mode AppArmor profiles for
containerd and kubelet, and security integration test.
ARM64 Raspberry Pi support: piCore64 base extraction, RPi kernel build
from raspberrypi/linux fork, RPi firmware fetch, SD card image with 4-
partition GPT and tryboot A/B mechanism, BootEnv Go interface abstracting
GRUB vs RPi boot environments, architecture-aware build scripts, QEMU
aarch64 dev VM and boot test.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
