Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for ZFS Systemd Mount generator #62644

Open
Echaleon opened this issue Jun 4, 2019 · 8 comments
Open

Support for ZFS Systemd Mount generator #62644

Echaleon opened this issue Jun 4, 2019 · 8 comments

Comments

@Echaleon
Copy link

Echaleon commented Jun 4, 2019

Recently, support for a systemd mount generator landed in ZFS stable, and support for it is present in both 0.7.13 and 0.8.0. It's fairly simple to use, and works successfully on Arch, though it doesn't (yet) support encrypted datasets, though it's fairly easy to write your own unit file.

The benefit of this is that it allows the use of native ZFS mountpoints, streamlining administration. Using it is fairly simple, with just a few lines of code: https://zfsonlinux.org/manpages/0.7.13/man8/zfs-mount-generator.8.html

Relevant issues and merge requests:
openzfs/zfs#7329
openzfs/zfs#8750
openzfs/zfs#8848

I've used this on Arch and it works wonderfully. I would try and do the integration myself, but my nix skills are not up to par yet.

@fpletz fpletz added this to To Do in systemd via automation Jun 4, 2019
@ElvishJerricco
Copy link
Contributor

We would need to make sure file systems mounted this way aren't present in /etc/fstab. Not sure what the right way to do that would be, considering the file systems will be in hardware-configuration.nix.

@stale
Copy link

stale bot commented Jun 1, 2020

Thank you for your contributions.
This has been automatically marked as stale because it has had no activity for 180 days.
If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.
Here are suggestions that might help resolve this more quickly:

  1. Search for maintainers and people that previously touched the
    related code and @ mention them in a comment.
  2. Ask on the NixOS Discourse. 3. Ask on the #nixos channel on
    irc.freenode.net.

@stale stale bot added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Jun 1, 2020
@emilazy
Copy link
Member

emilazy commented Jun 3, 2021

not stale

@stale stale bot removed the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Jun 3, 2021
@ghost
Copy link

ghost commented Mar 22, 2023

I'm maintaining the Alpine, Fedora, RHEL (Alma), Arch Linux and NixOS Root on ZFS guides. The systemd mount point generator causes a lot of headaches. Use legacy mount point with fileSystems if possible.

  • It depends on zed to generate entries in /etc/zfs/*. Especially with NixOS, we want the system root to be empty and stateless, and the generater would not work in this case.
  • It is generated from ZFS dataset properties. Ideally, all system configuration should be only managed by NixOS. There should not be such surprises as "oh, I forgot I configured this mount point with ZFS, not NixOS".
  • Especially with Root on ZFS, it depends on systemd and can not handle mounting important system mount points such as /var/lib correctly.

@ElvishJerricco
Copy link
Contributor

The systemd mount point generator causes a lot of headaches.

I've been using the mount generator for like a year and a half on one of my systems and have had no troubles.

Especially with NixOS, we want the system root to be empty and stateless

Ideally, all system configuration should be only managed by NixOS

I think this is not exactly accurate. For a stateless system, sure, I guess. But for many use cases, file systems are a part of the inherently stateful problems that they're trying to solve. And to that end, I think it's reasonable in many cases to want to keep stateful things out of the Nix config, particularly so that the system can be rolled back or rebuilt with minimal concern for the state of the disks. So wanting file systems to be defined with non-legacy mountpoints, and/or with gpt-auto-generator, or whatever else, outside of the Nix config, seems like a valid use case that it would be nice to support.

TL;DR: I really don't think it's ok for us to just blanket tell people they should only use legacy mountpoints. There's plenty of reasons you might not want to.

@gkleen
Copy link
Contributor

gkleen commented Mar 22, 2023

@ElvishJerricco

I've been using the mount generator for like a year and a half on one of my systems and have had no troubles.

Are you using it on a NixOS system?
I'd be interested in taking a look at the configuration if you'd be willing to share it.

@ElvishJerricco
Copy link
Contributor

ElvishJerricco commented Mar 22, 2023

@gkleen This is what I have.

  systemd.generators."zfs-mount-generator" = "${config.boot.zfs.package}/lib/systemd/system-generator/zfs-mount-generator";
  environment.etc."zfs/zed.d/history_event-zfs-list-cacher.sh".source = "${config.boot.zfs.package}/etc/zfs/zed.d/history_event-zfs-list-cacher.sh";
  systemd.services.zfs-mount.enable = false;

  services.zfs.zed.settings.PATH = lib.mkForce (lib.makeBinPath [
    pkgs.diffutils
    config.boot.zfs.package
    pkgs.coreutils
    pkgs.curl
    pkgs.gawk
    pkgs.gnugrep
    pkgs.gnused
    pkgs.nettools
    pkgs.util-linux
  ]);

It basically just enables the generator and disables zfs-mount.service. Then it needs diffutils added to the zed.settings.PATH, but that option doesn't properly append different definitions so I had to mkForce it and copy the nixpkgs default for it.

I copied it from someone else, but unfortunately I can't remember who :P

@ConnorBaker
Copy link
Contributor

@ElvishJerricco thank you for sharing that; I was running into similar problems discussed in this thread but using that snippet fixed things for me. I no longer need to specify boot.zfs.forceImportAll!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
systemd
  
To Do
Development

No branches or pull requests

6 participants