What does impermanence add over built-in functionality?

Help
2

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
I use it - as much to find out more about it as anything else.
If it interests you, try on a spare machine first.

3 Likes
3

I’ve no answer, but I was curious, so I asked Vicuna-13b. The answer:

Impermanence is a NixOS module that provides a convenient way to manage ephemeral files and directories, which are files or directories that are intended to be created and destroyed as needed. It is designed to make it easy to manage these types of files and directories, and to ensure that they are created and destroyed correctly when needed.

One of the key benefits of using Impermanence over the built-in NixOS functionality is that it provides a more user-friendly interface for managing ephemeral files and directories. Instead of having to use the NixOS configuration files or other command-line tools to create and manage these files, you can use the Impermanence module to do so in a more intuitive and convenient way.

Additionally, Impermanence may offer additional features or capabilities that are not available in the built-in NixOS functionality. For example, it may provide additional options for customizing the behavior of ephemeral files and directories, or it may offer better support for managing these files across multiple systems or environments.

Ultimately, whether or not you should use Impermanence depends on your specific needs and requirements. If you are comfortable using the built-in NixOS functionality to manage ephemeral files and directories, then you may not need to use Impermanence. However, if you prefer a more user-friendly interface or need additional features or capabilities, then Impermanence may be a good option to consider.

1 Like
4

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.

33 Likes
5

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] 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. Finally, we can all sleep piecefully…

3 Likes
6

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.

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.

3 Likes
7

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!

8

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.

9

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.

10

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. :slight_smile:

11

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.

12

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 - 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.

1 Like
13

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?

14

I haven’t tried it, but it seems interesting. You would need a mechanism to delete old snapshots, though

15

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 :thinking:

As I’m looking through blog posts, can someone shed a light on the difference between using

Is this related to btrfs vs zfs internals?

16

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

1 Like
17

Interesting. Thanks for the heads up

18

Ah sweet!! Thanks @TLATER that pointer has saved me a lot of time as I’m aiming for the Lanzaboote + Impermanence + ZFS combo too.

19

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?

20

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.

3 Likes
21

I just came across this lovely example in the ZFS wiki named Rolling Snapshots [1]

# 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

2 Likes