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

nixos: Option for disabling individual special fs #18391

Closed
wants to merge 1 commit into from

Conversation

rickynils
Copy link
Member

Motivation for this change

In some cases, we don't want NixOS to mount certain special
file systems. For example, some container systems handle this
themselves. This commit adds an option for disabling NixOS
management of individual file systems.

Things done
  • Tested using sandboxing
    (nix.useSandbox on NixOS,
    or option build-use-sandbox in nix.conf
    on non-NixOS)
  • Built on platform(s)
    • NixOS
    • OS X
    • Linux
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Fits CONTRIBUTING.md.

In some cases, we don't want NixOS to mount certain special
file systems. For example, some container systems handle this
themselves. This commit adds an option for disabling NixOS
management of individual file systems.
@mention-bot
Copy link

@rickynils, thanks for your PR! By analyzing the annotation information on this pull request, we identified @abbradar, @edolstra and @oxij to be potential reviewers

@domenkozar
Copy link
Member

Would be nice to also have a lxc test case :)

@rickynils
Copy link
Member Author

@domenkozar Yeah. I use libvirt/lxc in my CI setup, so this gets tested implicitly on my end. But it would be nice to have in the official Hydra too. My setup requires nix-daemon to have access to a running libvirtd daemon though, might not be ideal for the official build setup. I haven't looked into setting up LXC without libvirt yet.

# systemd-nspawn populates /sys by itself, and remounting it causes all
# kinds of weird issues (most noticeably, waiting for host disk device
# nodes).
"/sys" = { fsType = "sysfs"; options = [ "nosuid" "noexec" "nodev" ]; };
"/sys" = { enabled = !config.boot.isContainer; fsType = "sysfs"; options = [ "nosuid" "noexec" "nodev" ]; };
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Won't it work to simply have "/sys" = mkIf (!config.boot.isContainer) { ... } in this case, or is something more complicated needed somewhere else?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think so too (optionalAttrs also seems fine) -- otherwise we would need to also support enabled in regular filesystems and I don't think it gives us much benefits.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dezgeg @abbradar No, because then we have to encode too much logic in nixpkgs. For example, the libvirt-lxc container sets up /dev/pts itself and the console breaks if NixOS also mounts it. So we'd like to be able to turn /dev/pts off from an external, LXC-specific module.

Why do we need to support enable in regular filesystems? I can't find any place in nixpkgs where we do something like filesystems = config.boot.specialFileSystems. The regular file systems are different, because NixOS doesn't predefine a bunch of mountpoints in that case.

Btw, I started a general discussion of this "unsetting" of options here: http://lists.science.uu.nl/pipermail/nix-dev/2016-September/021663.html .

Copy link
Member

@abbradar abbradar Sep 7, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it, that sounds reasonable then. A nitpick -- options like those are generally named enable (imperative mood).

Oh, and we then want to move "/sys".enabled to container.nix,

Yet another "oh": we need to support this in fileSystems then because coreFileSystemOpts are reused for fileSystems. Should not be too hard, though.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, yeah it should be enable, I'll change it.

And yes, we should move it to container.nix. Except there is no such file :) I started to try to find the right file to add it to, but got confused about the division between nixos/modules/profiles and nixos/modules/virtualisation. I'll see if I can prepare another PR for cleaning that up a bit, so I can add a proper libvirt-lxc config there too.

OK, I see if I can add it to fileSystems too.

Copy link
Member

@abbradar abbradar Sep 7, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You have already effectively added it to fileSystems, so you need to add filtering to fileSystems at the top of the file (where it's toposorted) and that should be it.

What about modules/virtualisation/containers.nix?

EDIT: sorry, I'm sleepy and haven't noticed you mentioned it _. I think virtualization/containers.nix is the proper place because that's where container options are defined.

@ocharles
Copy link
Contributor

What is the status of this PR? It appears that @abbradar suggested a changed that you were going to work on, is that still relevant?

@mmahut
Copy link
Member

mmahut commented Aug 7, 2019

Any updates on this pull request, please?

@rickynils
Copy link
Member Author

@mmahut My specific use case for this is not relevant any more, and since it was a long time ago, I can't tell if this is generally useful anymore. Do you have a use case where you need this PR? If not, I think it can be closed.

@mmahut
Copy link
Member

mmahut commented Aug 8, 2019

Thank you, if anyone is interested in this, feel free to re-open this issue.

@mmahut mmahut closed this Aug 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants