mini-x64: small amd64 UEFI machines with 128 MB of flash

mini-x64 is a generic system like uefi-x64 — one image for amd64 machines whose firmware is UEFI — cut down to run from 128 MB of flash: its own tinyconfig-based kernel, an xz root, and one product, mini-x64.basic, which runs OpenRC with the management plane and SSH. Status is owned by the status table.

At a glance


Architecture	`amd64`
Boot chain	UEFI firmware → signed `EFI/BOOT/BOOTX64.EFI` (systemd-boot) → counted entry → signed UKI → authenticated native init → SYSTEM → signed verity root/support → OpenRC
Firmware form	`efi` — the boot loader lives inside the ESP
Partitions	ESP / SYSTEM / DATA
Size budget	130 MB (`BOARD_SIZE_BUDGET_MB`); the root is xz squashfs
Tier	bring-up (QEMU)
Boot assurance	I1

Hardware and feature state

Feature	State	Note
Containers (Podman)	board ready, not in a product	`BOARD_FEATURES="containers"`; `mini-x64.basic` carries no container engine
virtio-blk	verified under QEMU	the path the automatic boot takes
SATA (AHCI), NVMe	driver built in, unverified on hardware	—
SD / eMMC (SDHCI over PCI or ACPI)	driver built in, unverified on hardware	the small flash parts this board is for
USB	not supported	`CONFIG_USB_SUPPORT` is off
Network	virtio-net, Intel e1000 and e1000e	—
Display, Wi-Fi, Bluetooth, status LED, CAN, USB gadget	none	headless
Physical recovery action	none	credential recovery and full-factory reset are refused on this board

status: board-dependent — evidence: mica-build:boards/mini-x64/board.env, mica-build:boards/mini-x64/kernel/config/mini-x64.fragment, mica-build:boards/mini-x64/evidence.json

Partition layout

Partition	Role	Start	Size
`esp`	FAT	1 MiB	16 MiB
`system`	ext4	17 MiB	98 MiB
`data`	ext4	115 MiB	12 MiB, grown to the medium on first boot

The authoritative geometry is mica-build:boards/mini-x64/layout.tsv.

Console

Serial, console=ttyS0,115200n8; net.ifnames=0, so interfaces are addressed as eth0.

Obtaining an image

The product is mini-x64.basic, released as mini-x64.basic.<YYYYMMDD-HHMM> with the image mica-mini-x64.basic-<YYYYMMDD-HHMM>.img.gz. Verification is in download.

Flashing

Under QEMU. Decompress the image to disk.img and start it; this is the run flashing section 4 records, against the published mini-x64.basic:

cp /usr/share/OVMF/OVMF_VARS_4M.fd vars.fd
qemu-system-x86_64 -machine q35 -cpu max -m 1024 -smp 2 -nographic -no-reboot \
  -device i6300esb -watchdog-action reset \
  -netdev user,id=net0,hostfwd=tcp:127.0.0.1:8080-:8080 -device virtio-net-pci,netdev=net0 \
  -drive if=pflash,format=raw,unit=0,readonly=on,file=/usr/share/OVMF/OVMF_CODE_4M.secboot.fd \
  -drive if=pflash,format=raw,unit=1,file=vars.fd \
  -drive if=none,id=disk0,format=raw,file=disk.img \
  -device virtio-blk-pci,drive=disk0,bootindex=0

The image is 128 MiB; truncate -s 1G disk.img before the first start gives DATA room to grow. The watchdog device and the secboot firmware build are both required.

Onto a physical machine (unverified). Write the whole image to the machine’s SATA, NVMe, SD or eMMC medium, never to a partition, then sync and read back to compare (flashing section 3). The kernel has no USB driver, so the machine cannot boot this image from a USB stick: the medium is written from another system.

status: unsupported

First boot

As on uefi-x64: the early init verifies the deployment, DATA grows to the end of the medium, and the health gate confirms the deployment that booted. The root’s init is OpenRC, and micad drives the services each package ships for that init (mica-core:docs/mica-core.md section 3.8).

mini-x64.basic carries no web console. It serves the API on port 8080 and is claimed there:

curl http://127.0.0.1:8080/api/v1/session        # {"state":"setup"}
curl -X POST -H 'content-type: application/json' \
  -d '{"password":"at-least-eight-bytes"}' http://127.0.0.1:8080/api/v1/setup

Updates

full, root and kernel archives, with the A/B switch, health confirmation and rollback of every board. See updates and rollback.

Recovery

As for uefi-x64: read-only diagnosis, manual rollback, configuration reset and application-data reset are available; credential recovery and full-factory reset are refused, because the board declares no physical recovery action; the floor is a whole-disk reflash, which costs every partition and the device identity. See recovery.

Known limitations

All evidence is emulator evidence, not field evidence.
No USB at all: a machine that has to boot or be installed from USB media is not this image.
No web console, no MQTT and no container engine: mini-x64.basic carries the management plane and SSH only.

Qualification results

Binding: QEMU q35 with OVMF Secure Boot firmware and virtio-blk, over mini-x64.basic; no physical machine.

Owners: the Mica OS project owns the port and its qualification. There is no vendor and no integrator of record.

Emulator rows are evidence about the emulated platform, never a hardware pass. Each release run of the product boots it once under QEMU.

Row	Result	Date	Evidence / reason
QEMU runtime, component updates, trial fallback, fault recovery	pass	2026-09-30	the UEFI lifecycle suite over `mini-x64.basic`, `mica-build:tests/suites/lifecycle-uefi`
Installation and first boot	not tested	—	no physical machine
Cold boot and warm boot	not tested	—	no physical machine
A/B switch and update	not tested	—	no physical machine
Power-cut during update	not tested	—	no physical machine
Storage growth/health	not tested	—	no physical machine; flash endurance is unqualified
Recovery	not tested	—	no physical machine
Radios and fieldbus	N/A	—	the board declares none

status: board-dependent — evidence: mica-build:boards/mini-x64/evidence.json, mica-build:tests/suites/lifecycle-uefi/boot.sh, mica-build:README.md