Part I: The Equipment

They sent me to Mexico City with three Sun servers and one hard disk.

I was twenty-three, maybe twenty-four. Still green enough to think preparation meant documentation. I had printed manuals, customs forms, letters of intent — everything official, everything proper. The servers were for a demo. Important people would be there. A jail administrator, they said, though I never quite understood why a jail needed to see an Oracle database demonstration.

The machines were beautiful. Heavy metal boxes that hummed with purpose, SCSI drives spinning at 10,000 RPM, enough RAM to make your eyes water. Enterprise hardware. Professional.

The backup disk was from one of our smaller machines. Just in case, they said. Insurance.

I didn't know it would be the only thing that mattered.

Part II: The Border

Mexico City customs in 1999 was a place where logic went to die.

The agent looked at my paperwork. Looked at the servers. Looked at me.

"These require an importer," he said.

"I have documentation," I said. "It's for a demonstration. We're not importing them permanently."

He shrugged. The universal gesture of bureaucracy: not my problem, not my jurisdiction, not today.

The servers stayed. All three of them. Beautiful, expensive, and utterly useless to me behind a customs barrier I couldn't cross.

I had one week until the demo.

I had one hard disk in my bag.

Part III: The City

Mexico City in summer is a kind of organized chaos. Eight million people moving through streets laid out by the Spanish on top of Aztec canals on top of a lake that isn't really there anymore. Everything sinks. Everything shifts.

I spent three days working on phone calls, trying to get the servers released. The answer was always the same: paperwork, importers, procedures, mañana.

On day four, I stopped hoping customs would help.

I started looking for Sun servers in Mexico City.

The people I was working with — local techs, the demo team, partners — they understood. They made calls. Someone knew someone who knew someone who had a Sun workstation. Not the same model. Not even close. But it was Sun hardware, and that's what mattered.

We borrowed it. Rented it. I don't even know. I just know we got it to the venue.

Part IV: The Signature

This is where I learned something about Solaris that no manual ever taught me.

Every Sun machine had a hardware signature. A unique ID is burned into the system board. The disk I carried — the backup disk from our small server — it knew its home. It had expectations.

When I installed it in the borrowed machine, it booted. For about thirty seconds, I thought I'd pulled it off.

Then: kernel panic. Hardware mismatch. System ID conflict.

The disk was looking for its original motherboard. The borrowed machine was telling it: I'm not who you think I am.

I had two days until the demo.

Part V: The Night Shift

I won't pretend I solved it alone.

There was a local admin — I wish I remembered his name — who knew Sun systems the way a mechanic knows engines. Not from manuals. From hours of broken hardware and desperate fixes.

"The hostid," he said. "You need to change the hostid."

It sounded simple. It wasn't.

The system hostid was burned into the NVRAM. Changing it meant booting into the OpenBoot PROM, manually resetting values, then convincing Oracle — which had its own ideas about licensing and hardware IDs — that this was the same machine it had always been running on.

We worked through the night. Hex values in NVRAM. License keys that didn't quite match. Database instance IDs that pointed to non-existent hardware.

By 4 AM, we had it booting.

By 6 AM, Oracle was starting.

By 8 AM, I could run queries.

The demo was at 10 AM.

Part VI: The Van

The borrowed Sun server was downtown. The convention center was twenty kilometers away, through Mexico City morning traffic.

We loaded the server into a van. Not a truck. Not a proper equipment transport. A van. The kind you'd use to move furniture.

I sat in the back, holding the server steady as the driver navigated traffic like he was playing a video game. Every pothole felt like a minor earthquake. Every sharp turn made the server slide.

I kept thinking about the hard disk inside, which spins at 10,000 RPM when operating, with heads floating microns above the platters. One good jolt and I'd be carrying a very expensive paperweight to the demo.

We made it.

Part VII: The Demo

The jail administrator — if that's what he was — sat in the front row. Important people flanked him. They had that look of people who expect to be impressed.

I was exhausted. Wired on coffee and adrenaline. My hands were shaking slightly as I powered on the system.

Boot sequence. Oracle starting. Database mounting.

It came up clean.

I ran the demo. Queries executed. Reports generated. Data flowed across the screen as it had always done, as if the past seventy-two hours of chaos had never happened.

No one in the audience knew.

They saw a polished demonstration of enterprise database technology. Professional. Smooth. Exactly what they'd been promised.

I saw something else: every hack, workaround, and desperate fix that made it possible. The customs hold. The borrowed hardware. The NVRAM surgery. The van ride through morning traffic.

Afterward, people shook my hand. Congratulated me on a successful demo.

I said thank you.

I didn't say that I'd spent three days trying to trick a hard disk into forgetting what machine it belonged to.

Epilogue: What I Learned

Twenty-five years later, what I remember isn't the demo.

It's the feeling of sitting in that van, holding a Sun server steady with both hands, watching Mexico City traffic blur past the windows, knowing that everything depended on a spinning disk, not noticing it was in the wrong body.

I learned something about systems that week. Not the official version — the documented procedures, the support contracts, the proper channels. The real version.

Systems are fragile. They have expectations. They know where they belong. And when you ask them to work somewhere else, with different hardware, under different IDs, they resist.

Sometimes you can convince them. Sometimes you can trick them. Sometimes you can rewrite their memories just enough that they forget they're not supposed to work.

But it's never clean. It's never documented. And it always comes down to someone, somewhere, in the middle of the night, changing hex values in NVRAM and hoping they guessed right.

I still have the documentation I brought to customs. Useless paper.

I don't have the name of the admin who taught me how to change a hostid. I wish I did.

That's the thing about real technical work. The official stuff is easy to remember. It's the desperate improvisation, the people who helped, the solutions that shouldn't have worked but did — that's what matters, and that's what we forget.

I try not to forget.

***

Dog Years: Seventy-two hours to trick a hard disk into forgetting which machine it belonged to. Sometimes the solution isn't in the manual. Sometimes it's a van ride through Mexico City traffic, holding a server steady with both hands, hoping it doesn't notice it's in the wrong body.

***

This is part of the Dog Years series — tales from the trenches of enterprise IT, where one year of production fires equals seven years of wisdom.

What's your Dog Years story? Share in the comments.