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.

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.