System configuration
- Laptop: GIGABYTE G5 KF
- OS: Pop!_OS 26.04 (COSMIC / Resolute)
- GPU: NVIDIA GeForce RTX 4060 Laptop GPU
- NVIDIA driver: 595.104.02 (open kernel modules)
- Original kernel: 7.1.5-76070105-generic
- Updated kernel: 7.2.6-76070206-generic
- Root filesystem: ext4 on LVM inside a LUKS-encrypted NVMe partition
- Bootloader: systemd-boot with kernelstub-managed EFI files
Symptoms
Normal boot would hang during early initialization while waiting for:
/dev/mapper/data-root
The LUKS password prompt appeared, but the encrypted root volume did not become available and the system could not finish booting.
Increasing Dracut's retry timeout was considered, but the system was already waiting for several minutes, making a simple timeout issue unlikely.
Troubleshooting
We verified that:
- The NVMe drive and encrypted partition were detected.
- The LUKS mapping and LVM logical volume worked during successful boots.
- The initramfs contained the required
crypt, lvm, and NVMe components.
- The NVIDIA 595 module was installed for the running kernel.
- The LVM udev rules and
lvm_scan script matched between the old and new initramfs images.
A particularly useful test was booting with rd.break=pre-trigger. After typing exit and entering the LUKS password, the system booted successfully.
Kernel stack trace
During a failing boot, we reached the Dracut initqueue shell and found a blocked udev worker.
Its kernel stack included NVIDIA functions such as:
kgspInitRm_IMPL
RmInitAdapter
nv_start_device
nv_open_device
nvkms_open_gpu
nv_drm_register_drm_device
The kernel also reported a udev worker blocked on an rw-semaphore, likely owned by a kernel worker.
This provided strong evidence of a hang during NVIDIA GPU initialization. We could not conclusively prove that this was the direct cause of the missing LUKS/LVM root device, but it gave us a much more specific lead than the earlier LVM investigation.
Workaround that worked
We added the following parameter to the normal EFI boot entry's options line:
rd.driver.blacklist=nvidia,nvidia_drm,nvidia_modeset,nvidia_uvm
This tells Dracut not to load those NVIDIA modules during the initramfs stage. Dracut documents rd.driver.blacklist for preventing modules from loading during early boot.
Documentation: https://github.com/dracut-ng/dracut/blob/main/man/dracut.usage.adoc
The system then booted normally without manually stopping at a Dracut breakpoint. NVIDIA loaded later, and nvidia-smi worked.
Results
The workaround was tested successfully with:
- Kernel 7.1.5-76070105-generic
- Kernel 7.2.6-76070206-generic
For both, NVIDIA 595.104.02 loaded successfully after boot, and nvidia-smi recognized the RTX 4060.
The kernel update also completed successfully, including the DKMS build of NVIDIA 595 for kernel 7.2.6.
Important persistence detail
This system uses kernelstub to manage the EFI kernel and initramfs files. During the kernel update, kernelstub regenerated the default boot entry and removed the blacklist parameter we had added manually.
We restored the parameter in both:
/boot/efi/loader/entries/Pop_OS-current.conf — the normal boot entry
/boot/efi/EFI/Pop_OS-<machine-id>/cmdline — kernelstub's command-line configuration
After restoring the parameter in both places, the system successfully booted kernel 7.2.6 with NVIDIA 595.104.02.
If you try this workaround, verify your own bootloader's configuration and ensure the parameter survives kernel updates. Do not copy the example paths blindly.
Current status
- Normal boot works without a manual Dracut breakpoint.
- Kernel 7.2.6 is running.
- NVIDIA 595.104.02 and
nvidia-smi work.
- The encrypted LUKS/LVM root filesystem mounts successfully.
- The previous-kernel fallback and recovery entry were retained.
Caveat
This is a workaround, not a confirmed root-cause fix. The evidence strongly suggests a problem involving NVIDIA initialization during early boot, but we did not identify the precise driver bug or prove the complete causal chain.
If anyone has seen similar NVIDIA 595 hangs involving kgspInitRm_IMPL, RmInitAdapter, or blocked udev workers on GIGABYTE G5 KF hardware, I'd be interested to know whether this workaround helps or whether a more permanent fix is available.
The screenshot shows the blocked udev worker's kernel stack trace for anyone interested