# How To: really atomic updates for NixOS - avoiding breakages

**URL:** https://discourse.nixos.org/t/how-to-really-atomic-updates-for-nixos-avoiding-breakages/63011
**Category:** Guides
**Created:** [April 13, 2025, 1:11pm UTC](https://discourse.nixos.org/t/how-to-really-atomic-updates-for-nixos-avoiding-breakages/63011 "2025-04-13T13:11:44Z")
**Posts on this page:** 20
**Page:** 1

<div class="post-metadata">

### Author: ![BoredSquirrel](https://discourse.nixos.org/user_avatar/discourse.nixos.org/boredsquirrel/32/31935_2.png) [@BoredSquirrel](https://discourse.nixos.org/u/BoredSquirrel)
#### Post date: [April 13, 2025, 1:11pm UTC](https://discourse.nixos.org/t/how-to-really-atomic-updates-for-nixos-avoiding-breakages/63011/1 "2025-04-13T13:11:44Z")

</div>

By default, manuals reference `sudo nixos-rebuild switch` as the way to rebuild the system _ **everywhere** _.

This way swaps out and restarts various components, and can cause a lot of breakages. While in theory it may work, this mechanism has so much entropy (so many moving parts) to it, that atomic updates make more sense.

These imply updates that are staged to the next boot. The current system stays unchanged, and the rebuilt system is staged as the next boot target (NixOS generation).

You do a reboot and select it, the normal and well tested boot process is less likely to fail, and if it does, there is no running system that could break.

```bash
sudo nixos-rebuild boot && reboot

```

---

<div class="post-metadata">

### Author: ![waffle8946](https://discourse.nixos.org/user_avatar/discourse.nixos.org/waffle8946/32/27221_2.png) [@waffle8946](https://discourse.nixos.org/u/waffle8946)
#### Post date: [April 13, 2025, 1:32pm UTC](https://discourse.nixos.org/t/how-to-really-atomic-updates-for-nixos-avoiding-breakages/63011/2 "2025-04-13T13:32:19Z")

</div>

Not to mention, if systemd or the kernel gets an update, you must do a reboot anyway.

---

<div class="post-metadata">

### Author: ![vcunat](https://discourse.nixos.org/user_avatar/discourse.nixos.org/vcunat/32/11_2.png) [@vcunat](https://discourse.nixos.org/u/vcunat)
#### Post date: [April 13, 2025, 1:51pm UTC](https://discourse.nixos.org/t/how-to-really-atomic-updates-for-nixos-avoiding-breakages/63011/3 "2025-04-13T13:51:58Z")

</div>

It depends what kind of changes you deploy. When I do a simple tweak of some config, `switch` is OK (and even better if I don’t want to lose the desktop state). But on larger updates I certainly do the `boot` approach.

Nit: IIRC systemd can self-update during runtime (and some distros do even kernel live patching), but… overall the state transition is too complex to work well for arbitrary upgrades. That’s not just about Nix(OS) itself, but also about upstreams supporting this well.

---

<div class="post-metadata">

### Author: ![TLATER](https://discourse.nixos.org/user_avatar/discourse.nixos.org/tlater/32/4257_2.png) [@TLATER](https://discourse.nixos.org/u/TLATER)
#### Post date: [April 13, 2025, 5:53pm UTC](https://discourse.nixos.org/t/how-to-really-atomic-updates-for-nixos-avoiding-breakages/63011/4 "2025-04-13T17:53:02Z")

</div>

It’d honestly be pretty cool if we had some kind of metadata or at least a heuristic that could show users when a `switch` is enough to fully deploy the new system and when not.

There’s `restartIfChanged` and `reloadTriggers`, which can be used to figure that out for systemd units, and kernel or systemd versions in general are probably pretty easy to identify. Are there any other missing pieces?

---

<div class="post-metadata">

### Author: ![llakala](https://discourse.nixos.org/user_avatar/discourse.nixos.org/llakala/32/38325_2.png) [@llakala](https://discourse.nixos.org/u/llakala)
#### Post date: [April 13, 2025, 7:09pm UTC](https://discourse.nixos.org/t/how-to-really-atomic-updates-for-nixos-avoiding-breakages/63011/5 "2025-04-13T19:09:29Z")

</div>

There is [GitHub - thefossguy/nixos-needsreboot: Determine if you need to reboot your NixOS machine](https://github.com/thefossguy/nixos-needsreboot)… I’ve been meaning to try this out for ages.

---

<div class="post-metadata">

### Author: ![thefossguy](https://discourse.nixos.org/user_avatar/discourse.nixos.org/thefossguy/32/9641_2.png) [@thefossguy](https://discourse.nixos.org/u/thefossguy)
#### Post date: [April 14, 2025, 4:41pm UTC](https://discourse.nixos.org/t/how-to-really-atomic-updates-for-nixos-avoiding-breakages/63011/6 "2025-04-14T16:41:30Z")

</div>

Author here, I got busy with other things and someone else created a fork of it. I’ve been meaning to get at this to make it less worse. At the moment, it doesn’t do anything other than lookup for hash changes and then do a version compare in nix store paths that are in `/nix/var/nix/profiles/system-${generation}-link/sw/bin/${binaryName}`. That too, is for only _some_ packages that _I_ use.

Ideally, it should check for the version by asking Nix, not jump in the Nix store like an AI crawler.

---

<div class="post-metadata">

### Author: ![BoredSquirrel](https://discourse.nixos.org/user_avatar/discourse.nixos.org/boredsquirrel/32/31935_2.png) [@BoredSquirrel](https://discourse.nixos.org/u/BoredSquirrel)
#### Post date: [April 15, 2025, 8:45am UTC](https://discourse.nixos.org/t/how-to-really-atomic-updates-for-nixos-avoiding-breakages/63011/7 "2025-04-15T08:45:52Z")

</div>

Cool! This only makes sense if you always use `nixos-rebuild boot`, right?

---

<div class="post-metadata">

### Author: ![ThePhoenix](https://discourse.nixos.org/user_avatar/discourse.nixos.org/thephoenix/32/38925_2.png) [@ThePhoenix](https://discourse.nixos.org/u/ThePhoenix)
#### Post date: [April 24, 2025, 10:11pm UTC](https://discourse.nixos.org/t/how-to-really-atomic-updates-for-nixos-avoiding-breakages/63011/8 "2025-04-24T22:11:26Z")

</div>

Meant to reply to this thread ages ago (oops!)

When I saw the topic come up I remembered a blog I (18 months in!) a somewhat new person stumbled over on fedi and wished I’d known sooner… As the OP is right - switch is mentioned _everywhere_

Hope it’s useful to others finding this thread in future 🙂

> **[Please Stop Using \`nixos-rebuild switch\`](https://aly.codes/blog/2025-02-07-stop_using_nixos-rebuild_switch/)**
>
> Better practices for safely and reliably deploying and updating NixOS systems.

---

<div class="post-metadata">

### Author: ![Grunty](https://discourse.nixos.org/user_avatar/discourse.nixos.org/grunty/32/31449_2.png) [@Grunty](https://discourse.nixos.org/u/Grunty)
#### Post date: [April 25, 2025, 2:23pm UTC](https://discourse.nixos.org/t/how-to-really-atomic-updates-for-nixos-avoiding-breakages/63011/9 "2025-04-25T14:23:38Z")

</div>

While I appreciate the desire for safe updates and appreciate this guide, this sort of represents a bigger problem. That is, from a user perspective, rebooting after every update is undesirable and cumbersome. There should be better confidence with in-place updates for an end-user OS, I think.

Is there some way I could submit this as something to request dev time on for the next release?

---

<div class="post-metadata">

### Author: ![mastoca](https://discourse.nixos.org/user_avatar/discourse.nixos.org/mastoca/32/28219_2.png) [@mastoca](https://discourse.nixos.org/u/mastoca)
#### Post date: [April 25, 2025, 2:46pm UTC](https://discourse.nixos.org/t/how-to-really-atomic-updates-for-nixos-avoiding-breakages/63011/10 "2025-04-25T14:46:43Z")

</div>

FYI on the post the `nixos-rebuild --dry-activate` should be `nixos-rebuild dry-activate`

---

<div class="post-metadata">

### Author: ![waffle8946](https://discourse.nixos.org/user_avatar/discourse.nixos.org/waffle8946/32/27221_2.png) [@waffle8946](https://discourse.nixos.org/u/waffle8946)
#### Post date: [April 25, 2025, 2:50pm UTC](https://discourse.nixos.org/t/how-to-really-atomic-updates-for-nixos-avoiding-breakages/63011/11 "2025-04-25T14:50:30Z")

</div>

> [@Grunty](#):
>
> rebooting after every update is undesirable and cumbersome.

That’s unnecessary. You do need to reboot after every update to the kernel and init system though (at least with systemd) and likely some other specific cases. That’s overall not a NixOS-specific problem, that’s a general Linux problem.

`switch` is fine for simple changes that don’t require such updates.

---

<div class="post-metadata">

### Author: ![MaxHearnden](https://discourse.nixos.org/user_avatar/discourse.nixos.org/maxhearnden/32/16760_2.png) [@MaxHearnden](https://discourse.nixos.org/u/MaxHearnden)
#### Post date: [April 25, 2025, 3:00pm UTC](https://discourse.nixos.org/t/how-to-really-atomic-updates-for-nixos-avoiding-breakages/63011/12 "2025-04-25T15:00:46Z")

</div>

Systemd can and is updated without a reboot by using `systemctl daemon-reexec` [https://www.freedesktop.org/software/systemd/man/latest/systemctl.html#daemon-reexec](https://www.freedesktop.org/software/systemd/man/latest/systemctl.html#daemon-reexec)

Kernel modules can also be a reason to update as they are loaded from /run/booted-system.

---

<div class="post-metadata">

### Author: ![ksvivek](https://discourse.nixos.org/user_avatar/discourse.nixos.org/ksvivek/32/35158_2.png) [@ksvivek](https://discourse.nixos.org/u/ksvivek)
#### Post date: [April 29, 2025, 9:05am UTC](https://discourse.nixos.org/t/how-to-really-atomic-updates-for-nixos-avoiding-breakages/63011/13 "2025-04-29T09:05:52Z")

</div>

I run `switch` only when I just add/install few packages and options. Not definitely during a full system upgrade.

---

<div class="post-metadata">

### Author: ![iwanb](https://discourse.nixos.org/user_avatar/discourse.nixos.org/iwanb/32/4268_2.png) [@iwanb](https://discourse.nixos.org/u/iwanb)
#### Post date: [April 29, 2025, 1:49pm UTC](https://discourse.nixos.org/t/how-to-really-atomic-updates-for-nixos-avoiding-breakages/63011/14 "2025-04-29T13:49:20Z")

</div>

I quite liked this article on the Fedora Magazine about this problem and why Fedora does offline upgrades: [Restarting and Offline Updates - Fedora Magazine](https://fedoramagazine.org/offline-updates-and-fedora-35/)

NixOS avoids some of the problems by virtue of the nix store being immutable, like an application crashing because a dynamic library changed on disk.  
But as pointed out before, remaining issues like service restart or kernel changes are not solved.

---

<div class="post-metadata">

### Author: ![BoredSquirrel](https://discourse.nixos.org/user_avatar/discourse.nixos.org/boredsquirrel/32/31935_2.png) [@BoredSquirrel](https://discourse.nixos.org/u/BoredSquirrel)
#### Post date: [May 1, 2025, 4:19pm UTC](https://discourse.nixos.org/t/how-to-really-atomic-updates-for-nixos-avoiding-breakages/63011/15 "2025-05-01T16:19:30Z")

</div>

Yes afaik the live `switch` approach would not break the currently booted system (nix generation), so it is safe anyways. But nobody needs ugly system behavior

---

<div class="post-metadata">

### Author: ![TLATER](https://discourse.nixos.org/user_avatar/discourse.nixos.org/tlater/32/4257_2.png) [@TLATER](https://discourse.nixos.org/u/TLATER)
#### Post date: [May 1, 2025, 5:11pm UTC](https://discourse.nixos.org/t/how-to-really-atomic-updates-for-nixos-avoiding-breakages/63011/16 "2025-05-01T17:11:22Z")

</div>

> [@BoredSquirrel](#):
>
> Yes afaik the live `switch` approach would not break the currently booted system (nix generation), so it is safe anyways.

That’s only partially true. If graphics drivers update most graphics applications die.

It’s much safer in headless deployments with no particular attachment to hardware or kernel/systemd versions, but as long as `switch` doesn’t do a full `kexec` (which would negate most of the benefits of `switch` over `boot` anyway) it can never be truly safe.

---

<div class="post-metadata">

### Author: ![arianvp](https://discourse.nixos.org/user_avatar/discourse.nixos.org/arianvp/32/602_2.png) [@arianvp](https://discourse.nixos.org/u/arianvp)
#### Post date: [May 1, 2025, 8:39pm UTC](https://discourse.nixos.org/t/how-to-really-atomic-updates-for-nixos-avoiding-breakages/63011/17 "2025-05-01T20:39:02Z")

</div>

The problem with nixos-rebuild switch is that you can have implicit ordering slip in over time. Say you have service B depend on service A. But service A is started in the first switch and Service B in the second. Nothing broke. Now you reboot and Service A and B start in parallel and B fails.

---

<div class="post-metadata">

### Author: ![Mapybara](https://discourse.nixos.org/letter_avatar_proxy/v4/letter/m/8dc957/32.png) [@Mapybara](https://discourse.nixos.org/u/Mapybara)
#### Post date: [May 1, 2025, 10:27pm UTC](https://discourse.nixos.org/t/how-to-really-atomic-updates-for-nixos-avoiding-breakages/63011/18 "2025-05-01T22:27:57Z")

</div>

I often have a complete system crash when I use switch. I’m not going to bother diagnosing it because I know I can use build instead, but it happens, so that’s a data point.

---

<div class="post-metadata">

### Author: ![senorsmile](https://discourse.nixos.org/letter_avatar_proxy/v4/letter/s/278dde/32.png) [@senorsmile](https://discourse.nixos.org/u/senorsmile)
#### Post date: [May 28, 2025, 3:26am UTC](https://discourse.nixos.org/t/how-to-really-atomic-updates-for-nixos-avoiding-breakages/63011/19 "2025-05-28T03:26:46Z")

</div>

I just verified in a VM that this is not the case. If you do a switch and there’s a new kernel installed, the live system does NOT start using it until you reboot.

---

<div class="post-metadata">

### Author: ![BoredSquirrel](https://discourse.nixos.org/user_avatar/discourse.nixos.org/boredsquirrel/32/31935_2.png) [@BoredSquirrel](https://discourse.nixos.org/u/BoredSquirrel)
#### Post date: [June 23, 2025, 11:01pm UTC](https://discourse.nixos.org/t/how-to-really-atomic-updates-for-nixos-avoiding-breakages/63011/20 "2025-06-23T23:01:49Z")

</div>

Of course not? But all userspace components would be swapped out
