nixos/filesystems: add systemd dependencies for depends

[lheckemann]

Description of changes

Without this, overlay filesystems lack the dependency metadata required for the systemd-based stage-1 to mount them. This works in the scripted stage-1 since it mounts the filesystems sequentially, and the fstab entries are toposorted taking depends into account. This replicates that logic for systemd.

This isn't a very pretty approach, and I'm open to suggestions on how this could be done more elegantly.

Note also that this isn't all we need to make mounting overlay filesystems from systemd stage-1 work correctly; the mount will fail since the upper/lower/work paths would need to be prefixed with /sysroot -- but just doing that isn't appropriate, since it breaks mounting the filesystem from stage-2. This problem also exists with scripted stage-1.

I suspect we might need to introduce special handling for overlayfs, which generates distinct systemd mount units for stage-1 and stage-2, and warn when users define overlay filesystems using fileSystems.

That said, this PR already improves on what we had before IMHO, so I think we can merge it without yet solving the whole problem.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[ElvishJerricco]

@lheckemann duplicate of #233707?

[RaitoBezarius]

@lheckemann Friendly ping on ^ (I'm triaging my notifications.)

[lheckemann]

Kind of; I'm not sure the sysroot logic really makes sense, because the mount unit generated in the final system isn't correct in that case. See also #270611 for more discussion of the problem (and a potential solution).

[ElvishJerricco]

@lheckemann The idea of putting things in /run is intriguing, but it's worth noting that it requires that any depends can only be on something in /run. There are certainly scenarios where that won't work, e.g. when you want an overylay's upper dir to be persistent.

This is an extremely frustrating problem, and honestly I think the answer is a systemd feature. I think we want "chroot mount units" or something. I've tried to hack this together manually with RootDirectory= on mount units, but I don't think it can be done currently.

[lheckemann]

Yeah, I like the idea of chrooting the mount in principle, but it's complicated significantly by mount helpers which need to be exec'd (how do you ensure that they're there? how do you find them (especially in our non-FHS case)? and what if you want to use the helpers from the initrd?). I've spent some time thinking about the problem and the only real conclusion I've drawn so far is that the design of mounts and mount namespaces just kind of sucks for what we want to do :(