On real hardware

EDOS runs on real UEFI machines. It has been tried on a handful, which is not the same as being tested.

Boot the live ISO

The ISO is hybrid, so it goes straight onto a USB stick:

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

Boot it as a UEFI device. There is no BIOS/CSM path worth relying on.

The ISO carries a complete GPT disk image as a Limine boot module. The kernel exposes it as a RAM-backed block device and mounts it as the root filesystem, so the live system is writable, and everything written to it disappears on reboot. Nothing else needs to be attached for the machine to reach a desktop.

Install it to a disk

From the live desktop, in a terminal:

/ $ edos-install /dev/sda

Options are --esp-size SIZE (512M by default) and --yes to skip the confirmation. Disks appear as /dev/sda, /dev/sdb and so on, one node per device rather than per partition.

The installer:

1. Refuses to run if the target is backing a mounted filesystem.
2. Prints the plan: the device, its size, the two partitions it will write, and that everything on it will be destroyed. Waits for you to type yes.
3. Writes a GPT: an EFI System Partition, and an EDOS root taking the rest, with a freshly generated partition GUID so two installed disks are never confused.
4. Formats the ESP as FAT32 and the root as EFS.
5. Rescans the partition table and checks it found the two it just wrote.
6. Mounts both, copies the live root across, and writes Limine plus a limine.conf naming the new root’s GUID into the ESP.
7. Flushes and unmounts.

Reboot with the USB stick removed and the machine boots from its own disk, with a filesystem that keeps what you put on it.

Every step prints what it is about to do before doing it, so a failed install can be read off the serial log.

Which root gets mounted

The kernel matches the partition GUID from the Limine command line against every partition it can see, and prefers a match on a real disk over the live image that booted it. So a machine with EDOS installed boots the installed system even from the USB stick. The second Limine entry, edos (live root), forces the live root when you want it.

If nothing matches, the kernel logs every partition it did see, with device, index, GUID and detected filesystem, then falls back to a memory-backed root rather than mounting whatever happened to enumerate first.

What the drivers expect

Device	Support
Graphics	virtio-gpu. There is no driver for real GPUs, so on bare metal you get whatever the firmware left in the framebuffer.
Storage	AHCI with NCQ. SATA controllers in AHCI mode work; RAID mode does not, and there is no NVMe driver.
Network	Intel e1000e. Verified on real I219, I218 and I217 parts. DHCP configures the interface if a server answers.
Input	USB HID keyboard and mouse over xHCI, plus PS/2 through the legacy controller.
Audio	Intel HDA.

Anything outside that list is not driven. The kernel logs every PCI device it finds at boot, so the serial log tells you quickly whether your machine is in scope. In particular, a machine with only NVMe storage can run the live system but has nothing to install onto.

Getting output when it fails

Serial is the debugging channel, and the kernel writes to the legacy 16550 UART at 0x3F8. If the machine has a real serial port, capture it; there is no USB serial driver, so on a machine without one there is no log to read. A machine that boots far enough to start the window manager will at least show you the desktop.