gpu unlock error -16: the driver grabbed the card first

What gpu unlock error -16 looks like in the log

Three lines, in this order, and the third one is the one people quote.

NVRM: GPU 0000:01:00.0: RmInitAdapter failed!
NVRM: GPU 0000:01:00.0: rm_init_adapter failed, device minor number 0
nvidia: probe of 0000:01:00.0 failed with error -16

-16 is EBUSY. A gpu_unlock unlock failed -16 result means the module was present and lost the race for the device. The kernel is not saying the card is broken or unsupported; it is saying the device already has an owner. In practice that owner is nvidia, and the sequence above is the driver's own probe failing after the module lost the race. [issue #11]

The consequence is diagnostic. Whatever else is wrong with your setup, it did not get as far as the firmware stage. A card that answers -16 is electrically fine and perfectly visible to the system.

The gpu unlock race, in order

A cold boot gives three parties a chance at the GPU, and only the first one wins.

That is also why the failure is silent at install time. The package installs, the module builds, the firmware gets generated, and every step reports success. The mistake shows up on the next boot, as one line in the kernel log.

Three gpu unlock causes, in the order they turn up

• Causes in the order they show up, and what each one asks you to change.

• The module never entered the initramfs

  What you see

  It was built against the running kernel only

  Fix

  Put the drop-in in place, rebuild the image, cold boot

• The drop-in went to the wrong generator

  What you see

  No error at boot; lsinitramfs finds nothing

  Fix

  Write the file where your generator looks

• You loaded it by hand after boot

  What you see

  modprobe gpu_unlock seemed to work

  Fix

  Remove it from your shell session and load it earlier

The second row is the most common fresh-install version of the problem. An initramfs-tools file on a dracut machine does nothing, and it does nothing silently. That is the version of gpu_unlock unlock failed -16 that no cold boot will clear, because the file sits in the wrong directory rather than in the wrong order. Ubuntu 25.10 and 26.04 boot through dracut while the Debian package writes the initramfs-tools path. issue #54 documents it.

If dracut builds your image, follow the dracut initramfs installation guide rather than copying the initramfs-tools path.

The third row needs no rebuild. modprobe gpu_unlock at a shell prompt is too late by definition: the driver owns the device, and the module cannot take it back.

Fixing each gpu unlock error

For the first two, the fix has the same shape: put the drop-in where your generator looks, rebuild the image, cold boot. Neither fix helps a card that is not in the gpu unlock compatibility table: an unlisted card is skipped, not raced.

• Arch, CachyOS, EndeavourOS: /etc/mkinitcpio.conf.d/
• Debian, Ubuntu up to 25.04: /usr/share/initramfs-tools/modules.d/
• Fedora, RHEL, Ubuntu 25.10 and later: /usr/lib/dracut/dracut.conf.d/

Before rebuilding, check what is actually inside the image you are about to boot.

lsinitramfs /boot/initrd.img-$(uname -r) | grep gpu_unlock

No output means the module is not in the image and the ordering question is moot. Output means the module is there and losing the race anyway, which brings the third fix.

For a module that is present and still late, issue #171 uses an init-top script: a small hook that runs in the earliest userspace and loads gpu_unlock before udev begins probing the GPU. The ordering comes from where the script sits in the initramfs, not from modprobe options.

softdep nvidia pre: looks like the obvious answer and is not. kmod honours only the first softdep nvidia line in the tree, and on most desktops that line belongs to nvidia-utils.

On Ubuntu 24.04 specifically, there are two more ways to end up here:

• A hand-edited /etc/initramfs-tools/modules without the package's drop-in. initramfs-tools reads both that file and modules.d, so taking the ordering into your own hands means putting gpu_unlock ahead of nvidia in it yourself.
• A multi-kernel machine where the image was rebuilt for a kernel you are not booting. uname -r in your session has to match the image you actually rebuilt, or you fixed a file nobody reads.

Verifying that gpu unlock loaded this time

Two commands answer two different questions about gpu_unlock unlock failed -16: did the module run, and did the driver bind afterwards.

journalctl -k -b | grep gpu_unlock
lspci -nnk -s 0000:01:00.0

One caveat on reading logs: a card can be unlocked and still report a frozen SM clock in nvidia-smi, stuck around 210 MHz, while benchmarks run at full speed. That is a telemetry artefact, not a new gpu_unlock unlock failed -16 case.

It is also from issue #258. [issue #258]

If gpu unlock still returns -16