Architecture
Disk layout
A fixed layout, the same on every box — appliances assign disk roles, they don't expose partition editors:
| Partition | Role |
|---|---|
| XCON-BIOS | 1 MiB bios_grub (BIOS GRUB embed on GPT) |
| XCON-ESP | EFI system partition; GRUB + staged kernels |
| XCON-A | system slot A (read-only squashfs) |
| XCON-B | system slot B (read-only squashfs) |
| XCON-DATA | XFS, everything mutable (grows to fill the disk) |
The image installs GRUB for both BIOS and UEFI, so it boots on legacy-BIOS clouds and modern UEFI hardware alike.
Read-only root, writable data
The active slot is mounted read-only. /etc and /var are overlays
whose writable layer lives on the data partition, so per-box changes
persist without ever modifying the base image. All real state —
databases, apps, credentials, TLS, the xcon user's home — is on
XCON-DATA.
Identity and networking
Each box generates a unique machine-id on first boot and identifies to DHCP by its MAC address, so its IP stays stable across reboots.
Accounts
One primary account — xcon, sudo-capable, home on the data partition. root is locked: no password, no direct login, reachable only through sudo. The installer asks for exactly one password — xcon's, which is also the webadmin's.
Updates and trust
The update channel is static and signed. Each release is a manifest (version, notes, file hashes) plus an Ed25519 signature; the signing key is offline and the public key is baked into the image. The box trusts the signature, not the server — a compromised channel can't push an unsigned image.