nixos/filesystems: fix special file-systems for systemd-nspawn #345899
Conversation
|
people use this value for all sorts of containers, not just release notes would be good, but let's see if we can test this change out on a bunch of different container technologies and see if there is any impact? does cc @adamcstephens for informational purposes |
There was a problem hiding this comment.
Thanks @aanderse for the ping. This is indeed a breaking change for incus (and probably lxc) containers.
Perhaps now is a good time to remove some of the overload on isContainer? Maybe this PR could instead introduce an option specifically for nspawn, and condition based on that?
|
I won't run ofborg on these yet, because they won't succeed but incus can be tested by building |
and even further than I was aware of I guess.
Yeah, sounds good. |
the situation may not be so dire... in many cases we can deal directly with |
|
I actually think we want to get rid of |
Sounds reasonable. |
|
worth fixing, but how? so we still need special filesystems or can we already get rid of it and not worry about it anymore? 🤔 |
|
Well, the reason I'm doing this change is to resolve the error I pasted above which occurs when having an nspawn container with its onw Nix store inside and activating a new system configuration in that. For that problem, there's a fix and just because we should probably remove the entire specialFilesystems part (or even all of non-systemd initrd - which I agree with fwiw), it's still worth fixing problems for as long as it exists. |
|
Pushed another commit addressing these concerns. WDYT @aanderse @adamcstephens ? |
7a2dc72 to
c98f5a1
Compare
c98f5a1 to
bc9ab1e
Compare
2acfc45 to
421ce3b
Compare
This is a subset of aba55d1 (NixOS#67336)[1] that I (Ma27) am using for quite a while in my systemd-nspawn setup (without `nixos-container`) to have unprivileged containers. Recently, Linus reminded me that this isn't part of upstream NixOS and their setup fails like this when activating config in an nspawn instance (no shared store): stderr) activating the configuration... stdout) setting up /etc... stderr) mount: /dev: permission denied. stderr) dmesg(1) may have more information after failed mount system call. stderr) mount: /dev/pts: permission denied. stderr) dmesg(1) may have more information after failed mount system call. stderr) mount: /dev/shm: permission denied. stderr) dmesg(1) may have more information after failed mount system call. stderr) mount: /run: permission denied. stderr) dmesg(1) may have more information after failed mount system call. stdout) Activation script snippet 'specialfs' failed (32) So I decided to submit this portion again. [1] Hence I retained the original authorship. Co-authored-by: Maximilian Bosch <maximilian@mbosch.me>
421ce3b to
0bb2e4b
Compare
There are a bunch of components such as incus or LXC that also use `boot.isContainer`, so we'd have to differentiate between "OS container" and "actually nspawn". This became necessary for the file-systems part where nspawn takes care of setting up special filesystems like `/proc`, `/dev` etc., but others don't. To allow for a `boot.isContainer` being less overloaded, this introduces `boot.isNspawnContainer` that is exclusively used for nspawn-specific things. When `true`, `boot.isContainer = true;` is implied.
…ierachy is enabled already
0bb2e4b to
8edd84e
Compare
This is a subset of aba55d1 (#67336)[1] that I (Ma27) am using for quite a while in my systemd-nspawn setup (without
nixos-container) to have unprivileged containers.Recently, @lheckemann reminded me that this isn't part of upstream NixOS and their setup fails like this when activating config in an nspawn instance (no shared store):
So I decided to submit this portion again.
[1] Hence I retained the original authorship.
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.