fixpoint-linux image M2 (x86_64) — fx-core shell

fixpoint-linux bootable image — M2 (x86_64) — boots into the fx-core shell

A single raw disk image that boots fixpoint-linux under QEMU with -drive
only, and lands you at an interactive fxsh prompt — fx-core's own shell,
running the real fx-* commands (no recompilation). Built by fx-image
(fx-init @ ad42206).

• fixpoint-m2-x86_64.raw.gz — 128 MiB raw image, gzip (~32.5 MiB on the wire)
• uncompressed sha256: 1dea1346530d2c85b784d20ba49540779bd8f4fccd656ba428c01e49c4eed66e

Boot it

curl -fL -o fixpoint.raw.gz \
  https://github.com/fixpoint-linux/fx-init/releases/download/image-m2/fixpoint-m2-x86_64.raw.gz
gunzip fixpoint.raw.gz

qemu-system-x86_64 -machine q35 -accel kvm -cpu host -m 2048 -nographic \
  -drive file=fixpoint.raw,format=raw,if=virtio

The console reports fx-init: boot-ok v3 and then gives you fx> . Try
fx-cat /etc/hostname, fx-ls /, or fx-seq 1 5 | fx-sort -r. Ctrl-A X
quits QEMU; typing exit leaves the shell.

⚠️ image-m1 was defective — do not use it

image-m1 (64 MiB) silently failed to seed its disk store: the store is
~47 MB (the image builds its payload binaries unoptimised) but --size-mb 64
leaves only a 32 MiB partition, so cp -a /fx/store ran out of space and init
fell back to the ramfs store. It still printed boot-ok v3, so the failure was
invisible — but that image had no persistence and no roll-forward. This M2
image is 128 MiB, the seed is verified (the disk image's contents change across
a boot, and a second boot of the same disk comes up), and it is the one to use.
The underlying store bloat is a known open item.

Provenance

Input	Value
config	m3/config-console.dhall (config-good + the fxsh console service)
package set	m3/package-set.dhall
kernel pin	scripts/kernel-pin.txt (6.12.19-tiny, drivers built-in)
fx-init	ad42206
activated generation	v3

The image carries a blank primary partition, formatted by the guest on first
boot. It is an early milestone: you get the shell and the supervisor; it is not
yet a general-purpose desktop.