NVidia build dependency errors using 'nvidiaPackages.mkDriver'

Help
1

I’m trying to build the most recent NVidia drivers, while using NixOS stable (25.11) with kernel 6.18.8. But it fails like this:

error: Cannot build '/nix/store/zx4q8jrlw1ni2j4bjwcshkhdbf0da6ak-nvidia-open-6.18.8-590.48.01.drv'.
       Reason: builder failed with exit code 2.
       Output paths:
         /nix/store/nqj034a78nhs66r82wq39hc747090z9c-nvidia-open-6.18.8-590.48.01
       Last 18 log lines:
       > Running phase: unpackPhase
       > unpacking source archive /nix/store/wmypfkr7wlgj8w65kjv33k83mm4s8r8w-source
       > source root is source
       > Running phase: patchPhase
       > Running phase: updateAutotoolsGnuConfigScriptsPhase
       > Running phase: configurePhase
       > no configure script, doing nothing
       > Running phase: buildPhase
       > build flags: -j12 SHELL=/nix/store/j8645yndikbrvn292zgvyv64xrrmwdcb-bash-5.3p3/bin/bash CC=/nix/store/m1k4nxs8r0fl0pjxqp5n37vxgms7gdlb-gcc-14.3.0/bin/gcc LD=/nix/store/v9zpzmigqkcjrw1jpf0zjc49y47cm55s-binutils-2.44/bin/ld AR=/nix/store/myvv172x2am72534zgn9wx0qp5amq6a8-gcc-wrapper-14.3.0/bin/ar NM=/nix/store/myvv172x2am72534zgn9wx0qp5amq6a8-gcc-wrapper-14.3.0/bin/nm STRIP=/nix/store/v9zpzmigqkcjrw1jpf0zjc49y47cm55s-binutils-2.44/bin/strip OBJCOPY=/nix/store/myvv172x2am72534zgn9wx0qp5amq6a8-gcc-wrapper-14.3.0/bin/objcopy OBJDUMP=/nix/store/myvv172x2am72534zgn9wx0qp5amq6a8-gcc-wrapper-14.3.0/bin/objdump READELF=/nix/store/myvv172x2am72534zgn9wx0qp5amq6a8-gcc-wrapper-14.3.0/bin/readelf HOSTCC=/nix/store/myvv172x2am72534zgn9wx0qp5amq6a8-gcc-wrapper-14.3.0/bin/cc HOSTCXX=/nix/store/myvv172x2am72534zgn9wx0qp5amq6a8-gcc-wrapper-14.3.0/bin/c++ HOSTAR=/nix/store/4dh4138m8gbp56kh63j2pwgsfhf5l8v7-binutils-wrapper-2.44/bin/ar HOSTLD=/nix/store/4dh4138m8gbp56kh63j2pwgsfhf5l8v7-binutils-wrapper-2.44/bin/ld ARCH=x86_64 CROSS_COMPILE= KBUILD_OUTPUT=/nix/store/7zf8vhaizwvyj8226dpbdk48h4c0n7k2-linux-6.18.8-dev/lib/modules/6.18.8/build IGNORE_PREEMPT_RT_PRESENCE=1 SYSSRC=/nix/store/7zf8vhaizwvyj8226dpbdk48h4c0n7k2-linux-6.18.8-dev/lib/modules/6.18.8/source SYSOUT=/nix/store/7zf8vhaizwvyj8226dpbdk48h4c0n7k2-linux-6.18.8-dev/lib/modules/6.18.8/build MODLIB=\$\(out\)/lib/modules/6.18.8 DATE= TARGET_ARCH=x86_64
       > make[1]: Entering directory '/build/source/src'
       > /nix/store/j8645yndikbrvn292zgvyv64xrrmwdcb-bash-5.3p3/bin/bash: line 1: pkg-config: command not found
       > /nix/store/j8645yndikbrvn292zgvyv64xrrmwdcb-bash-5.3p3/bin/bash: line 1: pkg-config: command not found
       > /nix/store/j8645yndikbrvn292zgvyv64xrrmwdcb-bash-5.3p3/bin/bash: line 1: pkg-config: command not found
       > /nix/store/j8645yndikbrvn292zgvyv64xrrmwdcb-bash-5.3p3/bin/bash: line 1: pkg-config: command not found
       > /nix/store/j8645yndikbrvn292zgvyv64xrrmwdcb-bash-5.3p3/bin/bash: line 1: pkg-config: command not found
       > Makefile:362: *** Neither GTK2 nor GTK3 build dependencies found; please check `pkg-config --exists gtk+-3.0`.  Stop.
       > make[1]: Leaving directory '/build/source/src'
       > make: *** [Makefile:23: all] Error 2
       For full logs, run:
         nix log /nix/store/zx4q8jrlw1ni2j4bjwcshkhdbf0da6ak-nvidia-open-6.18.8-590.48.01.drv
error: Cannot build '/nix/store/a5gm7pcrb858wgnknpca5668wrfjpigv-linux-6.18.8-modules.drv'.
       Reason: 1 dependency failed.
       Output paths:
         /nix/store/51szfi014g4z1l40pr4asrxca36wpfjk-linux-6.18.8-modules
error: Cannot build '/nix/store/qacvric1vbs28b998rm4a3z3plpbrxcs-nixos-system-homer-25.11.20260202.d04d854.drv'.
       Reason: 1 dependency failed.
       Output paths:
         /nix/store/yfgd43w49f780593np1wkjrkibjqbfxn-nixos-system-homer-25.11.20260202.d04d854

This is my related config (used the NixOS Wiki example as a template):

{  
  hardware.graphics = {
    enable = true;
  };
  
  services.xserver.videoDrivers = [ "nvidia" ];

  hardware.nvidia = {
    
    modesetting.enable = true;

    open = true;

    nvidiaSettings = false;
    
    # package = config.boot.kernelPackages.nvidiaPackages.latest;
    # package = config.boot.kernelPackages.nvidiaPackages.beta;

    package = config.boot.kernelPackages.nvidiaPackages.mkDriver {
      version = "590.48.01";
      sha256_64bit = "sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=";
      sha256_aarch64 = "sha256-BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB=";
      openSha256 = "sha256-NWsqUciPa4f1ZX6f0By3yScz3pqKJV1ei9GvOF8qIEE=";
      settingsSha256 = "sha256-CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC=";
      persistencedSha256 = "sha256-DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD=";

      useSettings = false;
    };
  };
}

I thought that the GTK dependencies may be related to building nvidia-settings, so I tried to disable it. But I still get those dependency errors. Where are they coming from? And why is the mkDriver function not adding all build dependencies? I’m very confused…

2

Yeah, that’s very weird. It’s possible your hash is wrong, and happens to point at a source that does depend on gtk; nix will not doubt your assertion of the source hash if it can find one that looks like it.

I.e., you might accidentally be using the nvidia-settings hash for the module.

I’d recommend deleting all unnecessary hashes, replacing the ones you do need with lib.fakeHash, and to use --keep-going.

In practice you only need to fill in the hashes for sha256_64bit (assuming you’re on x86) and openSha256, since you probably also want to disable persistenced.

Like so: dotfiles/nixos-config/default.nix at 3b85db956f7deea7fff35efc950cc6e8dc672680 · TLATER/dotfiles · GitHub

1 Like
3

Hey, thanks for your response @TLATER !

I’ve tried using lib.fakeSha256 but it always results in this error:

error: hash ‘0000000000000000000000000000000000000000000000000000000000000000’ does not include a type, nor is the type otherwise known from context

But lib.fakeHash avoids that! Which is weird, because I would expect that a function called fakeSha256 would contain a sha256- prefix…

It’s possible your hash is wrong, and happens to point at a source that does depend on gtk; nix will not doubt your assertion of the source hash if it can find one that looks like it.

Does that mean that it chooses the package to download by the hash? I thought the hash is only used to verify the archive integrity, after it has been downloaded.

Anyway, I followed your advice and it worked! Well, the build was successful. But it fails to install the kernel because my 512 MB /boot partition is full:

updating GRUB 2 menu...
cannot copy /nix/store/rq0mfihrvsq9w6d4gyv5iadqq8n2fa6r-initrd-linux-6.18.8/initrd to /boot/kernels/rq0mfihrvsq9w6d4gyv5iadqq8n2fa6r-initrd-linux-6.18.8-initrd.tmp: No space left on device
Failed to install bootloader

It currently contains 2 kernels:

ll /boot/kernels/
.rwx------ 162M root  2 Feb 08:24 9mcpk5ar7rpa9v91kiv7hsdp0rawvhji-initrd-linux-6.18.6-initrd
.rwx------  14M root 20 Jan 15:49 358l6zj8jj3ar78pishd2ij16rxkqzaw-linux-6.18.6-bzImage
.rwx------ 162M root  3 Feb 22:10 426v76d3g3h236g1yiscbp8ai5r82fk0-initrd-linux-6.18.8-initrd
.rwx------  14M root  3 Feb 22:10 f1dvby8g535cmlr6mavvc9fg1jldxw6j-linux-6.18.8-bzImage
.rwx------  62M root 20 Jan 15:49 kscz1kj97gij00ag7r69g9hf9cdvsgfb-initrd-linux-6.18.6-initrd
.rwx------  83M root  4 Feb 20:50 rq0mfihrvsq9w6d4gyv5iadqq8n2fa6r-initrd-linux-6.18.8-initrd.tmp

I’m using BTRFS for Nixos, btw. On my old Ubuntu installation (based on ext4), the kernels were located on the / partition and /boot was just a folder, so never ran into this issue. For NixOS, I followed the setup instructions (from the wiki, afair) and ended up with this.

I can create a new thread for the new issue, but maybe you have a good solution for this issue?

4

lib.fakeSha256 is part of a family of functions for the legacy hash definitions. fetch* have a sha256 argument which expects a raw sha256 string.

The hash arguments (which pretty much everything uses now) require a hash that has a prefix instead of specifying the hash type as thr argument name, so you can use whatever hash is appropriate without changing the arg name.

This is indeed a bit counterintuitive, but basically just remember that lib.fakeSha256 (and its 512 sister) is the old, effectively deprecated one.

No, but if you tell it the source has a certain hash, and a source with that hash exists, there’s no way for nix to know that you’re telling it to use the wrong source code. It only has a hash to go by.

The sources are cached after the first download, and they aren’t indexed by URL, so it’s on you not to feed nix the wrong hash.

This too, is counterintuitive. It means that you can e.g. update the version string in mkDriver, rebuild, and get a fully functional driver with a different version than what you wrote.

That’s not possible, on a UEFI system /boot must be a separate partition. You probably just didn’t notice. On ubuntu you’re less likely to run into this issue because ubuntu doesn’t keep multiple kernels around for rollback purposes.

If you look at the kernel sizes, you’re well under 512MB; there must be something else gunking up your /boot. Nah, I underestimated the initrd sizes. Make sure to set your configurationLimit to, like, 5, your /boot is on the small side for a NixOS config (which isn’t a problem, you just need to set a lower limit to prevent running out of disk space).

100+MB for a kernel is also excessively large, you must have enabled something weird in your configuration. Share the full contents of your configuration.nix.

Refer to the official docs, not the wikis: NixOS Manual

The wikis are pretty unreliable, unfortunately, and I don’t see a post-LLM world in which this will improve. Though to be fair, this time the wiki is likely not at fault.

1 Like
5

Like nvidia or AMD GPU drivers, both propel the kernel and/or the initrd beyond the 100 MiB mark.

6

I still have the installation on the old disk, so I checked: /boot is a partition on the root filesystem and the 512 MB EFI partition is mounted to /boot/efi. Kernels are located directly in /boot, so they don’t use any space on the EFI partition.

Actually it does. It keeps old kernels and creates GRUB boot entries for each of them. I even wrote a script long time ago to clean them up and free space on the root partition.

100+MB for a kernel is also excessively large, you must have enabled something weird in your configuration. Share the full contents of your configuration.nix.

Yeah, I also noticed that. I don’t keep my config in a public repo, but this is the content of my boot.nix:

{
pkgs,
…
}:

{

boot = {
loader = {
systemd-boot.enable = false;

  efi.canTouchEfiVariables = true;

  grub = {
    enable = true;
    efiSupport = true;
    device = "nodev";    
    useOSProber = true;
  };
};

plymouth = {
  enable = true;
  theme = "cybernetic";
  themePackages = with pkgs; [    
    (adi1090x-plymouth-themes.override {
      selected_themes = [
        "abstract_ring_alt"
        "cybernetic"
        "pixels"
        "tech_b"
      ];
    })
  ];
};

# Enable early kernel mode setting (KMS)
initrd.kernelModules = [
  "nvidia"
  "nvidia_modeset"
  "nvidia_uvm"
  "nvidia_drm"
];

# Enable "Silent Boot"
consoleLogLevel = 0;
initrd.verbose = false;
kernelParams = [
  "quiet"
  "splash"
  "boot.shell_on_fail"
  "loglevel=3"
  "rd.systemd.show_status=false"
  "rd.udev.log_level=3"
  "udev.log_priority=3"
];

kernelPackages = pkgs.linuxPackages_latest;

};
}

Like nvidia or AMD GPU drivers, both propel the kernel and/or the initrd beyond the 100 MiB mark.

I’ve also checked the kernel sizes in Ubuntu. The initrd files are between 70 and 90 MiB (with NVIDIA drivers, same PC). The corresponding NixOS files are more than twice as big.

7

They don’t:

~> sudo ls -lh /boot/EFI/nixos
[sudo: authenticate] Password:
total 46M
-rwx------ 1 root root 13M Feb  3 04:13 b17bxf2yamwgkavsp55ixb4cdyfw2p0v-linux-xanmod-6.18.7-bzImage.efi
-rwx------ 1 root root 33M Feb  3 04:13 f60jfrajk6hz7hhyf2c9bh21d8l6jihp-initrd-linux-xanmod-6.18.7-initrd.efi
8

That kind of setup is not possible with self-bootstrapping kernels. It also makes disk encryption impossible. You must have been running an ancient (15+ years?) ubuntu setup, I don’t think their installer does that anymore.

Packing your initrd full of plymouth themes probably doesn’t help, but that would balloon the initrd size, not the kernel size.

These are set by the hardware.nvidia module, and some of them should be dynamically loaded instead of always enabled. You’re breaking the nvidia module behavior by separately declaring them.

Grub is also generally disrecommended in NixOS land, unless you have very bespoke requirements.

… but that’s all besides the point, and won’t affect your kernel size.

The problem likely lives in another module, my suspicion would be something like hardware.enableAllHardware that would enable a ton of kernel modules you don’t actually need. Various other NixOS modules might also enable kernel modules. Hard to help look for such things without seeing more of your configuration, but in either case, your kernel is way too big.

9

It’s only a few years old (max. 3). This how Ubuntu /boot looks like (viewed from a running NixOS):

.rw-r--r-- 287k root  5 Jul  2024 config-6.8.0-40-generic
.rw-r--r-- 297k root 11 Okt  2025 config-6.14.0-36-generic
.rw-r--r-- 297k root 14 Nov  2025 config-6.14.0-37-generic
drwxrwxr-x    - root  8 Okt  2021 efi
drwxr-xr-x    - root 18 Jan 09:20 grub
lrwxrwxrwx    - root 12 Dez  2025 initrd.img -> initrd.img-6.14.0-37-generic
.rw-r--r--  71M root 19 Mai  2025 initrd.img-6.8.0-40-generic
.rw-r--r--  85M root 24 Nov  2025 initrd.img-6.14.0-36-generic
.rw-r--r--  86M root 16 Jan 15:50 initrd.img-6.14.0-37-generic
lrwxrwxrwx    - root 12 Dez  2025 initrd.img.old -> initrd.img-6.14.0-36-generic
.rw-r--r-- 151k root 17 Nov  2024 memtest86+ia32.bin
.rw-r--r-- 152k root 17 Nov  2024 memtest86+ia32.efi
.rw-r--r-- 156k root 17 Nov  2024 memtest86+x64.bin
.rw-r--r-- 157k root 17 Nov  2024 memtest86+x64.efi
.rw------- 9,1M root  5 Jul  2024 System.map-6.8.0-40-generic
.rw-------  10M root 11 Okt  2025 System.map-6.14.0-36-generic
.rw-------  10M root 14 Nov  2025 System.map-6.14.0-37-generic
lrwxrwxrwx    - root 12 Dez  2025 vmlinuz -> vmlinuz-6.14.0-37-generic
.rw-------  15M root  5 Jul  2024 vmlinuz-6.8.0-40-generic
.rw-------  16M root 11 Okt  2025 vmlinuz-6.14.0-36-generic
.rw-------  16M root 14 Nov  2025 vmlinuz-6.14.0-37-generic
lrwxrwxrwx    - root 12 Dez  2025 vmlinuz.old -> vmlinuz-6.14.0-36-generic

As you can see, there are multiple initrd and vmlinuz files. And the /efi folder is empty, because it’s not mounted. The initrd files are also a lot smaller then the ones from NixOS:

➜ ll /boot/kernels/
.rwx------ 162M root  2 Feb 08:24 9mcpk5ar7rpa9v91kiv7hsdp0rawvhji-initrd-linux-6.18.6-initrd
.rwx------  14M root 20 Jan 15:49 358l6zj8jj3ar78pishd2ij16rxkqzaw-linux-6.18.6-bzImage
.rwx------ 162M root  3 Feb 22:10 426v76d3g3h236g1yiscbp8ai5r82fk0-initrd-linux-6.18.8-initrd
.rwx------  14M root  3 Feb 22:10 f1dvby8g535cmlr6mavvc9fg1jldxw6j-linux-6.18.8-bzImage
.rwx------  62M root 20 Jan 15:49 kscz1kj97gij00ag7r69g9hf9cdvsgfb-initrd-linux-6.18.6-initrd
.rwx------  83M root  4 Feb 20:50 rq0mfihrvsq9w6d4gyv5iadqq8n2fa6r-initrd-linux-6.18.8-initrd.tmp
root ~

EDIT: I’ve checked my work laptop, which runs the latest Fedora. It uses the same setup as Ubuntu (but xfs instead of ext4). And with disk encryption.

I can’t believe that 4 plymouth themes take up over 100MB. But anyway, all I want do is relocate the initrd files to the root partition, as other distros do, so size doesn’t matter. Is that really not possible with NixOS?

Grub is also generally disrecommended in NixOS land, unless you have very bespoke requirements.

Why? It served me well for over 20 years and it can do everything systemd-boot can, afaik. Maybe even more.

These are set by the hardware.nvidia module, and some of them should be dynamically loaded instead of always enabled. You’re breaking the nvidia module behavior by separately declaring them.

That sounds really interesting. But I don’t understand what you mean. This is the recommended way to enable early KMS for NVIDIA, as described in the Arch Wiki (and referenced in the NixOS Wiki). How else should I do that?

10

I don’t have anything like that in my config. The only other place that touches the kernel config is the auto-generated hardware-configuration.nix:

# Do not modify this file!  It was generated by ‘nixos-generate-config’
# and may be overwritten by future invocations.  Please make changes
# to /etc/nixos/configuration.nix instead.
{ config, lib, pkgs, modulesPath, ... }:

{
  imports =
    [ (modulesPath + "/installer/scan/not-detected.nix")
    ];

  boot.initrd.availableKernelModules = [ "xhci_pci" "ahci" "nvme" "usbhid" "usb_storage" "sd_mod" ];
  boot.initrd.kernelModules = [ ];
  boot.kernelModules = [ "kvm-intel" ];
  boot.extraModulePackages = [ ];

  nixpkgs.hostPlatform = lib.mkDefault "x86_64-linux";
  hardware.cpu.intel.updateMicrocode = lib.mkDefault config.hardware.enableRedistributableFirmware;
}
11

Yeah, I doubt it. I don’t think plymouth is causing this by itself, but it’s worth testing. Maybe one of the themes includes some incredibly high-res images.

Sadly the initrd is hidden in a let binding, so I can’t too easily give you a one-liner to build just the initrd for testing purposes. Maybe when I am at a computer.

You can also consider not setting config.hardware.enableRedistributableFirmware and instead setting only the subset of firmware you need with hardware.firmware; that would probably be a good chunk of data, too. These are the default packages, for the record: nixpkgs/nixos/modules/hardware/all-firmware.nix at e576e3c9cf9bad747afcddd9e34f51d18c855b4e · NixOS/nixpkgs · GitHub

Other than that, I’d look through boot.initrd.kernelModules - you can get the list with nixos-option boot.initrd.kernelModules (assuming no flakes, use the --flake option if you use flakes).

As for the less immediately related stuff:

My bad! I missed the initrd.

I’d suggest trying if you actually need early modesetting. Most of the reasons you might have wanted this in the past don’t really apply since nvidia driver version ~540.

Modesetting by the nvidia driver is enabled by default now on NixOS, and covers most of what you might want (e.g. wayland, plymouth). Not having the nvidia driver in the initrd will probably help cut down that size.

Yeah, the problem is precisely that it can do a lot of stuff, 99% of which you never use, all packed into a 30 year old codebase.

It’ll work, but there are more bugs, security issues and misfeatures than with the newer systemd-boot. Like, you’re on an EFI system, you need none of the code for booting MBR stuff. The kernel itself implemented a bunch of grub’s features 15 years ago, but grub keeps them around for backwards compat that you will never care about with your current system.

Especially the folks who dug deeply into the NixOS bootspec are quite vocal about not using grub, unless you know you need one of its more unique features (i.e., basically just MBR boot on legacy systems for normal mortals).

I think there is some misinterpretation here, as this should be fundamentally impossible. Without a kernel to decrypt your disk, you cannot load a kernel from your root partition to boot. It’s encrypted. The data is unavailable before you’ve booted a kernel far enough to decrypt.

Grub can theoretically decrypt disks, to be fair, but this feature isn’t used by any serious distro since it’s known to be quite insecure.

Perhaps these other distros have a two-stage boot where they store multiple kernels in different places or something… But it’s anyway irrelevant what other distros do in this context, so let’s end the sleuthing there.

I mean, anything is possible, but the current setup has no provisioning for this. I think adding this feature would involve pretty big changes to the boot process.

Depending on what you’re doing, downstream you might be able to get away with something simpler, of course, but there’s no readily available documentation for this, you’ll have to dig into the nixpkgs source and write your own implementation.

That said though, your immediate problem really shouldn’t take that level of engineering. kernel + initrd should not be more than ~50MB IME, even with the nvidia module. You should be able to fit plenty of generations even in a small partition.

I think we should focus on cutting this initrd size down to something reasonable. It’s almost an order of magnitude larger than mine, and our setups are not that different.

1 Like
12

OK, I think I found the reason for the huge initrd files. This is the result if I build without adding the NVidia modules:

ll /boot/kernels/
.rwx------ 14M root  3 Feb 22:10 f1dvby8g535cmlr6mavvc9fg1jldxw6j-linux-6.18.8-bzImage
.rwx------ 62M root  5 Feb 16:33 fgmyx5l0cshsv3pxnc61lwi3ga0qsk7w-initrd-linux-6.18.8-initrd

And this is the result if I enable the “Early Kernel Mode Setting” code from above:

ll /boot/kernels/
.rwx------ 162M root  5 Feb 16:40 426v76d3g3h236g1yiscbp8ai5r82fk0-initrd-linux-6.18.8-initrd
.rwx------  14M root  3 Feb 22:10 f1dvby8g535cmlr6mavvc9fg1jldxw6j-linux-6.18.8-bzImage
.rwx------  62M root  5 Feb 16:33 fgmyx5l0cshsv3pxnc61lwi3ga0qsk7w-initrd-linux-6.18.8-initrd

100 MB for 4 kernel modules… wow.

Btw, the reason I’ve added Early KMS is Plymouth. It works without, but has a very low resolution. I didn’t think about initrd sizes at that point, because I’m simply not used to that being an issue.

Perhaps these other distros have a two-stage boot where they store multiple kernels in different places or something.

That’s also what I thought. Maybe I’ll take a closer look later, because I’m still curious.

Anyway, what would happen if I mount my EFI partition to /boot/efi (or just /efi), and set

boot.loader.efi.efiSysMountPoint = "/boot/efi"; # (or "/efi")

Would that work on Nixos or would it break booting? Or would it do nothing and all initrds would simply be written to /boot/efi, eventually ending up in the exact same situation?

13

I mean, you can give it a shot. Worst case you brick your bootloader, but recovering from that isn’t hard (unless perhaps if you’re using disk encryption).

Right, grub/systemd-boot can also set the mode. If it’s just for resolution, that seems more appropriate to me.

14

Thanks a lot for your help @TLATER! I have one last question, regarding the docs:

I’ve tried to find documentation about the mkDriver function, but wasn’t successful. I tried noogle.de, search.nixos.org and Github. All I found was the nvidia-x11 package, but I wouldn’t call that code “well documented” (e.g. I still don’t know what persistenced means). Is there some better documentation?

15

The best docs for nvidia are their own README: NVIDIA Accelerated Linux Graphics Driver README and Installation Guide

Note that’s for a specific driver version, the link will become outdated after a while.

There you can find what all the features do, including what persistenced is (a way to keep nvidia GPUs in servers “warm” at all times).

If it’s not obvious what an option does, I read the code and compare to the upstream docs. Many of the NixOS nvidia options are subtly broken, or at least variously inadvisable or misleading, so it’s worth reading a bit into what the options are ultimately supposed to effect (and double check they actually do that).

As for mkDriver, yeah, it’s only documented as far as it needs to be. It won’t explain what the various args do, the names just match specific features which you have to independently understand.