Skip to content

EDOS v0.2.0 — one bootable file

Latest
Latest

Choose a tag to compare

View all tags
@edg-l edg-l released this 09 Aug 14:32
· 100 commits to trunk since this release
v0.2.0
e6cc844
This commit was signed with the committer’s verified signature.
edg-l Edgar
SSH Key Fingerprint: +A7lLT2gDYr5C10kmfwZUpM/UInH6sAMBHGi1NjMpRk
Verified
Learn about vigilant mode.

One file. edos-x86_64.iso carries its own root filesystem, boots to the
desktop on its own, and can install itself onto a disk.

Everything before this release needed two files: an ISO holding nothing but
Limine and the kernel, plus a separate disk image the kernel went looking for by
partition GUID. On real hardware that meant flashing a 5G image to a spare drive
before the machine was usable.

What is new

  • A live ISO. The root filesystem ships inside the ISO as a Limine boot
    module, served by a RAM-backed block device. Writable, and discarded on
    reboot. Nothing else needs to be attached.
  • edos-install <device>. From the live desktop: partitions the target,
    formats an ESP and an EFS root with a fresh partition GUID, copies the live
    system across, and writes Limine naming the new root. Reboot without the stick
    and the machine comes up on its own disk.
  • Block devices in userspace. /dev/sda, /dev/sdb, /dev/ram0, byte
    addressed through the block page cache, with ioctls to flush, rescan the
    partition table, read the sector count, and ask whether a device backs a mount.
  • efs-mkfs runs inside EDOS, sharing one implementation with the host tool.
  • Root selection is explicit. A real disk wins over the live root, so an
    installed machine boots its own system. root=live forces the live root. No
    match logs every partition it saw and falls back to memfs, instead of mounting
    whichever partition enumerated first.

Getting there took nine write-path fixes in the kernel, none of them specific to
the installer: writes that bypassed the block page cache were lost, and the EFS
journal wrote its ring at partition-relative LBAs.

Running it

qemu-system-x86_64 \
  -machine q35,accel=kvm -cpu host -smp 4 -m 2G \
  -drive if=pflash,format=raw,readonly=on,file=/usr/share/OVMF/OVMF_CODE.fd \
  -drive if=pflash,format=raw,file=OVMF_VARS.fd \
  -cdrom edos-x86_64.iso \
  -device virtio-vga -device qemu-xhci -device usb-kbd -device usb-mouse \
  -serial stdio

Or write it to a USB stick and boot it as a UEFI device:

sudo dd if=edos-x86_64.iso of=/dev/sdX bs=4M status=progress conv=fsync

Full instructions at edos.edgl.dev/downloads.

Verify

sha256sum -c SHA256SUMS

Known limits

Graphics is virtio-gpu only, so bare metal gets whatever the firmware left in
the framebuffer. Storage is AHCI; there is no NVMe driver, so a machine with
only NVMe can run the live system but has nothing to install onto. No accounts,
no permission checks. The journal covers metadata, not file data.

Assets 4
Loading