FreeOS 0.1.23 — disks that are not virtio

An operating system written from scratch in Rust, for ARM64 and x86-64. UEFI boots
it, a compositor draws it, programs run outside the kernel in address spaces of their own,
and it installs itself onto a disk it partitioned. No telemetry, no network calls, no third
party kernel code.

This is the first published build. It is a working system, not a demo: it boots to a
desktop with a mouse, runs ring-3 programs that are scheduler tasks, enforces mode/uid/
gid on every path component, writes to an ext2 root that survives a reboot, and keeps the
wall clock to within a second or two of the host's.

What is new in 0.1.23

Disks that are not virtio. For nine phases the words "disk" and "virtio-blk" meant the
same thing in this kernel — fine inside QEMU, where there is no other disk, and useless
everywhere else. The installer would write a disk perfectly well through the firmware, and
then the installed system would not find its own root. Two drivers close that:

• AHCI — the controller behind every SATA port, and the one VirtualBox presents by
  default.
• NVMe — how the disk in any laptop bought in the last eight years is attached. Queues
  in memory, a doorbell, a phase bit, and PRP lists instead of ports and registers.

Underneath both is the part that mattered more than either: the root partition is now
looked for on every disk the machine has, by its GPT type GUID, rather than on the one
that happened to be first.

One defect on the way is worth the sentence, because it is the class this project keeps
meeting — a state the firmware happened to leave behind, mistaken for a state of the
hardware. On x86-64 AHCI worked at once; on ARM the same disk reported "no device" while
the link was plainly up. OVMF has a SATA driver and had already introduced the device to
itself; ArmVirtQemu has none and had touched nothing. The driver now resets the link itself,
which makes the port's state identical whether the firmware set it up, ignored it, or left
it half-configured.

The full reasoning, including what each phase checks and what is known to be missing, is in
README.md.

What it looks like

The desktop, on x86-64 and on ARM64 — same source, same compositor, different machine:

The file manager, reading the mounted filesystem:

The installer picks a disk and refuses to offer the one it booted from, then asks for
confirmation last — everything you might change your mind about is asked before the point
of no return, not after:

And the installed system, running a program as the account the installer created. Four
files, four different answers, each for its own reason — the last one is refused because a
directory on the way is 0700 and owned by someone else, not because of the file's own
mode:

Which file to take

File	What it is
FreeOS_0.1.23_x86_64_release.iso	Live system, x86-64. Boots, gives you the desktop, writes nothing to the host.
FreeOS_0.1.23_aarch64_release.iso	Live system, ARM64.
FreeOS-Installer_0.1.23_x86_64_release.iso	Installer, x86-64. Erases a disk and installs onto it.
FreeOS-Installer_0.1.23_aarch64_release.iso	Installer, ARM64.

How to run it

EFI is required — there is no BIOS boot path at all, by design. A machine left on legacy
boot will simply not find the medium.

In VirtualBox: create a VM of type Other/Unknown (64-bit), turn on Settings → System →
Enable EFI, attach the .iso to the optical drive, start it. VMware works the same way;
on Hyper-V pick Generation 2, which is the EFI one. The defaults are fine — the pointing
device does not need changing any more, because the kernel reads the device's own HID report
descriptor rather than assuming a boot protocol.

In QEMU, from a clone of the repository: cargo xtask run --arch x86_64.

Honest limits

• The live ISO writes nothing. It boots, mounts its initrd, gives you the desktop and
  the shell. That is the whole of it, and it is the point.
• The installer erases the disk you select. It shows the layout and asks for
  confirmation last, and it will not offer the medium it booted from — but it has no
  resize, no dual boot, and no undo. Use a disk you are willing to lose.
• Verified in QEMU, on both architectures, in both profiles — 84 automated scenarios,
  driven over the serial line rather than by screenshots. The VirtualBox run for the new
  disk drivers has not been done yet; when it is, it will be said out loud.
• A disk with 4096-byte sectors is refused with a message, not silently treated as
  512-byte. Removing that limit is the next phase — it existed because there was no way to
  test against such a disk, and that stopped being true with the NVMe driver.
• There is no login and no password prompt. The account exists and programs run under
  it; nothing switches users yet, and the password digest in /etc/passwd is not produced
  by a real key derivation function. That is stated in the code rather than dressed up.

Licence

MIT OR Apache-2.0.