refactor(backend): read the arm64 guest kernel in-process via go-diskfs, no loopback mount#15
Conversation
…fs, no loopback mount
|
Warning Review limit reached
More reviews will be available in 11 minutes and 12 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (8)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
On linux/arm64 fleetbox boots stock cloud images by direct kernel boot: it pulls the guest image's own
vmlinuz/initrdout of the raw root disk before launching the VM. That extraction used to loopback-mount the disk —losetup --partscan,udevadm settle,mount,umount,losetup --detach. It was the last shell-out left in the Linux backend after ADR-0025 removed all the networking ones, and it carried the same costs: it needed those binaries on PATH and root to run, it mutated global host state (a loop device and a kernel mount) that leaked if the holder was SIGKILL'd mid-extraction, and it papered over a udev race with sleeps.This replaces the extraction mechanism with an in-process, pure-Go read of the raw image via go-diskfs (the surgical
backend/file+partition/gpt+filesystem/ext4set): open the disk read-only, walk the partition table, read each partition as ext4 until one yields a kernel, copy out the kernel (gunzipping a gzip Image) and initrd via an atomic temp+rename. No loopback mount, no shell-out, no global host state to leak on SIGKILL, no root needed for extraction. The direct-boot decision and the boot ABI are unchanged — same--kernel/--initramfs/--cmdline, same cached output next to the disk. The extracted kernel and initrd are byte-identical to the old loopback extraction, re-proven on the pinned debian-12 arm64 image.The pure search/copy logic lives in a new untagged
bootextract.goso it is unit-testable on the macOS dev box (the same split the package already uses forpurehelpers.go); the go-diskfs wiring stays in thelinux && arm64file, so go-diskfs links into that binary alone andgoogle/uuidis the only new external module. go-ext4fs stays the fixture writer (bumped to v1.0.2). This raises the module's minimum Go to 1.25 (go-diskfs v1.9.3 requires it).Heads-up for reviewers: there is no CI lane for the nested arm64 path —
vm-linux.ymlruns the amd64 firmware path (boot_amd64.go) and does not exercise this code. It was validated locally: the seam unit tests, the byte-identical sha256 re-proof, and themake test-vmnested dogfood on M3+/macOS-26 hardware.Checklist
ARCHITECTURE.mdupdated in this PRdocs/adr/(next sequential number)!in the title) → the description spells out what callers must change