Teaching an Old Dog New Tricks: Reviving a 2015 MacBook Pro with Linux (and an AI Debugging Assist)

9/12/2026

I'm writing this note on my latest weekend project. I've had an old MacBook Pro from 2015 lying around - my daughter had been using it for school, but Apple stopped supporting the hardware on new releases of macOS. Eventually the bit-rot was too real. She needed to run current software so I got her a new machine and put this old laptop on a shelf. It sat there between my humidor and an empty bottle of Four Roses collecting dust. Seemed like a shame to let what seemed like still usable hardware go to waste, so I started a project to dive into the free and open source world. Linux, of course.

After a quick look around the possibility space I landed on Linux Mint as the distro. It was close enough to the Ubuntu systems I've managed before, but had a slightly friendlier UI that drew me in. I wasn't sure what to expect in terms of the struggle to get Linux running on Apple hardware - the last time I played with Linux on Mac it was a painful, slow experience. I spent some blood, sweat, and tears installing Yellow Dog Linux on a Mac G4, an uncomfortably long time ago. I'm happy to report that the situation has improved.

After making a boot drive, the install on the MacBook was smooth. So smooth, in fact, that after hitting a few bumps in the road where the filesystem would slip into read-only mode, I was happy just to start over and re-install. Did that twice. It gets old, and at some point you just want to know what is actually going on - I knew there was some sort of instability that the OS was protecting itself from, but couldn't tell if there was a problem with the drive or something about the old hardware that was going to make this little project a fun exercise that never quite gets off the ground.

This is the twenty-first century though. We have technology that younger me, struggling to run Yellow Dog Linux on a Jobs-era Mac, could not have possibly imagined. That guy had Google and maybe Stack Overflow - this guy has Claude.

Working the actual problem was its own kind of fun - less "here's the answer" and more a real back-and-forth. I'd paste a chunk of kernel log, Claude would form a theory and tell me exactly what to check next, half the time it'd be wrong and we'd rule it out together and go a level deeper. Bad RAM, ruled out. Failing SSD, ruled out. A SATA power-management theory, ruled out. Each dead end actually narrowed things down instead of being a waste of time, and a few rounds of log dumps and commands later we'd zeroed in on what was actually going on.

After a week of use, the stability of the system is there, the fix looks robust, and I'm really enjoying not only running Claude, but getting deeper into the open weight, free, local agentic workflows out there. Opencode is pretty damn good. The free models on their Zen service have been pretty damn good too. Big Pickle has been a nice surprise, and running Ollama locally feels good. Sure, the Mac hardware is still old and has some limits - but it's been fun teaching that old dog new tricks.

With that, here's Claude on the specifics of what we found and how we fixed it:

The technical bit

The filesystem kept remounting read-only mid-session or right after waking from sleep - ext4's self-protective response when it detects it can't trust its own metadata anymore. First instinct was a dying SSD (it's a 2015 machine, RAM and disk hardware failure are the reasonable priors), but SMART came back clean and memtest passed, which ruled both out.

Digging into the kernel logs (journalctl/dmesg) showed the real chain: a host bus error on the SATA controller, right after IOMMU DMA faults (DMAR: ... non-zero reserved fields in PTE). Translation: Linux's generic Intel VT-d (IOMMU) code and Apple's ACPI tables on this hardware don't fully agree on how DMA memory mappings should be validated, and under sustained disk activity, the IOMMU was intermittently rejecting legitimate write requests from the disk controller. Ext4 saw those as I/O failures, aborted its journal to protect data integrity, and remounted read-only.

The fix was a single kernel boot parameter - intel_iommu=off - which disables that IOMMU enforcement entirely. Since this laptop isn't running VMs with hardware passthrough, there's no downside to leaving it off. A week of normal use since, including the workloads that used to trigger it within minutes, and it's been rock solid.