Something broke after the update: "after" and "because of" are not the same

You updated, you rebooted, something does not work. The first reflex is "the update broke it", and sometimes that is true. But a distinction has to be made first, because it changes the work from the start.

"After" and "because of"

A reboot is the first honest test of everything done since the last reboot. A service started by hand and never added to startup, a mount that was never written into the configuration, a setting changed while running and never saved to a file: all of these have been there for months, and none of them had been exercised until that moment. The reboot reveals them, it does not cause them.

Knowing this pays off, because "roll back the update" does not solve that kind of problem, and because it does not, it sends you the wrong way for hours.

Symptom first, decision second

The real question is not "how do I go back", it is what exactly is broken. There are three families of symptom and they point in three different directions.

The machine does not come up at all. The matter is the kernel or the boot layer. The way back is the previous kernel, and it is usually still there, because updates do not delete old kernels.

The machine comes up but there is no panel. A service did not start. Look at which one and why; this is almost always a single configuration matter, not the whole update.

Everything comes up but something behaves differently. A component genuinely changed. This is where the instinct to go back is most wrong: the right work is to read what changed.

Going back is not free

Rolling back the root filesystem does not only undo the update, it undoes everything since that moment. Settings changed in between, access keys added, other things installed, all of it goes back. Going back is a decision, not a button.

A ladder that starts with the cheapest

Try the narrowest thing first, and if it works, do not touch anything more:

Boot with the previous kernel. It affects only the kernel and leaves the rest as it is.

Put one package back to its earlier version. Its effect is limited to that package.

Roll the system state back as a whole. The most powerful and most expensive one, kept for last.

Write it down before you fix it

Note what you saw: the error line, which service, what time. On the day it starts working the reason disappears, and when the same thing happens three months later you will have nothing left in hand.

What Atlas does

Atlas pins the running kernel before the update. So even when a new kernel is installed, the reboot brings you up on the old one; moving to the new one is a separate and deliberate step. When you do move to the new kernel, the boot guard takes over: it verifies the system genuinely came up healthy and falls back to the old kernel by itself if it did not.

A snapshot of the root filesystem is taken before the update. On ZFS this is cheap and going back takes minutes; on systems without ZFS the package state is stored separately, so not the whole system but the installation state can be undone. The last five pre-update snapshots are kept and older ones are cleaned up.

After the install finishes another check runs: are the critical services up, is cluster agreement still held. So the question "did something break" is asked before you notice.

⚠️ The warning above still stands: rolling the root filesystem back as a whole undoes more than the update. Atlas keeps the snapshot ready, but the decision to go back is yours.