> **Disclaimer:** The following text is an AI-generated log and summary of a
> 10-hour attempt by `claude-code` and `Swamp` to virtualize macOS Tiger 10.4.
> Previously I had no experience running mac os in VM, nor did a I read guides,
> during the run I had to point claude to guides and reasonable attempts

I wanted to run macOS Tiger 10.4 in a VM on my Unraid box, managed entirely by
[Swamp](https://github.com/systeminit/swamp).

This is a log of the attempt. It highlights the friction that occurs when trying
to run a 2006 operating system on 2026 virtualization infrastructure.

## The Goal

Run a genuine Apple macOS Tiger 10.4 (Intel) installation inside QEMU/KVM on
Unraid. No hackintosh distros. A pure, retail Tiger ISO, provisioned through
Swamp extension models.

## The 32-bit EFI Problem

The Tiger 10.4.5 Intel retail ISO has a `boot.efi` that is strictly **32-bit**:

```
boot.efi: PE32 executable Intel 80386, for EFI
```

Standard OVMF—the modern UEFI firmware for QEMU—is 64-bit. A 64-bit UEFI cannot
execute a 32-bit EFI binary.

Tiger 10.4.8 and later shipped with a dual 32/64-bit `boot.efi`, which would
work with standard OVMF. But I only had the 10.4.5 disc, which meant dealing
with the 32-bit limitation.

## Finding the Right ISO

**Q: Can't you just find a newer ISO?**

A: I tried. I downloaded **XxX OS x86 10.4.11** (3GB of hackintosh history). I
mounted it and found only legacy Chameleon BIOS boot files (`boot`, `cdboot`,
`chain0`). No `boot.efi` anywhere. Completely useless for a modern UEFI boot
chain.

Then I found **TIGERMACOSX10411** (2.7GB). I downloaded it, only to discover a
**PowerPC disc** from March 2005. It predated Intel Macs entirely. It held
`BootX`, an artifact from another processor architecture. Furthermore, it was a
corrupt HFS+ image with an invalid secondary volume header that Linux couldn't
mount.

No usable retail Tiger 10.4.8+ Intel ISO could be found online. (I did not look
much into that, just archive)

## The IA32 OVMF Approach

If standard 64-bit OVMF won't run our 32-bit `boot.efi`, we must use 32-bit
OVMF.

I sourced an **OVMF IA32** build (`rust-osdev/ovmf-prebuilt`) and the **OpenCore
1.0.6** IA32 binaries, and built a 256MB GPT EFI disk.

This required fixing several configuration issues:

1. **The Case Sensitivity Trap:** `BOOTIA32.efi` was uppercase. The EFI shell
   expects exact case matching, so the path needed to be updated.
2. **The Vault:** OpenCore expects security (`Vault=Secure`). I had to set it to
   `Optional`.
3. **Firmware Incompatibility:** `OpenRuntime.efi` panicked with IA32 OVMF, so I
   removed it. `OpenHfsPlus.efi` failed on one nightly OVMF build but worked on
   another. The specific firmware version mattered.
4. **The Missing Keyboard:** The OpenCore picker wouldn't register keystrokes
   despite injecting every PS/2 and USB driver (`Ps2KeyboardDxe`, `XhciDxe`,
   `OpenUsbKbDxe`). The fix was to bypass human input entirely by setting
   `ShowPicker=False` and `Timeout=0`.
5. **The YAML Parsing Issue:** Embedding Python in Swamp `cfgmgmt/exec` YAML
   broke on colons. The solution was to base64-encode the scripts and decode
   them at runtime.

### Successful Boot

After fixing the configuration, the boot sequence worked:

The IA32 OVMF loaded IA32 OpenCore. OpenCore read the "Mac OS X Install Disc 1"
HFS+ filesystem. The 32-bit `boot.efi` executed successfully.

The XNU kernel started loading, verbose boot lines appeared on the screen, and
the VM hit 100% CPU on a single core. The kernel was running.

## The Black Screen Issue

Then, the screen went completely black.

The VM was running and the kernel was active at 100% CPU, but there was no
display output.

I cycled through the available QEMU video adapters: `vmvga` (VMware SVGA II),
`vga` (Standard VGA), `cirrus` (Cirrus CL-GD5446). CPU model changes (Nehalem,
Penryn) made no difference.

**Q: Why does the display fail if the kernel is running?**

A: Because macOS Tiger 10.4.5 has **zero framebuffer drivers** for any hardware
that QEMU emulates. `VMwareGfx.kext` wasn't introduced until macOS 10.5 Leopard.
When the kernel takes over from the OVMF's basic GOP framebuffer, it looks for a
hardware driver to handle the display. Finding none, the screen goes black.

QEMU's `screendump` command confirmed it: a 1024x768 blank screen.

## System Modeling

Despite the video output failure, the provisioning process worked as intended.
We managed this setup using Swamp:

- An **`@magistr/libvirt/vm` extension** (`libvirt_vm_tiger.ts`) provisioned the
  VM with Apple SMC, SATA disks, IA32 OVMF, and exact QEMU arguments.
- **`@adam/cfgmgmt/exec` models** fetched the ISOs, built the OpenCore EFI disk,
  and inspected archives.

It was a reproducible, version-controlled system modeling the required
environment.

## The Takeaway

The 32-bit EFI problem is solvable. IA32 OVMF paired with IA32 OpenCore is a
working bridge to Tiger's 32-bit `boot.efi`.

The actual blocker is hardware driver support. Tiger predates the virtual
hardware QEMU provides. The provisioning and boot sequence succeed, but the
process ultimately stops at missing kernel extensions for the display.