When dracut builds the initramfs, gpu unlock is absent

Why gpu unlock has to be inside the dracut initramfs

Ordering is the product. gpu_unlock does one thing at boot: it writes the speed selectors before the NVIDIA driver can bind the card. Once nvidia owns the device, the same write comes back busy and the log prints -16. Every install decision here is about reaching the card first. The package, the drop-in and the kernel parameter are all machinery for that one window.

That earlier stage is the initramfs. The module and the firmware it replays travel with the image instead of waiting in /lib/modules for the root filesystem to mount. On a normal desktop the difference between the two locations is the difference between working and returning EBUSY, which is why the install overview treats the generator as the main decision rather than a packaging detail.

The project deliberately does not win this race with softdep nvidia pre:. kmod honours only the first softdep nvidia line it reads, and on an ordinary desktop that line belongs to nvidia-utils or gddr6_hwmon; whichever package writes second is ignored. The ordering is handed to the initramfs generator instead. [official README]

Two facts about the boot stage are worth carrying into everything below. The module unlocks its cards concurrently, about a second in total however many there are, and each card is handled on its own: one that is already bound or powered down is skipped with a log line. If a laptop booted with its discrete GPU switched off, the unlock has nothing to talk to. [official README]

Which machines need gpu unlock through dracut

Three generators are easy to place. mkinitcpio belongs to Arch and its derivatives, initramfs-tools covers Debian and Ubuntu up to 25.04, and dracut covers Fedora, RHEL and its rebuilds, openSUSE, and Ubuntu from 25.10 onward. [official README]

The Ubuntu line is where people get caught, because the distribution name stopped answering the question. 24.04 LTS and 25.04 build with initramfs-tools. 25.10 and 26.04 build with dracut. A guide written for 24.04 hands you a drop-in path that exists on disk and is never read by anything.

So check the image rather than the package list: a gpu-unlock dracut initramfs either carries the module or it does not, and the package list will not tell you which. Both toolchains ship a lister (lsinitrd for dracut, lsinitramfs for initramfs-tools), and either one prints what the kernel will actually unpack at boot. If your image was built by dracut, the drop-in has to be where dracut looks, whatever your /etc/os-release claims.

• Two generators, two directories. A file in the wrong one is inert.

• dracut

  Drop-in file

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

  Where it comes from

  Fedora and RHEL packaging; hand-installed on Ubuntu 25.10+ (issue #54)

• initramfs-tools

  Drop-in file

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

  Where it comes from

  Debian and Ubuntu up to 25.04 packaging

The directory matters more than the file name. dracut reads dracut.conf.d while it builds an image; a file dropped anywhere else is just text on a disk that no generator opens.

With dracut and initramfs-tools, the project builds the module for every installed kernel that has headers, and rebuilds those images on install and again on removal. A kernel installed later gets the module and a new image from the kernel's own install hooks. [official README]

That behaviour is worth relying on: doing it by hand after every kernel update is the kind of chore that ends with a locked card and a stale image.

The package that omits the dracut setup for gpu unlock

The Debian package is the exception, and it is the reason this page exists. It writes the initramfs-tools drop-in only. On Ubuntu 25.10 or 26.04, where the boot goes through dracut, make install-deb succeeds, the module gets built, and the image never receives it. The gpu-unlock dracut initramfs on those machines has to be built by hand.

issue #54 reports this on a dracut-booting Ubuntu and carries the manual drop-in as a workaround. It is still open at the time of this check, so treat the missing drop-in as the current behaviour of the package rather than a one-off. [issue #54]

Verify gpu unlock in the image before you reboot

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

journalctl -k -b | grep gpu_unlock

The first two lines are alternatives, not a sequence: run the lister your system has, against the image your bootloader really loads (ls /boot settles which file that is). What you are looking for is gpu_unlock.ko inside the image and the firmware it needs beside it. A gpu-unlock dracut initramfs that passes this check carries both; one that fails it says nothing at boot, which is the whole problem.

Fixing gpu unlock in a dracut image by hand

Two moves. First install the drop-in that issue #54 carries into the directory dracut reads; then rebuild the image for the kernel you actually boot and check it with the lister. Those two moves are the whole gpu-unlock dracut initramfs repair.

# Run from the gpu-unlock source checkout
sudo install -Dm644 packaging/boot/dracut.conf /usr/lib/dracut/dracut.conf.d/gpu-unlock.conf

# Build for the running kernel into the distribution default image path
sudo dracut --force --kver "$(uname -r)"

# Read the image your bootloader will actually use
lsinitrd "/boot/initramfs-$(uname -r).img" | grep -E 'gpu_unlock\.ko|firmware' || lsinitramfs "/boot/initrd.img-$(uname -r)" | grep -E 'gpu_unlock\.ko|firmware'

The rebuild is the step people skip after editing configuration. An image built this morning does not know about a file you wrote this afternoon, and a reboot alone repacks nothing. On a multi-kernel machine, confirm that the image named by your boot entry belongs to the running uname -r; rebuilding a different kernel leaves the problem untouched.

Once the drop-in sits in dracut.conf.d, later kernels are handled by dracut's own hooks and you do not repeat this. The same file is what the Fedora and RHEL packages install, so on those distributions the first move of this section is already done for you and only the rebuild remains.

If the module is built but the image still lacks it, check the kernel you actually booted for headers. A kernel without headers gets no module built, and therefore nothing for the generator to copy. [official README]

What gpu unlock problems are not dracut's fault

Two failures look like a dracut problem and are not, and both are worth separating before you touch the image again.

The first is -16. The module is in the image, it ran, and nvidia had already claimed the card. The fix is the ordering inside the image, which is the -16 page.

The second is -2. The module loaded and could not find its firmware, which means the build and the image disagree about the payload. The firmware page covers what to look for.

One rule separates all three cases: if the lister shows the module, this page is finished and the kernel log is the next thing to read. If it does not, nothing downstream of the image matters yet, and no amount of gpu_unlock.targets will help — an entry the module cannot see is not an entry it can unlock.

Your next gpu unlock step

Install the drop-in, rebuild, run the lister before you reboot. When the image shows the module, the journal decides what happens next: unlocked means you are done, -16 or -2 means move to troubleshooting, and nothing at all means the boot never reached the module.

If you have not checked the card yet, start at the gpu-unlock compatibility table. A card outside cards[] is logged and skipped at boot, and no drop-in fixes that.