Download and run GLaDOS

Three images, all bootable UEFI ISOs, all built by this project's own ISO writer: a FAT32 EFI System Partition wrapped in ISO 9660 with an El Torito boot entry pointing at it. They differ in exactly one thing, which is the language model baked into them.

glados-1.3.7-qwen3-0.6b.iso

glados-1.3.7-qwen35-2b-8k.iso

glados-1.3.7-qwen35-2b-32k.iso

The links in the table above are pinned to 1.3.7. There is deliberately no fixed "latest" URL for an individual image, because the filename carries the version, and a URL that silently changed what it served would be a poor thing to put in a script.

So, three ways, in order of how much you want to type:

• By hand: the releases page always opens on the newest, with every image listed.
• With the GitHub CLI, which resolves the newest release for you:

# every image from the newest release
gh release download --repo IlumCI/GLaDOS --pattern "*.iso"

# or just the small one
gh release download --repo IlumCI/GLaDOS --pattern "*qwen3-0.6b.iso"

• With curl alone, asking the API which asset is newest. Change the pattern at the end to pick a different image:

curl -s https://api.github.com/repos/IlumCI/GLaDOS/releases/latest \
  | grep -o '"browser_download_url": *"[^"]*qwen3-0.6b\.iso"' \
  | cut -d'"' -f4 \
  | xargs curl -L -O

The checksum file is the one asset whose name never changes, so it does have a stable URL:

curl -LO https://github.com/IlumCI/GLaDOS/releases/latest/download/SHA256SUMS

Worth doing, and worth doing before you spend twenty minutes wondering why the model will not load. A truncated download still flashes and still boots. It fails later, while loading weights, with a message about the weights, and nothing in the system knows the real cause.

# Linux
sha256sum -c SHA256SUMS --ignore-missing

# macOS
shasum -a 256 -c SHA256SUMS --ignore-missing

# Windows PowerShell -- prints the hash, compare it against SHA256SUMS yourself
Get-FileHash .\glados-1.3.7-qwen3-0.6b.iso -Algorithm SHA256

CI records each image's digest as it is built and re-reads it from the release afterwards, because an upload of 1.9 GB that changes the bytes is a thing that can happen and a digest taken before the upload would not catch it.

The easiest route, and the one to send somebody who just wants to see it. VirtualBox is free, runs on Windows, macOS and Linux, and touches nothing outside its own virtual machine.

1. Install VirtualBox from virtualbox.org if you do not have it, and download an image from the table above.

2. Machine → New. Give it a name. Set Type to Other and Version to Other/Unknown (64-bit). Under ISO Image, browse to the .iso you downloaded.

   The 64-bit part matters. Pick a 32-bit version and the machine will not start the kernel at all.

3. Tick "Skip Unattended Installation". VirtualBox sees an ISO and offers to install a guest operating system from it automatically. There is no installer on this disc, so let it skip.

4. Memory and processors. At least 2048 MB for the 0.6B image, 5120 MB for the 2B, 8192 MB for the 32k. Two or more processors is worth doing: several self-test suites genuinely need a second core and report a failure without one.

5. Hard disk: you can skip it. Choose "Do Not Add a Virtual Hard Disk". Nothing is installed, and the system runs entirely from the disc. Adding one is harmless if the wizard insists.

6. Finish the wizard, then open Settings → System → Motherboard, and tick "Enable EFI (special OSes only)".

   This is the step everybody gets stuck on. VirtualBox boots BIOS by default and GLaDOS has no BIOS boot path, so without this you get "FATAL: No bootable medium found" and nothing else. The wording of the setting is unfortunate, but this is the special OS it means.

7. Start the machine. You should see the firmware, then the GLaDOS boot log, then a desktop.

If it is unbearably slow, hardware acceleration is off or unavailable. Check Settings → System → Acceleration, and on Windows note that VirtualBox and Hyper-V fight over the hardware: if Hyper-V, WSL2, Docker Desktop or Windows memory integrity are enabled, VirtualBox may silently fall back to emulation. Turning Hyper-V off, or using QEMU with the Windows hypervisor instead, both work.

What this project is developed against, so it is the best-tested environment there is. QEMU needs its UEFI firmware attached by hand, which is the one fiddly part.

1. Install QEMU and OVMF. OVMF is the open-source UEFI firmware; QEMU ships it, but not always under the same name.

   # Debian / Ubuntu
   sudo apt install qemu-system-x86 ovmf
   
   # Fedora
   sudo dnf install qemu-system-x86 edk2-ovmf
   
   # macOS
   brew install qemu
   
   # Windows
   choco install qemu

2. Find the firmware, and make a writable copy of the variables file. Modern QEMU ships edk2 as a split pair: a read-only CODE image and a writable VARS image that holds the NVRAM. The VARS file in the system directory must not be written to, so copy it first.

   # common locations; one of these will exist
   ls /usr/share/OVMF/OVMF_CODE.fd /usr/share/edk2/x64/OVMF_CODE.fd \
      /usr/share/qemu/edk2-x86_64-code.fd 2>/dev/null
   
   cp /usr/share/OVMF/OVMF_VARS.fd ./vars.fd

   Do not reach for -bios here. Those files are flash device images rather than a ROM, and QEMU rejects them with "could not load PC BIOS". They have to be attached as two if=pflash drives, which is what the command below does. Only the legacy combined OVMF.fd works with -bios, and most distributions no longer ship one.

3. Boot it. Adjust the firmware paths to whatever step 2 found.

   qemu-system-x86_64 \
     -machine q35 \
     -m 2G \
     -smp 4 \
     -accel kvm \
     -drive if=pflash,format=raw,unit=0,readonly=on,file=/usr/share/OVMF/OVMF_CODE.fd \
     -drive if=pflash,format=raw,unit=1,file=./vars.fd \
     -cdrom glados-1.3.7-qwen3-0.6b.iso

   Raise -m to 5G or 8G for the 2B images.

4. Use the right accelerator for your host, or everything will be emulated. The difference is not subtle: on this project's own workload the Windows hypervisor measured about 160 times faster than emulation, taking a boot plus four commands from over 24 minutes to 61 seconds.

   -accel kvm                    # Linux
   -accel hvf                    # macOS
   -accel whpx -cpu max          # Windows
   

   On Windows -cpu max is needed alongside whpx: the hypervisor alone reports no AVX2 or FMA, and the parts of the system that need them decline to run and say so.

A serial console is worth having. Adding -serial stdio puts the shell in your terminal, which is easier to read and to copy out of than the framebuffer. The project's own harness drives exactly this, over a TCP socket instead of stdio.

The real thing. Real memory bandwidth, real hardware, real devices to find on the PCI bus. This is also the only route that destroys something, so it is worth being careful about which device you pick.

With balenaEtcher

1. Get balenaEtcher from etcher.balena.io. It is free, and runs on Windows, macOS and Linux.

2. Plug in the stick. Any size from 2 GB up for the 0.6B image, 4 GB up for the 2B ones. An external SSD works exactly the same way and Etcher treats it identically.

3. Flash from file, and pick the .iso you downloaded. Etcher takes the ISO directly; there is nothing to convert and no mode to select.

4. Select target. Etcher hides your system drives by default, which is most of why it is the recommended tool here. Check the name and the size against the device you actually plugged in.

5. Flash, and let it validate. Etcher re-reads what it wrote and compares. Let it finish: this is the same check as verifying the download, one layer further down, and it catches a stick that is failing.

6. Eject it properly before pulling it out, so the write cache is flushed.

Other tools, if you prefer

• Rufus on Windows, in DD mode. It will ask; take DD rather than ISO mode.
• dd anywhere Unix-like. Check the device name twice; this overwrites whatever you name.

# Linux / macOS. Check the device name first, this overwrites it
sudo dd if=glados-1.4.2.iso of=/dev/sdX bs=4M status=progress oflag=sync

On macOS the device is /dev/rdiskN and you will need to diskutil unmountDisk it first.

1. Turn Secure Boot off in your firmware settings.

   The kernel is not signed by a key your firmware trusts, and there is no Microsoft-signed shim in front of it. What firmware usually says about this refusal is "no bootable device", which is true in the same way a locked door is not a wall. Secure Boot lives under Security or Boot in most firmware setup screens.

2. Leave the stick in and reboot, then open the firmware boot menu. Which key depends on the vendor:

   MSI, Lenovo, Acer

   F11

   Dell, HP, Toshiba

   F12 or F9

   ASUS

   Esc or F8

   Most others

   F12, F11, F8 or Esc, held from power-on

3. Pick the entry listed under UEFI. Many firmwares list the same stick twice, once as UEFI and once as legacy. Take the UEFI one; the other will not boot.

4. Read the boot log. It prints the memory map it was handed, how much heap it managed to get, every device it finds on the PCI bus, and a pass or fail line for every self-test. Twenty-six sections run at boot and diag offers fifty-eight named suites on demand.

   That log rewards a read. An ECDSA bug once sat visible in it for an entire debugging session while the person reading the screen scrolled past it.

You get a Frutiger Aero desktop with a window manager, a taskbar and a terminal, and a shell behind it. Things worth typing, roughly in order of how quickly they pay off:

• help lists everything. diag lists the self-test suites and diag all runs them.
• ask what is an operating system puts a question to the model in kernel space. gen generates text, and ask new forgets the conversation.
• devices says what is in the machine, which driver claimed each part, and, at the bottom, what it recognised and cannot drive.
• if, dhcp, dns example.com, then https example.com / fetches a page over a TLS 1.3 connection this kernel negotiated itself, down to the X25519 key exchange.
• battery reads a charge by interpreting the AML your own firmware ships in its DSDT, because on a laptop there is no other way to get one. In a virtual machine there is no battery to read.
• agent <goal> hands the model a goal and a step budget. It picks an applet through a grammar that makes wrong names unreachable, reads what the applet prints, and writes a transcript.
• doom, if you have a WAD. None ships, for the same reason no weights are in the source repository.

"No bootable medium found", or the firmware shell instead of a desktop

The machine is booting BIOS rather than UEFI. In VirtualBox, Settings → System → Motherboard → Enable EFI. In QEMU, the two if=pflash drives. On real hardware, pick the boot entry listed under UEFI and check Secure Boot is off.

It boots, then stops while loading the model

Almost always not enough memory. The weights are read whole into a pool before the firmware hands over, so the requirement is hard rather than a matter of swapping. Raise the virtual machine's RAM, or take the 0.6B image.

It boots but the model behaves strangely, or fails to load with a sensible-looking error

Verify the download against SHA256SUMS. A truncated image flashes, boots, and fails somewhere with no relationship to the truncation.

Everything works and is glacial

Hardware acceleration is off. See the notes under each route. On Windows, Hyper-V and VirtualBox contend for the hardware and VirtualBox loses quietly.

store init says there is no unclaimed space

Working as intended. NVMe writes are locked at boot and only unlock once the driver finds a disk region explicitly set aside for it. On a machine whose disk is entirely allocated to another operating system there is no such region, so it fails and says so rather than taking space that belongs to something else.

Two self-test suites fail on a single-processor machine

Expected. "The allocator was exercised from several cores" and "a task carried onto another core and back" are false statements about a machine with one core. Give the guest two or more.

Development happens against one laptop, an MSI Thin GF63 12UC, and that is the only machine any of this is meaningfully tested on.

It should boot on most x86-64 UEFI systems. Nothing in the boot path is vendor-specific and the graphics path is plain GOP, which every UEFI implementation provides. Storage and networking are a different story, because a driver has to match a chip: there is one for Intel e1000, one for Realtek RTL8168, one for NVMe and one for xHCI, and that is the whole list. So expect a working desktop and a working model, and treat your disk and your network card as an open question. devices will tell you which way it went, and names what it recognised and cannot drive.

Wireless does not work yet on real hardware. The 802.11 stack is written and tested against a simulated radio, but no driver exists for the wireless part in this laptop or in most others, so there is no wlan0 to join a network with. Wired ethernet and USB tethering from a phone both work today.

The battery reading is an open question in the other direction. It goes through an interpreter that runs your firmware's own bytecode, which is universal by construction, but the embedded controller it reaches through has never had its success path exercised: emulators model no controller, so under a virtual machine only the timeout is proven and every figure shown is a fallback.

Can I run GLaDOS without installing it on a real computer?

Yes, and it is the recommended way to try it. VirtualBox and QEMU both run it and neither touches your disk. The only requirement is that the virtual machine boots UEFI rather than BIOS, which is one checkbox in VirtualBox and a pair of pflash drives in QEMU.

Is the GLaDOS ISO free?

Free to download and free to run. The source is published under all-rights-reserved, which means you are welcome to read it. Redistributing it or building derivatives from it needs asking.

Will it damage my computer or my files?

Booted from the ISO it installs nothing and writes nothing. NVMe writes are locked at boot and only unlock if the driver finds a disk region that was explicitly set aside for it, and every error path locks them again. The one step that does destroy data is flashing a USB stick or an external SSD, which erases that device completely.

Which image should I take?

The Qwen3-0.6B one, on 2 GB of RAM. The 2B images want 5 GB, and 8 GB for the 32k variant. Those two carry the same weights and differ in one four-byte field, which is how much conversation fits before the cache starts recycling its oldest turns.

How do I get the newest version?

The releases page always opens on the newest. There is no fixed URL for an individual image because the filename carries the version, so the commands above ask the API which asset is newest rather than guessing at a name.

Why does it need Secure Boot disabled?

Because the kernel is not signed by a key your firmware trusts. Getting one would mean going through a Microsoft-signed shim, which is a matter of distribution and paperwork. This applies to real hardware; VirtualBox and QEMU with plain OVMF do not enforce it.

How fast is the model?

Generation is bound by memory bandwidth, so each token costs roughly one pass over the weights. That puts the 2B images about three times slower per token than the 0.6B one. Around 155 MB of the 0.6B checkpoint is the output classifier alone, which is why restricting that final matrix multiply to the tokens a grammar can actually reach is such an effective optimisation.

Does it send anything anywhere?

No. There is no telemetry and no network activity at all unless you type a command that causes some. There is an updater, and it runs only when you ask it to: nothing checks for a new version on its own, at boot or on a timer. The model runs locally because there is nowhere else for it to run.