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
Imperative containers broken on 18.03/nixos-unstable #40355
Comments
I can confirm this issue on a clean 18.03 install. To reproduce:
|
This issue sees related NixOS/nix#2134 |
That’s the error messages you get when you try using nix |
This doesn't seem to be the issue. the container is running the same nix version, it seems:
Interestingly enough, the command |
Aha, I think I found the culprit
|
In nix 1.12, this lock was never acquired. So it was not a problem that However, acquiring the lock throws an Previously, the function would return on |
I'm not very familiar with the |
You can work around this for now by remounting /nix/var/nix/db as read/write within the container: |
Oh great! Thanks. Perhaps we should just add that line in the container
code.
…On Thu, Jul 12, 2018, 11:51 goibhniu ***@***.***> wrote:
You can work around this for now by remounting /nix/var/nix/db as
read/write within the container:
mount -o remount,rw /nix/var/nix/db
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#40355 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAmWoykF85d4gE2TC_68QCRV5s3G3S-Vks5uFxwGgaJpZM4T7kQ5>
.
|
Making the host nix database writable in the container is a very bad idea, eg.
|
So how should the container connect to the host's nix-daemon? Docs read like it's only possbile to connect over ssh, or could you expose it as a file-based socket too? |
Yes. It's a unix domain socket, running nix commands as an unprivileged user also use this to communicate with the daemon. By default it's located at
|
I'm afraid I don't know about the internals, but containers do work for me as long as I stick with e.g. |
Nix commands inside the container have been broken since 18.03, and no fix is yet in sight. Lets remove from the documentation that this is a usecase that we support, as it doesn't seem likely that this will be fixed before 18.09 either. See NixOS#40355
@reinhardt I've updated the docs to reflect this |
Okay, after some digging, I have found out what is going wrong, and how we can fix it. Because we are user The solution is to force the
When we are not the
We should add the |
Nice catch! |
When logging into a container by using nixos-container root-login all nix-related commands in the container would fail, as they tried to modify the nix db and nix store, which are mounted read-only in the container. We want nixos-container to not try to modify the nix store at all, but instead delegate any build commands to the nix daemon of the host operating system. This already works for non-root users inside a nixos-container, as it doesn't 'own' the nix-store, and thus defaults to talking to the daemon socket at /nix/var/nix/daemon-socket/, which is bind-mounted to the host daemon-socket, causing all nix commands to be delegated to the host. However, when we are the root user inside the container, we have the same uid as the nix store owner, eventhough it's not actually the same root user (due to user namespaces). Nix gets confused, and is convinced it's running in single-user mode, and tries to modify the nix store directly instead. By setting `NIX_REMOTE=daemon` in `/etc/profile`, we force nix to operate in multi-user mode, so that it will talk to the host daemon instead, which will modify the nix store for the container. This fixes NixOS#40355
When logging into a container by using nixos-container root-login all nix-related commands in the container would fail, as they tried to modify the nix db and nix store, which are mounted read-only in the container. We want nixos-container to not try to modify the nix store at all, but instead delegate any build commands to the nix daemon of the host operating system. This already works for non-root users inside a nixos-container, as it doesn't 'own' the nix-store, and thus defaults to talking to the daemon socket at /nix/var/nix/daemon-socket/, which is bind-mounted to the host daemon-socket, causing all nix commands to be delegated to the host. However, when we are the root user inside the container, we have the same uid as the nix store owner, eventhough it's not actually the same root user (due to user namespaces). Nix gets confused, and is convinced it's running in single-user mode, and tries to modify the nix store directly instead. By setting `NIX_REMOTE=daemon` in `/etc/profile`, we force nix to operate in multi-user mode, so that it will talk to the host daemon instead, which will modify the nix store for the container. This fixes #40355 (cherry picked from commit 3624bb5)
Issue description
I upgraded an imperative container from 17.03 to 18.03 with nixos-unstable on the host: 18.09pre139319.1d9330d63a5 (Jellyfish), and now I can no longer run any nix commands:
I also tried creating a fresh container and it breaks in the same way.
Technical details
nix-info
on the container fails with:error: opening lock file '/nix/var/nix/db/big-lock': Read-only file system
system: 0, multi-user?: no, error: opening lock file '/nix/var/nix/db/big-lock': Read-only file system
version: 0, error: opening lock file '/nix/var/nix/db/big-lock': Read-only file system
nix-info
on the host system:system: "x86_64-linux", multi-user?: yes, version: nix-env (Nix) 2.0.2, channels(goibhniu): "nixos-18.03pre120540.b8f7027360", channels(root): "nixos-18.09pre139319.1d9330d63a5", nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs
The text was updated successfully, but these errors were encountered: