It'd be cool to have a single image with

• nix (like nixpkgs/nix)
• podman

Such a docker image could be used to build other docker images in GitLab CI/CD using nix (e.g. with jupyterWith) and then pushing them to the GitLab container image registry with podman. Doing this with two separate GitLab CI/CD jobs that can run in containers from two separate images (one with nix, another with either docker or podman) is sometimes not feasible, because the resulting image might be too big to pass it as artifact between GitLab CI/CD jobs of a GitLab CI/CD pipeline.

I'm trying to use the nix-flakes image to work with flakes in a CI pipeline (droneCI).
Trying to run commands that require experimental-features fails, even though I'm using the nix-flakes image, this is what I'm trying:

kind: pipeline
name: default
type: docker

platform:
  os: linux
  arch: amd64

steps:
- name: Show flake info
  image: nixpkgs/nix-flakes
  commands:
  - nix flake show
  - nix flake info
  - nix flake list-inputs
  environment:
    NIX_PATH: nixpkgs=channel:nixos-unstable

I get the following error in the output:

latest: Pulling from nixpkgs/nix-flakes
Digest: sha256:198cc4134cf0607571fa36c7470ffc80374bb1decc153c850d6691f409fba011
Status: Image is up to date for nixpkgs/nix-flakes:latest
+ nix flake show
error: --- Error --- nix
experimental Nix feature 'nix-command' is disabled; use '--experimental-features nix-command' to override

What is the way to use flakes with the docker images? Am I using the correct image at all?

Any plan to support aarch64 nix images?

Workaround:
In pkgs.nix, change x86_64-linux to aarch64-linux and build (nix-build -A nix-flakes)

It's critical for the cases where some directories are mounted, and I definitely don't want to root them. Previously I was able to run dockerized nix-shell with mounted directories as non-root user this way:

https://github.com/coingaming/src/blob/dab692ec0171d4c789bc60c5bbf4ede6b7e43516/btc-lsp/nix/hm-shell-docker.sh#L40-L56

With nixpkgs/nix this is not working because adduser is not in scope.

I originally left a comment over in nix-community/docker-nix#21 - just repeating it here:

I don't fully understand how docker-nixpkgs are meant to be used. For example, what one probably tries first is:

docker run -ti --rm nixpkgs/nix-unstable:latest

but then

bash-4.4# nix-env -iA nixpkgs.git
error: getting information about '/root/.nix-defexpr': No such file or directory

So I'm missing something?

On my system I currently cannot use the nixpkgs/curl container:

$ docker run nixpkgs/curl curl https://nixos.org
curl: (6) getaddrinfo() thread failed to start

Can you reproduce this, too, or do you need more details?

I have defined an image for nix-linter following the existing images' examples,

{ buildCLIImage
, nix-linter
}:
buildCLIImage {
  drv = nix-linter;
}

and when I try to run it, I get a "permission denied" error:

$ podman run --rm localhost/nix-linter-0.2.0.3:rfj89prik95nb35nrpsrr1cf5ik8323i nix-linter --recursive .
nix-linter: /proc/tty/driver: getDirectoryContents:openDirStream: permission denied (Permission denied)

Other images from this repository run fine under podman, so I don't think it's a podman issue.

Using the nix-flakes image, I've had a few troubles recently on my gitlab CI:
1/ I used to hit sh: error while loading shared libraries: liblowdown.so: cannot open shared object file: No such file or directory
I tried to bump the image to use
image: nixpkgs/nix-flakes@sha256:5a85a3a26c0a2017228aec8bfa0b1bf397d1f2f5972ab543e5eb281c018fd48c
and now I get
2/ sh: error while loading shared libraries: libreadline.so.8: cannot open shared object file: No such file or directory
when trying to run nix build --extra-experimental-features 'nix-command flakes' .

Hi!

Now that 24.05 is out and stable, it'd be good to get a bump for https://hub.docker.com/r/nixpkgs/cachix-flakes/tags too (happy to try a PR if that helps)

Thanks

See Image Matrix on README.md:
https://github.com/nix-community/docker-nixpkgs/blob/master/README.md

See tags on docker hub:
https://hub.docker.com/r/nixpkgs/nix/tags

In my CI, I like to pin the docker image with for instance
nixpkgs/nix-flakes@sha256:4ff08e134a935c3e94b04cbffb96680e1beed887335ee67dd1570fca8bf8f094
it looks like that image disappears every day after the CI round and is replaced with the new one
https://hub.docker.com/layers/nixpkgs/nix-flakes/latest/images/sha256-707623a2cc8d0bfba8ac7b07b20f954c55a148f481c15821d23851953b2ab91a?context=explore
(docker pull nixpkgs/nix-flakes@sha256:4ff08e134a935c3e94b04cbffb96680e1beed887335ee67dd1570fca8bf8f094 fails for instance)

1/ Is this correct ?
2/ is it possible to keep past versions up ? or should I reference for instance nixpkgs/nix-flakes:nixos-21.05 . Alternatively I could upload to hub.docker.com my copy of the image but if I can avoid it ^^

It seems like our current tooling just replaces the previous tagged image when pushing the aarch64 image.

$ podman pull docker.io/nixpkgs/nix-flakes
Trying to pull docker.io/nixpkgs/nix-flakes:latest...
Getting image source signatures
Copying blob edcd22323b9f done   | 
Copying config 0a685f731e done   | 
Writing manifest to image destination
WARNING: image platform (linux/arm64) does not match the expected platform (linux/amd64)
0a685f731e6c5b1d65c22ff2dee3d51ee2a6b709d014e3923b48cd9e16c62d61

I tried to run different images on a macbook and got errors about a problem with the Exec format.

I didn't inspect the image layout so I don't know if the binaries are not put in the correct directory or if docker and podman understand differently the CMD instruction

Even a basic podman run -ti --rm nixpkgs/bash bash doesn't work

Travis CI is finally dead. Move things to GitHub Actions.

Description:
When running docker info | grep cgroupos, a warning is displayed indicating the absence of cpuset support:

WARNING: No cpuset support

Upon further investigation, it seems that cgroup2 is mounted:

mount | grep cgroup2
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)

Furthermore, examining the content of /proc/cgroups, it shows that cpuset is enabled:

| subsys_name | hierarchy | num_cgroups | enabled |
|-------------|-----------|-------------|---------|
| cpuset      | 0         | 112         | 1       |
| cpu         | 0         | 112         | 1       |
| cpuacct     | 0         | 112         | 1       |
| blkio       | 0         | 112         | 1       |
| memory      | 0         | 112         | 1       |
| devices     | 0         | 112         | 1       |
| freezer     | 0         | 112         | 1       |
| net_cls     | 0         | 112         | 1       |
| perf_event  | 0         | 112         | 1       |
| net_prio    | 0         | 112         | 1       |
| hugetlb     | 0         | 112         | 1       |
| pids        | 0         | 112         | 1       |
| rdma        | 0         | 112         | 1       |
| misc        | 0         | 112         | 1       |
| debug       | 0         | 112         | 1       |

This table provides a clear overview of the subsystem names, hierarchy, number of cgroups, and whether they are enabled.

Despite cpuset being enabled in the cgroups hierarchy, Docker still reports the absence of cpuset support.

This discrepancy raises concerns about Docker's performance and behavior, especially for containers relying on cpuset functionalities.

Could you please advise on how to resolve this inconsistency and ensure optimal Docker performance in this environment?

Would be nice to have this documented, like why use one over the other.

ref: NixOS/nix#5368

nixpkgs/cachix-flakes for example has the same problematic version: nix (Nix) 2.5pre20211007_844dd90

Trying to use these images in GitHub Actions gives an error, see e.g. https://github.com/Infinisil/github-actions-docker/runs/1271863329:

 /usr/bin/docker exec  de645264c246e9831bfdda7ede83a62ed2d14583037ddb6b317acabd8fdfb1fa sh -c "cat /etc/*release | grep ^ID"
OCI runtime exec failed: exec failed: container_linux.go:370: starting container process caused: no such file or directory: unknown

This has already been reported in actions/checkout#334, but it doesn't really have anything to do with the checkout action (that's just the first action that tries to run the container).

Most likely it's some file missing in the image, but the error really doesn't help a lot to figure out which file.

A possible way to figure this out is to do a long-winded bisection with e.g. an alpine image, because that one works, and the image contents can be inspected with https://stackoverflow.com/a/53481010. So by incrementally copying files from that image to the docker-nixpkgs one, it should start working at some point.

Firstly; Thanks for your awesome work!

Currently offered tags include a good range of recent stable options; with 22.11 now being the most recent stable release could we add 22.11?

Would be great to be able to easily install packages in the docker image (works using nix shell, but that's awkward).

I think the best option would be to just add ~/.nix-profile/bin to the PATH, wouldn't it?

Allowing:

$ nix profile install nixpkgs#rsync
$ rsync --help

Right now, only x86_64-linux images are being pushed. For M1 users, aarch64 is nice.

Hello,

We're witnessing the following: test -x exe in today's :latest tag is incorrectly returning 1

$ export IMAGE=nixpkgs/nix@sha256:7d18385c919113f3495226e39f7b8b915743fc14edcd867a38107a9868c2e5f4 # :latest from today
$ docker run -it --rm $IMAGE sh -c 'touch exe; chmod +x exe; test -x exe && echo OK || echo KO'
KO
$ export IMAGE=nixpkgs/nix@sha256:8536a25f261194d033dd8124a72181393471aba0e1c2309aeb242fd38df59aa5 # Previous :latest (we believe)
$ docker run -it --rm $IMAGE sh -c 'touch exe; chmod +x exe; test -x exe && echo OK || echo KO'
OK
$ export IMAGE=nixpkgs/nix@sha256:b391ea0473d8dd3eb76b7ff69f012abab8915c2a48595c3d022cd5674e611834 # :nixos-20.09 from today
$ docker run -it --rm $IMAGE sh -c 'touch exe; chmod +x exe; test -x exe && echo OK || echo KO'
OK

This has manifested itself in our GitLab CI pipelines with the message shell not found, for their CI runner tests for common shell paths, and as test is returning false negatives, it fails to start the script.

I don't doubt the source of the issue is somewhere else, but I thought reporting it here could be helpful.

Thanks

would that be ok to add an iamge with a static nix ? nix build .#pkgsStatic.nix works fine here. Sadly, I am interested in nixUnstable which fails to build on unstable

Given that the only way to build docker images using a nix command needs to do docker load command, why was docker not built-in to nixos/nix? Or at least some image that has nixos/docker-nix

here is my example:

image:
	docker run --privileged \
		--mount type=bind,source=${PWD}/.github/workflows,target=/etc/nixos \
		--mount type=bind,source=/var/run/docker.sock,target=/var/run/docker.sock \
		-it nixos/nix nix-shell -p docker --run \
		"docker load --input \$$(nix-build /etc/nixos/image.nix)"
	# docker push

The new docker repo docker.nix-community.org is missing the nixos-23.05 tag:

$ docker pull docker.nix-community.org/nixpkgs/bash
Using default tag: latest
latest: Pulling from nixpkgs/bash

$ docker pull docker.nix-community.org/nixpkgs/bash:nixos-23.05
Error response from daemon: manifest for docker.nix-community.org/nixpkgs/bash:nixos-23.05 not found: manifest unknown: manifest unknown

Since yesterday pulls are failing with the following error:

❯ docker pull docker.nix-community.org/nixpkgs/nix-flakes
Using default tag: latest
Error response from daemon: Head "https://ghcr.io/v2/nixpkgs/nix-flakes/manifests/latest": unauthorized

If you run nix store verify --all all newly built paths will be untrusted.

This breaks Cachix and any other tools that require store paths to be present in sqlite db.

Why does the nixpkgs/nix-unstable Docker image not have nixos-rebuild or systemctl?

$ docker run --tty --interactive nixpkgs/nix-unstable
bash-5.2# nixos-rebuild
bash: nixos-rebuild: command not found
bash-5.2# systemctl
bash: systemctl: command not found
bash-5.2#

Even if that's expected for nixpks/nix-unstable, would you know why it's also the case for nixos/nix, which might be intended as a full NixOS install?

(I'm not sure what the difference between these images are, or what their intended for.)

I asked similarly on Stack Overflow:

• Why do some official Nix Docker containers not have the nixos-rebuild command?

Currently if the Docker container is started as a non-root user (eg nobody), Nix commands fail with permission errors. For example:

❯ docker run --rm -it --user nobody nixos/nix:2.16.1
bash-5.1$ nix --extra-experimental-features 'flakes nix-command' profile install nixpkgs#hello
error: could not set permissions on '/nix/var/nix/profiles/per-user' to 755: Operation not permitted

It would be nice if it were possible to use these commands as some non-root user (not necessarily "nobody") without further modifying the image.