Two AIs, One Ancient VM, and a Lunch Break
I had a kind of mind-blowing experience with Claude Code recently.
I needed to get an old Debian 4.0 VM running on my Mac — a 2007-era OS and codebase, packaged up as a VirtualBox .ova. Problem is, VirtualBox doesn't run on Apple Silicon. So I fired up Claude Code, started walking through some debugging steps together, and then realised: why am I in the loop here? I should just let it drive.
I spun up two instances in parallel. One to get the VM actually booting. The other to just extract the files from the disk image. Then I went to lunch.
Instance 1: The Boot Whisperer
The first instance switched to UTM/QEMU (which can emulate x86 on ARM), extracted the .ova, converted the disk image, and fixed the boot firmware — swapping UEFI for legacy BIOS and the Q35 chipset for i440FX, because a 2007 kernel is too old for anything modern.
It still hung at "Waiting for root file system…"
The issue turned out to be a controller mismatch. The OVF descriptor showed the disk was originally on SATA (/dev/sda), but UTM had it on IDE (/dev/hda). GRUB and /etc/fstab both had /dev/sda1 hardcoded. Catching the GRUB menu interactively was impossible due to emulation timing, so Claude did something I'd call unhinged: it used Python to scan the raw bytes of the disk image for GRUB's menu.lst and /etc/fstab, found every /dev/sda reference, and binary-patched them to /dev/hda. Same string length, no offset corruption.
Then it booted the VM headlessly, with no display. To see what was happening, it used the QEMU monitor socket to periodically dump the framebuffer to screenshots — and read them to monitor boot progress. It typed the username and password character-by-character via QEMU's sendkey command, took a screenshot, and there it was: a shell prompt.
Instance 2: The Filesystem Archaeologist
The second instance took a completely different approach. No booting at all.
A .ova is a tar containing a .vmdk. A .vmdk is a virtual disk with an MBR partition table. The Linux partition starts at byte 32,256. It's turtles all the way down.
macOS can't read ext2 natively, and every tool it tried — ext4fuse, macFUSE, brew packages, Python libraries — failed. So it wrote an ext2 filesystem reader from scratch in Python. Parsed the superblock, inode tables, block pointers, directory entries, symlinks — all by computing byte offsets into the raw disk image. No tools needed, just the spec.
What Struck Me
Two instances, two completely different strategies, both working autonomously. One reverse-engineered the boot chain and binary-patched a disk image. The other wrote a filesystem parser from scratch to bypass the OS entirely.
I have no idea if there was a "better" way to do any of this — it's technically a solved problem. But these two just went and got it done while I was eating lunch. One patched the image to get it working. The other wrote a reader to extract the files from it.
The VM is from 2007. The AI debugging it is from 2025. What a time.
Originally posted as a thread on Threads.