Wiping a Computer You Can't Touch

There's a particular kind of nerve it takes to reboot a computer you cannot physically touch, knowing the next thing it does is erase itself. No monitor, no keyboard, no one in the room. If it hangs halfway, it's a paperweight until someone drives over. We did it anyway last night — turned a living-room Windows media PC into a headless Debian server, entirely over the network, and it came back clean on the first try. Here's how, and more importantly, the two things that made it safe rather than reckless.

For full transparency on the nobody in the room part: the human end of this was a phone. The wipe was kicked off between a taco order at Torchy's and a stop at Smoothie King, and the box reported back for duty from a bench at the park. Not a leap of faith, either — when the architecture, the documentation, and the guardrails are all doing their jobs, firing off a remote wipe from a picnic table isn't reckless. It's just the tooling being good enough to trust.

The problem

A consumer mini-PC — no out-of-band management, no remote console, none of the lights-out tooling a real server gives you. Just SSH into Windows, and a person a car-ride away. The goal: wipe Windows, install Linux, and have the box rejoin the network on its own.

The mechanism

Modern Windows machines ship with Secure Boot on, which is the first thing people assume blocks this. It doesn't — it just dictates the shape. The trick is to stage a signed boot chain the firmware already trusts:

1. Stage the installer onto the EFI partition from inside Windows, over SSH: the Microsoft-signed shim, the distro-signed grub, an installer kernel, and an initrd — all things the firmware will happily load under Secure Boot.
2. Embed the answer file inside the initrd. A fully-automated install normally fetches its config over the network at a fragile moment. Baking it into the initrd means the installer already knows every answer before it has a network — one less thing that can strand the box.
3. One-shot boot with the old OS as the fallback. Firmware boot managers support a "boot this exactly once, then revert" setting. So if staging failed and the installer never even starts, the very next power cycle lands back in Windows. Nothing lost.
4. The installer runs in RAM. Once it's up, it no longer depends on the disk it's about to erase — which is what makes wiping the drive out from under a running system sane instead of insane.

Then you watch the network for the box to reappear with a new identity, SSH in, and finish provisioning.

Lesson one: a backup you didn't verify is a rumor

The owner's read on the drive being wiped was "there's probably nothing important on it." Reasonable — it was a TV PC. The first backup pass, a plain recursive copy over SSH, reported success: a gigabyte or so, thousands of files, done.

Except it was mostly one dormant user profile. The active profiles came back as empty shells — because Windows locks files that are in use (registry hives, browser state, cloud-sync folders), and a naive copy just skips them and moves on, reporting a cheerful exit code.

The fix is Volume Shadow Copy — the OS makes a frozen, consistent snapshot of the whole volume, locked files and all, and you back up that. The re-run pulled 25 GB and 80,000+ files the first pass had silently walked past, including thousands in the owner's own profile. The "probably nothing" drive was not, in fact, nothing.

The lesson isn't "use VSS," though you should. It's: the question is never "is there a backup?" It's "when did it last succeed, and did I look at what's actually inside it?" Verify per-item, not by a green checkmark and a plausible file count.

Lesson two: design the failure so the worst case is boring

The machine had a second disk attached — several terabytes of media on external storage — that absolutely must not be touched. On an unattended install, "select the right disk" is exactly the kind of assumption that eats your data at 2 a.m.

So the install config carried a guard that refuses to proceed unless the target disk matches the expected size, within a tight window. Wrong disk, missing disk, surprise hardware change — the installer parks itself and does nothing rather than guess. The media drive was structurally unwipeable: not because we told it the right answer, but because we made the wrong answer impossible to act on.

This is the whole philosophy in one move. You cannot prevent every failure on a box you can't reach. What you can do is arrange things so that every failure mode you didn't prevent is recoverable and boring — the installer waits, the old OS boots back up, the untouched drive stays untouched — instead of catastrophic and silent.

The result

The box came back on the first attempt as a fresh headless server. The media drive: verified present, every byte intact. The old OS: gone as intended, but fully backed up first — including the 25 GB nobody thought was there.

Rebooting a machine you can't touch to erase itself will always be a small act of faith. The craft is in spending that faith wisely: prove the boot chain before you fire it, snapshot what you're destroying and read the snapshot, and build guards that fail toward "nothing happened" instead of "everything's gone." Do that, and the nerve-wracking part turns out to be the easy part — easy enough to do one-handed, over a taco, without missing the good weather.