The Reboot That Locked Itself Behind a Login Screen

A long-running job on the machine in my office died in the middle of the night. No error, no crash report, no half-written output. It simply wasn't there any more.

The machine itself looked perfect. Responsive, cool, idle. Then I checked how long it had been running: 13 minutes. That job had been going for hours. The server had rebooted underneath the work — a pending operating system update was the most likely trigger — and nothing in my logs had announced it.

Here is the part that took me too long to see. The machine did not come back after that reboot. It came back when I walked over and typed a password into a login screen. Everything else — the services, the remote access, the queued work — had been sitting behind a prompt that only accepts a password typed on the physical keyboard.

An unattended machine has to survive the reboots you didn't schedule

My first instinct was that this was the sleep problem again. That machine used to put itself to sleep and take remote access down with it, and I had fixed that earlier the same day.

It wasn't sleep. Sleep prevention was still working. Services were still set to start at boot rather than wait for a person to log in. Every safeguard I had built was doing exactly what I designed it to do — and every one of them ran after the point where the machine had stopped.

The lesson for businesses: the reboots that hurt are never the ones you scheduled. They are the update that landed at 4am, the power blip, the kernel panic, the cleaner who unplugged something. A recovery plan that only survives planned restarts hasn't been tested.

Full-disk encryption and unattended recovery are in flat contradiction

This isn't a bug, and there's no clever fix for it. It's arithmetic.

Full-disk encryption works by demanding a password before the operating system meaningfully starts. Networking, remote login, the VPN, the scheduled jobs — all of that is software living on the encrypted disk. None of it exists yet at the moment the prompt appears.

So the tool you'd use to rescue the machine remotely is locked inside the thing you're trying to rescue. Every reboot, for any reason, ends the same way: the server waits for hands, indefinitely.

On a laptop this is invisible — the person rebooting it is holding it. On an always-on server with nobody in front of it, the same control quietly converts every restart into an outage that lasts until someone can physically reach the room. That morning it cost me a walk, because I happened to be in the same city. Had I been out of the country for a week, the outage would have been a week.

The encryption was defending a theft that could not happen here

Seen clearly, this stopped being a technical decision and became a question about threat models.

Disk encryption protects data on a drive that leaves your control: a laptop stolen from a car, a machine sent out for repair, a disk decommissioned and resold. Those are real risks, and I take them seriously on anything that travels.

This machine doesn't travel. It sits in a room I control, behind a door with a lock. The realistic attacker who ends up holding that disk has already walked into that room — at which point encryption isn't the control doing the work. The door is.

So I made the trade deliberately: full-disk encryption off, automatic login on, so the machine boots into a working, logged-in state with no human involved.

Be honest about what that is. It's the right answer for one machine with one threat model, and the wrong answer for a laptop that leaves the building, for anything holding client data under a contractual duty to encrypt at rest, or for a machine in a leased space where "the room" isn't a control you own. I'd call all three the other way. Encryption here was defending against something that couldn't really happen, and blocking something that already had.

Recovery is only as automatic as its least automatic step

Look at what was true that morning. Sleep prevention: automatic. Services at boot: automatic. Password at the console: a human being, in a specific building, awake.

Three links, two automated, and the outcome decided entirely by the third. Automated recovery gives no partial credit — the least automatic step sets your real recovery time, and it's usually the step nobody wrote down, because it never felt like part of the system.

Here's an audit you can run this week without touching anything technical. For each always-on system you depend on — the box the phone system runs on, the server behind your internal tools — ask one question: if it restarts itself at 3am and nobody is in the building, does it come back? Then make someone prove it on a Tuesday afternoon. If the answer involves a person, that person is your uptime, and you should know their travel plans.

Make the trade on purpose, or make it at 2am

Nobody chose this configuration. Encryption was on because it's a sensible default — chosen by people protecting laptops that get left in taxis. The server inherited a laptop's assumptions, and the contradiction stayed invisible until something forced a reboot with no one there.

Most of your risk settings are like this: picked by a vendor, for the average machine, which is nobody's machine in particular. Fine, until a default protecting one thing quietly costs you another.

Resolve conflicts like this on a quiet weekday, in writing, with the reason recorded beside the decision. The alternative is resolving it at 2am with a system down and everyone biased toward whatever stops the pain fastest — which is how good controls get switched off for bad reasons and never switched back on.

The bottom line

A security control and an availability requirement can be flatly incompatible, and when they are, you don't get both. Decide which one this particular machine genuinely needs, write down what you gave up and why, and revisit it when the machine's job changes. The failure here wasn't the encryption or the reboot — it was that nobody had ever made the decision.

For the engineers

The mechanism is pre-boot authentication. Full-disk encryption gates the mount of the system volume behind a passphrase typed at the console, served by a minimal pre-boot environment. Networking, the remote login daemon, the VPN client and every service you configured to start at boot live on the volume that hasn't mounted yet. There is no remote path in, because the software that would answer a remote connection doesn't exist until after the volume is decrypted. Wake-on-LAN, sleep prevention and boot-time service start all sit downstream of it.

The symptom was an orphaned background job plus a host reporting 13 minutes of uptime with no reboot I had initiated — the tell that the job hadn't crashed, the host had restarted. A pending OS update was the likely trigger, which is the worst class of trigger: it arrives on someone else's schedule.

The fix: disable full-disk encryption, enable automatic login, so the machine boots to a logged-in session and brings its services up with no input. Then verify it the only way that counts — reboot it deliberately while you're somewhere else, and confirm it returns without a keystroke. An untested recovery path is a belief, not a capability.

The cost is real: pull that drive and it reads. That's the accepted trade for a machine in a room you control, and it belongs in a written decision, not in someone's memory.

This is the close cousin of Your Server Still Thinks It's a Laptop — another machine carrying consumer defaults into a server's job — and it's the same reason Automation That Survives Contact With Reality insists you rehearse the failure, not just prevent it. A security control and an availability requirement can be flatly incompatible; when they are, you don't get both. Decide which one this particular machine genuinely needs, write down what you gave up and why, and revisit it when the machine's job changes. The failure here wasn't the encryption or the reboot — it was that nobody had ever made the decision.

I traded disk encryption for unattended recovery on my own server, on purpose and in writing. If you run always-on systems whose recovery story quietly ends with a person walking into a room — a server wanting a password at the console, a nightly job re-run by hand — a consulting day forces each one through a real unattended reboot and leaves you a written list of what recovers by itself, what needs hands, and which trade-offs you're making deliberately. Book a consulting day or send me an inquiry first if you'd rather talk before booking.