# What does impermanence add over built-in functionality?
**URL:** https://discourse.nixos.org/t/what-does-impermanence-add-over-built-in-functionality/27939
**Category:** Help
**Created:** [May 7, 2023, 7:12pm UTC](https://discourse.nixos.org/t/what-does-impermanence-add-over-built-in-functionality/27939 "2023-05-07T19:12:38Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@nairou](https://discourse.nixos.org/u/nairou)
#### Post date: [May 7, 2023, 7:12pm UTC](https://discourse.nixos.org/t/what-does-impermanence-add-over-built-in-functionality/27939/1 "2023-05-07T19:12:38Z")
The NixOS configuration has `environment.etc`. Home Manager has `home.files`. I’m currently using both to symlink files into place from a persistent location.
As far as I can tell, this is also what Impermanence does. So why do people use it? Does it do a better job? Does it handle directory locations that the default configs can’t?
I assume I don’t need it, but I’m probably missing something.
---
### Author:  [@Damage](https://discourse.nixos.org/u/Damage)
#### Post date: [May 7, 2023, 7:45pm UTC](https://discourse.nixos.org/t/what-does-impermanence-add-over-built-in-functionality/27939/2 "2023-05-07T19:45:48Z")
The idea of impermanence is that upon reboot, the machine loses its state and in the case of NixOS gets recreated from your configuration (stored in a persistent area of your file system). So any erroneous state changes (accidental or otherwise) are lost between reboots.
The persistent area will hold some important data - perhaps ssh keys (depending on type) and passwords that you may need beyond your configuration.nix (or flake)
It does not affect your home folders.
I found Guekka’s blog are good resource - [NixOS as a server, part 1: Impermanence | Guekka's blog](https://guekka.github.io/nixos-server-1/)
I use it - as much to find out more about it as anything else.
If it interests you, try on a spare machine first.
---
### Author:  [@jtojnar](https://discourse.nixos.org/u/jtojnar)
#### Post date: [May 7, 2023, 8:53pm UTC](https://discourse.nixos.org/t/what-does-impermanence-add-over-built-in-functionality/27939/4 "2023-05-07T20:53:08Z")
Please do not post LLM-generated content without verifying that it is correct. This reply is four paragraphs of mostly saying the same vague thing with a few confusingly wrong pieces of information it hallucinated sprinkled in.
---
### Author:  [@dschrempf](https://discourse.nixos.org/u/dschrempf)
#### Post date: [May 8, 2023, 11:16am UTC](https://discourse.nixos.org/t/what-does-impermanence-add-over-built-in-functionality/27939/5 "2023-05-08T11:16:53Z")
For reference: The Nix community provides [GitHub - nix-community/impermanence: Modules to help you handle persistent state on systems with ephemeral root storage [maintainer=@talyz]](https://github.com/nix-community/impermanence) which is amazing.
Whitelist whatever you want to keep. Dump everything else at every reboot. No more [https://github.com/lahwaacz/Scripts/blob/4317390d6c6aaa248d3fbaed177291b3c9d35efe/rmshit.py](https://github.com/lahwaacz/Scripts/blob/4317390d6c6aaa248d3fbaed177291b3c9d35efe/rmshit.py). Finally, we can all sleep piecefully…
---
### Author:  [@TLATER](https://discourse.nixos.org/u/TLATER)
#### Post date: [May 8, 2023, 12:27pm UTC](https://discourse.nixos.org/t/what-does-impermanence-add-over-built-in-functionality/27939/6 "2023-05-08T12:27:32Z")
It also doesn’t do exactly the same thing, rather than symlinking read-only, nix-prepared files into place, it creates read-write bind-mounts of files that nix never touches.
I.e., with `environment.etc` and `home.files` you can instruct nix to put pre-written files created at build-time into places that will exist at runtime, but can never be modified. `environment.persistence` will just make paths available at certain places for reading/writing, but they will be empty by default and are intended to be written at runtime.
> [@Damage](#):
>
> It does not affect your home folders.
Is false, by the way, the impermanence module actually has provisions for doing this in your home directory as well. What gets cleared is entirely up to the user.
---
### Author:  [@nairou](https://discourse.nixos.org/u/nairou)
#### Post date: [May 8, 2023, 12:47pm UTC](https://discourse.nixos.org/t/what-does-impermanence-add-over-built-in-functionality/27939/7 "2023-05-08T12:47:09Z")
> rather than symlinking read-only, nix-prepared files into place, it creates read-write bind-mounts of files that nix never touches
Ah! Okay, this is a bigger difference than I thought. Read/write, and would solve the issue where some programs don’t like their directories to be symlinks.
Thanks!
---
### Author:  [@nairou](https://discourse.nixos.org/u/nairou)
#### Post date: [May 8, 2023, 2:52pm UTC](https://discourse.nixos.org/t/what-does-impermanence-add-over-built-in-functionality/27939/8 "2023-05-08T14:52:23Z")
Another question comes to mind. Does Impermanence _require_ that root get wiped at every boot? Or can it be used like `environment.etc` in that it sets up the link if it doesn’t yet exist?
I’m wondering if I can use Impermanence now to get things organized, and decide to start wiping root at a later time.
---
### Author:  [@dschrempf](https://discourse.nixos.org/u/dschrempf)
#### Post date: [May 8, 2023, 2:55pm UTC](https://discourse.nixos.org/t/what-does-impermanence-add-over-built-in-functionality/27939/9 "2023-05-08T14:55:09Z")
No, it does not require a root `tmpfs`. However, it is conventionally used together with some temporary file system.
I suggest going the opposite route though: Setup a minimal system with a temporary file system and add persistent components whenever you need them.
---
### Author:  [@nairou](https://discourse.nixos.org/u/nairou)
#### Post date: [May 8, 2023, 2:56pm UTC](https://discourse.nixos.org/t/what-does-impermanence-add-over-built-in-functionality/27939/10 "2023-05-08T14:56:40Z")
I’ve already planned for eventually wiping root, I’m using btrfs and have a blank snapshot. I’m just hesitant to pull the plug until I know everything else is working. 🙂
---
### Author:  [@nairou](https://discourse.nixos.org/u/nairou)
#### Post date: [May 8, 2023, 3:00pm UTC](https://discourse.nixos.org/t/what-does-impermanence-add-over-built-in-functionality/27939/11 "2023-05-08T15:00:22Z")
Example: I use a VM, so `/var/lib/libvirt` has data I don’t want to lose. I want to make sure impermanence can safely remap it before I let it go.
---
### Author:  [@TLATER](https://discourse.nixos.org/u/TLATER)
#### Post date: [May 8, 2023, 3:32pm UTC](https://discourse.nixos.org/t/what-does-impermanence-add-over-built-in-functionality/27939/12 "2023-05-08T15:32:04Z")
Yep, totally possible. In fact, since tmpfs requires lots of ram people don’t always have, I think it’s pretty common practice to just use a normal partition to hold the data, and then clear it with `initrd.postDeviceCommands`.
@grahamc - who I believe started this practice with [this blogpost](https://grahamc.com/blog/erase-your-darlings/) - apparently uses an empty zfs snapshot they restore at boot time, for example.
If you just want to test things out you can just not delete your data on boot.
---
### Author:  [@don.dfh](https://discourse.nixos.org/u/don.dfh)
#### Post date: [July 12, 2023, 2:00pm UTC](https://discourse.nixos.org/t/what-does-impermanence-add-over-built-in-functionality/27939/13 "2023-07-12T14:00:16Z")
> [@TLATER](#):
>
> uses an empty zfs snapshot they restore at boot time
I was pondering today if it might be helpful to my journey of adopting impermanence to first snapshot the existing `/` root folder and than reverting to the `blank` snapshot.
That way I should get the benefits of a clean root filesystem without the issues of actually loosing data.
Have others tried this?
---
### Author:  [@Guekka](https://discourse.nixos.org/u/Guekka)
#### Post date: [July 12, 2023, 2:17pm UTC](https://discourse.nixos.org/t/what-does-impermanence-add-over-built-in-functionality/27939/14 "2023-07-12T14:17:26Z")
I haven’t tried it, but it seems interesting. You would need a mechanism to delete old snapshots, though
---
### Author:  [@don.dfh](https://discourse.nixos.org/u/don.dfh)
#### Post date: [July 12, 2023, 3:34pm UTC](https://discourse.nixos.org/t/what-does-impermanence-add-over-built-in-functionality/27939/15 "2023-07-12T15:34:34Z")
> [@Guekka](#):
>
> You would need a mechanism to delete old snapshots, though
The idea is to be able to sort through them manually as I’m planning to start my `impermanence` journey on my working laptop.
Once I feel like having understood the setup well enough I might disable the step.
On the other hand, this might allow for an review/ analysis script 🤔
As I’m looking through blog posts, can someone shed a light on the difference between using
- `boot.initrd.postDeviceCommands = pkgs.lib.mkBefore ` as described in [NixOS as a server, part 1: Impermanence | Guekka's blog](https://guekka.github.io/nixos-server-1/)
- `boot.initrd.postDeviceCommands = lib.mkAfter` as described in [Erase your darlings: immutable infrastructure for mutable systems - Graham Christensen](https://grahamc.com/blog/erase-your-darlings/)
Is this related to `btrfs` vs `zfs` internals?
---
### Author:  [@TLATER](https://discourse.nixos.org/u/TLATER)
#### Post date: [July 13, 2023, 11:42am UTC](https://discourse.nixos.org/t/what-does-impermanence-add-over-built-in-functionality/27939/16 "2023-07-13T11:42:23Z")
I can’t find the post anymore, but someone found that using `postDeviceCommands` is anyway too early for at least btrfs, and can cause data loss. It will also stop working if the systemd init ever becomes the only option.
You’ll _actually_ want something like this: [Impermanence vs. systemd initrd w/ TPM unlocking - #3 by kjhoerr](https://discourse.nixos.org/t/impermanence-vs-systemd-initrd-w-tpm-unlocking/25167/3)
---
### Author:  [@Guekka](https://discourse.nixos.org/u/Guekka)
#### Post date: [July 14, 2023, 6:51am UTC](https://discourse.nixos.org/t/what-does-impermanence-add-over-built-in-functionality/27939/17 "2023-07-14T06:51:40Z")
Interesting. Thanks for the heads up
---
### Author:  [@don.dfh](https://discourse.nixos.org/u/don.dfh)
#### Post date: [July 14, 2023, 12:37pm UTC](https://discourse.nixos.org/t/what-does-impermanence-add-over-built-in-functionality/27939/18 "2023-07-14T12:37:24Z")
Ah sweet!! Thanks @TLATER that pointer has saved me a lot of time as I’m aiming for the Lanzaboote + Impermanence + ZFS combo too.
---
### Author:  [@don.dfh](https://discourse.nixos.org/u/don.dfh)
#### Post date: [July 14, 2023, 1:42pm UTC](https://discourse.nixos.org/t/what-does-impermanence-add-over-built-in-functionality/27939/19 "2023-07-14T13:42:13Z")
> [@TLATER](#):
>
> You’ll _actually_ want something like this: [Impermanence vs. systemd initrd w/ TPM unlocking - #3 by kjhoerr](https://discourse.nixos.org/t/impermanence-vs-systemd-initrd-w-tpm-unlocking/25167/3)
Reading through @kjhoerr config, I found an additional service hardlinking `/persist/etc/machine-id` in a separate `systemd` service, instead of `environment.persistence."/persist".files`
>
What is this required for?
---
### Author:  [@quasimap](https://discourse.nixos.org/u/quasimap)
#### Post date: [July 14, 2023, 3:11pm UTC](https://discourse.nixos.org/t/what-does-impermanence-add-over-built-in-functionality/27939/20 "2023-07-14T15:11:57Z")
If you include `/etc/machine-id` in `environment.persistence."/persist".files`, then the systemd initrd will generate a new /etc/machine-id on every boot. From the Freedesktop documentation,
> Otherwise, if `/etc/machine-id` does not exist, this is a first boot. During early boot, **systemd** will write “`uninitialized\n`” to this file and overmount a temporary file which contains the actual machine ID. Later (after `first-boot-complete.target` has been reached), the real machine ID will be written to disk.
You have to hardlink the file early or else systemd will think it doesn’t exist and then generate a new one.
---
### Author:  [@don.dfh](https://discourse.nixos.org/u/don.dfh)
#### Post date: [July 14, 2023, 8:22pm UTC](https://discourse.nixos.org/t/what-does-impermanence-add-over-built-in-functionality/27939/21 "2023-07-14T20:22:01Z")
> [@Guekka](#):
>
> You would need a mechanism to delete old snapshots, though
I just came across this lovely example in the ZFS wiki named **Rolling Snapshots** [1]
```auto
# zfs destroy -r pool/users@7daysago
# zfs rename -r pool/users@6daysago @7daysago
# zfs rename -r pool/users@5daysago @6daysago
# zfs rename -r pool/users@4daysago @5daysago
# zfs rename -r pool/users@3daysago @4daysago
# zfs rename -r pool/users@2daysago @3daysago
# zfs rename -r pool/users@yesterday @2daysago
# zfs rename -r pool/users@today @yesterday
# zfs snapshot -r pool/users@today
```
This feels like a very elegant solution to the idea of storing the old state “just in case” and delayed auto-cleanup.
[1] [https://openzfs.github.io/openzfs-docs/man/8/zfs-snapshot.8.html#Example\_4\_:\_Performing\_a\_Rolling\_Snapshot](https://openzfs.github.io/openzfs-docs/man/8/zfs-snapshot.8.html#Example_4_:_Performing_a_Rolling_Snapshot)