Install gpu unlock on Ubuntu so the module loads first

Three gpu unlock checks before you start

• Cards

  Is the card in the whitelist?

  It is a list of PCI device IDs, not model names. Check yours before you build anything.

• -110

  Can you physically cut power?

  A failed attempt can leave the card unresponsive until the machine loses power entirely. Rebooting is not enough — that is the -110 case.

• Signing

  What about Secure Boot?

  An unsigned module taints the kernel, and a machine enforcing signatures will refuse it. Signing it yourself with a MOK works.

A Fedora 43 machine with Secure Boot on is reported working through MOK signing in issue #173. Turning Secure Boot off is the other route, and it is a different decision, worth making deliberately. [official README]

The whole gpu unlock install, in four moves

Four gpu unlock install paths

The project ships packaging for the three big families plus Unraid, and a dispatcher that reads /etc/os-release for you.

# reads ID / ID_LIKE and picks the right installer
make install

# or name it
make install-arch   # makepkg
make install-deb    # dpkg-buildpackage + apt
make install-rpm    # rpmbuild + dnf

# build without installing
make arch / make deb / make rpm

• Unraid is the exception: it has no make path, and the only thing published under Releases is an Unraid plugin package.
• AUR is not in the list either. The package is still an open pull request #223.

Whichever path you take, the build is what produces the firmware:

• Inputs come from NVIDIA and CachyOS and land in ~/.cache/gpu-unlock/inputs.
• They are compiled into the module directory and the package.
• make inputs refreshes them; INPUTS= points the build somewhere else.
• A source package does not carry the firmware, which matters later when you wonder why a copied blob does nothing.

How the initramfs generator changes gpu unlock

Four targets, four drop-in locations, and one of them is not where you expect.

• Drop-in paths as listed by the project. A file written for one generator does nothing on another.

• mkinitcpio

  Drop-in file

  /etc/mkinitcpio.conf.d/zz-gpu-unlock.conf

  Typical distros

  Arch, CachyOS, EndeavourOS

• initramfs-tools

  Drop-in file

  /usr/share/initramfs-tools/modules.d/gpu-unlock.conf

  Typical distros

  Debian, Ubuntu up to 25.04

• dracut

  Drop-in file

  /usr/lib/dracut/dracut.conf.d/gpu-unlock.conf

  Typical distros

  Fedora, RHEL, openSUSE, Ubuntu 25.10 and 26.04

• UKI / generated entries

  Drop-in file

  /etc/kernel/cmdline, then rebuild

  Typical distros

  any install that boots a unified kernel image

The trap sits in the third row, and it is the most common way a gpu-unlock Ubuntu install fails without saying so. The Debian package writes an initramfs-tools drop-in only, so on Ubuntu 25.10 or 26.04, where the boot goes through dracut, the module never makes it into the image.

You will not see an error at install time. You will see a log with no gpu_unlock lines at all, which is the tell. issue #54 has the manual drop-in, which is one install command.

Install under dracut

One more generator detail that bites people on Arch: mkinitcpio -c <config> and preset files with _config ignore drop-ins entirely. If your preset does that, the module will not be included no matter what you put in zz-gpu-unlock.conf.

The kernel parameter that opts gpu unlock in

A gpu-unlock Ubuntu install does nothing until you name the cards you want handled. That is deliberate: the module is installed on machines where it must do nothing by default.

gpu_unlock.targets=all                          # every supported, unbound card
gpu_unlock.targets=0000:21:00.0                 # one card
gpu_unlock.targets=0000:21:00.0,0000:22:00.0    # two cards

• The addresses are full lspci -D names, unrelated to GPU numbering or to which card is driving your display.
• Entries that are not in the whitelist get logged and skipped, including when you mix all with explicit addresses.
• The replay after a suspend and resume is on by default. gpu_unlock.resume=0, or writing 0 to /sys/module/gpu_unlock/parameters/resume, turns it off, for machines where the replay is what fails.

How you write the parameter depends on the bootloader, and the difference matters more than it looks: a parameter added to a running session does nothing for the next boot.

# Debian / Ubuntu / Mint  ->  /etc/default/grub, then update-grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash gpu_unlock.targets=all"

# Arch / CachyOS
sudo grub-mkconfig -o /boot/grub/grub.cfg

# Fedora / RHEL
sudo grubby --update-kernel=ALL --args="gpu_unlock.targets=all"

# systemd-boot: edit the options line (bootctl status shows the path)
# UKI: write /etc/kernel/cmdline, then rebuild

Verify gpu unlock before you trust it

Verify a gpu-unlock Ubuntu install with two checks, in order: is the module inside the image, and did it actually run.

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

Roll back gpu unlock in three steps

The exception is a machine where a failed run left the firmware unsettled. In that case the module keeps its DMA buffer until the next power cycle, so shut down, unplug, and start again rather than restarting into the same state.

Rebuild gpu unlock after a kernel update

Any kernel or initramfs change on a gpu-unlock Ubuntu machine needs a rebuild, or the module disappears along with the kernel it was built for.

• On initramfs-tools and dracut, a hook handles new kernels once the package is installed.
• On mkinitcpio it depends on the preset, and the _config case above applies again.

The symptom is not an error message. The card simply stays locked, and the only trace is the missing gpu_unlock: unlocked line in the boot log.

Version, commit and the date of this check are on every page of this site. [official README] carries the current instructions; the paths above were checked against them.

Next: if the module is in the image and the log still shows no gpu_unlock line, that is the -16 page. If the log shows -2 instead, the firmware never made it in.