XAIOS Build 6

One image per architecture, instead of one image for all of them.

Up to build 5 a release was a single ISO carrying an AArch64, an x86-64 and a
RISC-V loader, kernel and initial filesystem. UEFI makes that work and it was
genuinely one deliverable — but a boot that went wrong had three kernels, three
initial filesystems and three loaders on the medium to be wrong about, the file
was 220 MB of which about thirty was payload, and an architecture whose build
had quietly not happened produced an image that still booted on the machine
that built it and not on the machine it was carried to.

Pick your architecture first

An AArch64 image will not boot an x86-64 machine, and no kit fixes that
afterwards.

To run XAIOS on	AArch64	x86-64	RISC-V 64-bit
QEMU	xaios_b6-aarch64-qemu.zip	xaios_b6-x86_64-qemu.zip	xaios_b6-riscv64-qemu.zip
VMware Fusion	xaios_b6-aarch64-vmware-fusion.zip	—	—
Apple Virtualization.framework	xaios_b6-aarch64-virtualization-framework.zip	—	—
a real machine, from a USB stick	xaios_b6-aarch64-usb.zip	xaios_b6-x86_64-usb.zip	xaios_b6-riscv64-usb.zip
a real machine with no disk, over the network	xaios_b6-aarch64-netboot.zip	xaios_b6-x86_64-netboot.zip	xaios_b6-riscv64-netboot.zip
your own tooling	xaios_b6-aarch64.iso.zip	xaios_b6-x86_64.iso.zip	xaios_b6-riscv64.iso.zip

Fusion and Virtualization.framework have no x86-64 or RISC-V column because both
run guests on the host Mac's own cores; an x86-64 or RISC-V guest there would be
emulation, which is what the QEMU kits are for.

Unzip before use. On first boot there is no account and no default password —
the machine asks how to set itself up.

RISC-V reaches the same shelf as the other two

It had a loader inside the shipped image and nothing else: no launcher anyone
downloads, no USB kit, no network-boot binary. It now has all three, and both
new files boot. What has never happened is a real machine fetching one over a
network — no RISC-V machine that netboots has been in front of this project — so
what is unproven there is the fetch and the DHCP option-93 selection, not the
system inside the binary. The kit's own README says so.

Smaller, where it could be

78 MB for x86-64 and 84 MB for RISC-V, against 220 MB before. AArch64 keeps its
size: its 96 MiB EFI System Partition is the one VMware Fusion's firmware boots,
and shrinking it is a re-qualification rather than an edit.

A machine that had run long enough stopped booting

A file is at most sixteen runs of blocks, and the allocator took the first
sixteen free runs in address order. The low blocks of a volume are the most
broken up, so on a volume written and rewritten for a while it collected sixteen
fragments out of the rubble at the bottom and refused the write with the volume
two-thirds empty. Because the same path snapshots a file, and because the update
self-test stages a snapshot on every boot and asserts it worked, the machine
halted in the cyan screen instead of coming up — with fsck calling the volume
sound, which it was. Blocks are now taken longest-run-first. Sixteen extents is
still a ceiling and that is recorded rather than claimed fixed.

Three things that could not fail before now can

• The image builder asks mformat what filesystem it produced rather than
  trusting that the size implies FAT16, which is what Fusion silently depends on.
• The release builder refuses an architecture it was asked for and cannot find,
  instead of skipping it in a line that scrolls past.
• A kernel built to fault on purpose says so in its own bytes, and both packaging
  scripts refuse it without booting anything. Not hypothetical: a network-boot
  binary was built that way and looked like a release binary in every respect a
  person can check.

---

The release note
records every checksum, exactly which hypervisors and firmware this build was
booted on, and what was not tested. How a build is produced, and what each
check in the sequence is there to catch, is in
docs/BUILD-PROCESS.md.

Nothing here is production supported and the syscall surface is not frozen.