Change:
virtualisation.docker.daemon.settings = lib.mkIf (config.hardware.nvidia-container-toolkit.enable && (lib.versionAtLeast config.virtualisation.docker.package.version "25")) { <del> features.cdi = true; }; </del> <ins> features.cdi = true; }; </ins> hardware.nvidia-container-toolkit.mounts = let nvidia-driver = config.hardware.nvidia.package; in (lib.mkMerge [ [{ hostPath = pkgs.addDriverRunpath.driverLink; containerPath = pkgs.addDriverRunpath.driverLink; } <ins> { hostPath = "${lib.getLib nvidia-driver}/etc"; containerPath = "${lib.getLib nvidia-driver}/etc"; } { hostPath = "${lib.getLib nvidia-driver}/share"; containerPath = "${lib.getLib nvidia-driver}/share"; } </ins> { hostPath = "${lib.getLib pkgs.glibc}/lib"; containerPath = "${lib.getLib pkgs.glibc}/lib"; } { hostPath = "${lib.getLib pkgs.glibc}/lib64";

Discussion:
Steps to reproduce the behavior: Enable CDI and podman: Run any program doing off-screen rendering in a container, cf. (vtk-egl defined in ): Verify the issue is eliminated by mounting the glvnd configs: See what gets mounted into the container: Note how the paths from are present, but are omitted. This is likely because hard-codes the FHS paths. Glvnd configs are part of the host configuration and should be mounted into the containers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --CC CC it's the same issue with Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I'll submit a patch to nvidia that should fix this. It seems like the nvidia tooling should be using XDGDATADIRS instead of hardcoding /usr/share. On the nixos side though, we should be adding to XDGDATADIRS.
This is the CDI output I get when using XDGDATADIRS that includes /run/openl-driver/share: does this include everything you expect?
For my current use-case I think this is the thing, so yes. Of course we still need to ensure that the closure is included in the container, including the symlink targets I'm pretty sure we do do that for libglvnd somehow, but I'd need to search for the concrete rreferences
Thanks I assume this works with the change you plan to submit to nvidia-container-toolkit, right? Wouldn't this be a matter of setting on the unit that calls the CDI generator?
We need to somehow synchronize at least the following: [ ] CDI generators, [ ] , [ ] , [ ] In the worst case we track them manually as we clarify and implement EDIT: CC
Sorry, what exactly is there to synchronise? They all appear to use some subdir of .
Hi! I tagged you because a potential implication of is that the location of these configs might change in the future, and the current issue is about making detect those correctly =how ever we solve this for has to account for the potential move later
Yes! PR is here:
Awesome!
what kind of container are you running?

I'm worried that in the case where the container is built using nix, everything works when we mount the paths under since the software running in the container is already configured to look for stuff in . But perhaps in the case where the host is nixos and the container is something else (like ubuntu), that software may end up looking in and will not find what has been shared from the host. It seems that from the host would need to be shared with the container.
Yes, there are two layers to the issue: , EGL is "broken" even in containers based on images produced by nixpkgs' : I think it's because the current implementation of fails to mount the full closure into the container (including the store path with the jsons); already tracking in there's supporting the FHS images, for which we need to remap parts of to the locations expected by FHS distributions. Your PR hopefully addresses this