ayeos.8b on GitHub

Getting started

Your first aye>

Bring the preview up on a test machine. Start with USB, then explore network boot when you’re ready.

Experimental previewx86_64 UEFISeptember 2026 preview

01 / Prepare

A place to experiment.

This is a developer preview of a bare-metal operating system. Use a spare machine or an isolated virtual machine, and keep a recovery route to your existing operating system.

  • An x86_64 computer with UEFI firmware. This image is not an ARM or legacy BIOS build.
  • A USB drive you can dedicate to the experiment, or a virtual disk for QEMU.
  • The matching image and checksum file from one release.
Current validation

The offline USB image and USB → iPXE → public HTTPS → AyeOS path have reached the aye> prompt in QEMU. This release’s physical-machine boot remains to be verified. Native MEMNET operation and client IP retirement are separate, unfinished work.

The preview does not yet have a supported Secure Boot signing path. Firmware that only permits trusted, signed EFI applications may refuse this loader. Use a dedicated test system whose boot policy permits the preview.

02 / Boot offline

Start with the USB image.

  1. Download the matching files.

    Save the image and its checksums in the same folder.

    USB image SHA256SUMS

  2. Check the download.

    Calculate the image’s SHA-256 and compare it with the ayeos-usb.img entry in SHA256SUMS. On macOS:

    shasum -a 256 ayeos-usb.img

    On Linux, use sha256sum ayeos-usb.img. On Windows PowerShell, use Get-FileHash .\ayeos-usb.img -Algorithm SHA256. A matching checksum checks file integrity; it is not a release signature.

  3. Write the image to your test USB.

    Use a disk-image writer that supports raw .img files. Identify the removable drive by its capacity and device information before selecting it.

    Writing a disk image replaces the drive’s contents.

    Back up anything you need first. Select the intended USB drive, and review that target before starting the write. You do not need to install AyeOS onto the computer’s internal disk.

  4. Choose the USB in the UEFI boot menu.

    Safely eject the drive, insert it into the test computer, and use the firmware’s one-time boot menu to select its UEFI entry. The loader should lead to the AyeOS aye> prompt.

Already have a FAT-formatted EFI USB?

An experienced user can update boot files without writing a full disk image. Back up the existing EFI directory first, then use the same release’s BOOTX64.EFI and KERNEL.BIN:

EFI/
└── BOOT/
    ├── BOOTX64.EFI
    └── KERNEL.BIN

These files replace any existing loader at those paths. Keep the loader and kernel together as a matched pair and check each against SHA256SUMS.

03 / From the firmware

Already at a UEFI shell?

Insert the prepared USB and refresh the filesystem mappings:

map -r

Inspect the listed FS0:, FS1:, and other filesystem entries until you find the USB’s EFI\BOOT directory. The example below assumes it is FS0:; use your actual mapping.

fs0:
ls EFI\BOOT
EFI\BOOT\BOOTX64.EFI

If no filesystem appears, try another USB port and run map -r again. The image must have been written as a disk image, rather than copied onto the drive as a single .img file.

04 / Beyond the USB

Boot files, over the network.

Network boot is useful when you want to keep the loader and kernel on a server and choose a matching release without rewriting a full USB image.

HTTPS / iPXE

A USB launcher, a web download.

UEFI starts iPXE from USB. iPXE gets a network address, fetches the kernel, and starts AyeBoot. This route has reached the AyeOS shell in QEMU over public HTTPS, using the official iPXE binary with TLS verification.

How the web handoff works
TFTP / AyeFire

A boot service on your LAN.

AyeFire supplies boot files through TFTP, with web and terminal controls. PXE firmware also needs your boot network’s DHCP settings to identify the server and loader.

AyeFire source and setup instructions will accompany source publication.

Keep IP until the downloads finish.

TFTP uses UDP/IP; HTTP and HTTPS use TCP/IP. The intended client sequence is to finish and verify downloads, enter the kernel, establish native MEMNET, and then retire optional IP services. That complete handoff is future work. The server can keep IP for administration and for other booting machines.

How does iPXE hand the downloaded kernel to AyeBoot?

The USB launcher is iPXE; the hosted BOOTX64.EFI is AyeBoot. iPXE downloads the kernel with the image name EFI\BOOT\KERNEL.BIN, then starts the matching AyeBoot application. AyeBoot finds the kernel through iPXE’s UEFI filesystem.

Keep both files in one versioned release directory and retain the offline USB image as a recovery route. Public HTTPS delivery has been verified in QEMU. Physical firmware compatibility and release-signature verification remain separate work.

Public HTTPS boot now reaches the AyeOS shell in QEMU with TLS verification. Release-signature enforcement and a supported Secure Boot signing path remain unfinished; transport security does not establish the complete boot trust chain.

05 / Learn from the boot

You’ve reached aye>.

Capture what your machine reports, including the computer model, firmware version, release, and any boot or network messages. A shell prompt verifies startup; native networking needs its own evidence.

Follow the project Explore the library

To return to your usual system, power down and remove the USB, then select the existing operating system in the firmware boot menu.

A few useful answers

Before the next step.

Is this ready to replace my everyday operating system?

No. This preview is for development and exploration. Hardware coverage, boot trust, persistence, and the full native network handoff still need work. Keep your normal operating system and recovery media available.

Can the boot server run on ARM?

Serving static boot files does not require the server to match the client’s CPU architecture. An ARM web server can host this x86_64 image. Running AyeOS itself on ARM requires a separate port.

Does starting AyeOS remove TCP/IP?

Not in the current preview. Native MEMNET is the intended direction, but downloading files, starting the kernel, bringing up MEMNET, and retiring IP are distinct steps. The current implementation does not yet complete that entire sequence.

Will there be a MEMNET boot BIOS?

A native MEMNET boot path is a future direction. A UEFI application is a practical first step before deeper firmware integration. It needs a boot protocol, artifact authentication, bounded transfers, supported NICs, and a tested handoff to the kernel.

Where can I read the papers without running AyeOS?

The 8b Library contains curated documents and reader sources. Its downloadable release includes an offline reader.