[SOLVED] nvidia-open-dkms keeps getting preempted by nouveau

zhihuiyuze · 2025-08-11 23:42:43

Hardware / setup

Laptop: ASUS (Tianxuan 5 Pro)

dGPU: NVIDIA AD106M (GeForce RTX 4070 Mobile)

iGPU: AMD AI9HX370 (Radeon 880M / 890M)

Kernel: linux-zen

Display stack target: KDE Plasma + Wayland

Boot: systemd-boot with UKI, Secure Boot enabled (own keys via sbctl) Arch and Windows 11 dual-boot (Windows on NVMe#1, Arch on NVMe#2; Windows EFI copied to the second drive)

Root FS: LVM on LUKS, filesystem bcachefs /boot not encrypted with 2Gb Fat32, 2Tb allocated to Windows from NVme#2(Not on LVM or LUKS)

TPM: LUKS token via TPM2, currently using PCR 7 only (I tried 7+11 with ukify/systemd-measure, but TPM wouldn’t release the secret after reboot)

Problem

Even after switching to nvidia-dkms, nouveau still gets loaded at boot and ends up binding to the GPU. As a result, SDDM on Wayland fails to start (black screen / “Could not start Display server on vt 2”).
If I remove nvidia-open-dkms or nvidia-dkms(I tried both closed source and open source) and fall back to nouveau, SDDM still fails, and I cannot get into KDE.

According to the Wiki, once you install nvidia-open-dkms, nouveau will be disabled without any additional steps. However, nouveau is still loaded on my system.

What I’ve tried

1. Disable nouveau

* /etc/modprobe.d/blacklist-nouveau.conf:

blacklist nouveau
options nouveau modeset=0

* Removed kms from HOOKS in /etc/mkinitcpio.conf, rebuilt:

HOOKS=(base udev autodetect modconf block sd-encrypt lvm2 filesystems keyboard fsck sd-vconsole udev)
mkinitcpio -P

* Rebuilt the UKI with ukify and re-signed (Secure Boot).

2. Install NVIDIA open kernel module

* Packages: nvidia-open-dkms, nvidia-utils, dkms, linux-zen-headers (DKMS reports the module built for the current kernel).

* After reboot, lsmod still shows nouveau and not nvidia modules, and lspci -k shows:

Kernel driver in use: nouveau
Kernel modules: nvidia

* journalctl shows repeated NVRM: No NVIDIA devices probed (consistent with nouveau already bound).

3. Tried proprietary NVIDIA driver

* Swapped to proprietary nvidia packages — same end result (nouveau grabs the device first, SDDM Wayland still fails).

4. Wayland / KMS checks

* I know Wayland needs DRM KMS (nvidia_drm.modeset=1).
Problem: I don’t even see /sys/module/nvidia_drm/parameters/modeset because the nvidia_drm module never loads (nouveau binds first).

Current symptoms / logs

* lsmod | grep -E 'nouveau|nvidia|amdgpu' → shows nouveau + amdgpu, no nvidia*.

* lspci -k → NVIDIA device uses nouveau; AMD device uses amdgpu.

* journalctl -b -1 | grep -iE 'nvrm|nvidia|nouveau|drm' → many NVRM: No NVIDIA devices probed lines.

* SDDM logs: “Display server starting…”, then “Could not start Display server on vt 2”.

Questions

1. When dkms status shows the NVIDIA open module is built, but nouveau still binds to the GPU after reboot, what’s the usual culprit on Arch?
(Given I already blacklisted nouveau via modprobe, removed kms from HOOKS, rebuilt initramfs/UKI, and re-signed for Secure Boot. I added back km on HOOKS, also the same result.)

2. For KDE Plasma on Wayland with AMD iGPU + NVIDIA dGPU (offload), what is the recommended way to do so?

3. Is there anything about UKI / Secure Boot / LUKS (bcachefs) that could cause the initramfs to still include or load nouveau early despite the blacklist?

Extra info I can provide on request

Any hints to stop nouveau from binding (so nvidia_drm can load and KMS can work under Wayland) would be hugely appreciated. Thanks!

Last edited by zhihuiyuze (2025-08-20 07:58:16)

seth · 2025-08-12 06:37:33

Please don't paraphrase, https://bbs.archlinux.org/viewtopic.php?id=57855 and also see https://wiki.archlinux.org/title/Genera … s_and_code

Then please post your complete system journal for the boot:

sudo journalctl -b | curl -F 'file=@-' 0x0.st

V1del · 2025-08-12 08:14:14

My guess is you forgot to mount the /boot partition (or the reverse, you mounted a /boot partition but the actual kernel images are on the /boot directory on your root partition) because all of these measures would lead to nouveau not loading guaranteed unless you were not loading the correctly adjusted initramfs. But the output seth requested will bring more light on this and other questions.

zhihuiyuze · 2025-08-12 08:17:46

Hi,

Please find the full log via the link > http://0x0.st/8Cst.txt

zhihuiyuze · 2025-08-12 08:40:39

V1del wrote:

My guess is you forgot to mount the /boot partition (or the reverse, you mounted a /boot partition but the actual kernel images are on the /boot directory on your root partition) because all of these measures would lead to nouveau not loading guaranteed unless you were not loading the correctly adjusted initramfs. But the output seth requested will bring more light on this and other questions.

I don't think that's the problem, because I see /boot is mounted.

mount > http://0x0.st/8CsG.txt
fdisk -l > http://0x0.st/8CsG.txt
mkinitcpio -P > http://0x0.st/8CsR.txt

seth · 2025-08-12 11:54:36

nouveau is still in the initramfs, the reason is

  -> Running build hook: [kms]

Lose that.

zhihuiyuze · 2025-08-12 13:24:59

Ah, I added back kms after I deleted kms and it still doesn't work.

Here are the logs and configurations father I removed KMS again.

mkinitcpio.conf > http://0x0.st/8Co_.txt

mkinitcpio -P > http://0x0.st/8Cof.txt

And I rebooted the system again.

The output of journalctl -b is here.

http://0x0.st/8CoJ.txt

seth · 2025-08-12 13:33:48

nouveau is clearly still in the initramfs.
either you're storing that in the wrong location or it's because

HOOKS=(base systemd autodetect modconf block sd-encrypt lvm2 filesystems keyboard fsck sd-vconsole udev resume)

you've some busybox hooks next to systemd
https://wiki.archlinux.org/title/Mkinit … mmon_hooks - udev and resume should™ not be in there.

Do you have files in /boot after umouting the boot partition?

zhihuiyuze · 2025-08-12 14:02:07

No, after I umount / boot and ls -la /boot it is empty.

> you've some busybox hooks next to systemd
https://wiki.archlinux.org/title/Mkinit … mmon_hooks - udev and resume should™ not be in there.

Okay I see, systemd already includes udev and resume. Now I have removed it, but I can't go to the GUI still.

I was thinking about securely boot might provenning loading the dkms driver, but if it is unsigned I think that I can't even go to tty. > would uki signed the driver also when I process mkinitcpio -P? But I have a configuration for doing auto-signing.

Here are the logs that might have some information needed.

bootctl status > http://0x0.st/8CHW.txt
demsg -T > http://0x0.st/8CHE.txt
journalctl -b > http://0x0.st/8CH6.txt

From demsg -T I see

 [Tue Aug 12 21:46:05 2025] NVRM: No NVIDIA devices probed.
[Tue Aug 12 21:46:05 2025] nvidia-nvlink: Unregistered Nvlink Core, major device number 510

But this is not related with SB, is just because nouveau linked the GPU.

seth · 2025-08-12 14:26:20

I was thinking about securely boot might provenning loading the…

Your exclusive problem so far is

seth wrote:

nouveau is clearly still in the initramfs.

There's essentially no way you're properly updating the UKI (should™ not include nouveau but should™ blacklist it)

You can blacklist nouveau using a kernel commandline parameter.

zhihuiyuze · 2025-08-13 00:59:55

According to the document, if I have modconf in hook the system should load /etc/modprobe.d but it doesn't.

I tried to change /etc/kernel/cmdline to

 rd.luks.name= my uuid =cryptlvm root=/dev/vg0/root rw quiet splash module_blacklist=nouveau

Or

 rd.luks.name= my uuid =cryptlvm root=/dev/vg0/root rw quiet splash modprobe.blacklist=nouveau module_blacklist=nouveau nouveau.modeset=0

But nouveau is still loading.

I noticed that when I executed mkinitcpio -P it reads /etc/mkinitcpio.d/linux-zen.preset > http://0x0.st/8Cax.txt

Should I uncommit

 #default_config="/etc/mkinitcpio.conf"

seth · 2025-08-13 05:35:06

Do those stanzas show up in

cat /proc/cmdline

?

zhihuiyuze · 2025-08-13 05:44:42

No it doesn’t, probably it doesn’t read my configuration?

Is there a default location for uki to read cmdline?

V1del · 2025-08-13 14:36:19

https://wiki.archlinux.org/title/Unifie … mmand_line you should probably read the entirety of that page if you want to opt for UKIs

According to that preset file you're not using an UKI however? You'd have to check your systemd-boot config https://wiki.archlinux.org/title/System … ng_loaders -- What instructions did you use to originally set this up?

Last edited by V1del (2025-08-13 14:45:29)

zhihuiyuze · 2025-08-13 19:27:57

I refer to not only one wiki or tutorial I might be mess up.

For example
https://github.com/systemd/systemd/issues/35820
https://bbs.archlinux.org/viewtopic.php?id=297811
jpetazzo.github.io/2024/02/23/archlinux-luks-tpm-secureboot-install/

The wiki pages that you provided I also checked them before.

I notice that

> mkinitcpio supports reading kernel parameters from command line files in the /etc/cmdline.d directory.

I don't have the folder but I have /etc/kernel/cmdline

> Alternatively, /etc/kernel/cmdline can be used to configure the kernel command line.

I think after I regenerate the kernel image by mkinitcpio -P it should read it.

I also tried to edit /etc/kernel/install.conf

Change the parameter for uki_generator from ukify to mkinitcpio but the result from proc cmdline doesn't show my cmdline configuration after I reboot.

My /boot/loader/entries is empty does this mean I'm not using system boot at all? I thought UEFI would scan every.efi files in /boot/EFI.

> Signing for Secure Boot
If you have Secure Boot enabled, you may want to add a pacman hook to automatically sign the boot manager upon every upgrade of the package:

I don't use systemd hook showing in the system boot pages because I have to write on by myself and the wiki just shows a configuration triggered by pacman.

But with uki.conf I can do after adding any kmod or upgradeung thee kernel and than signing automatically very easily.

In my current understanding, uki is like a plugin for system boot. So maybe my system boot is not updated the kernel? But I see once I do mkinitcpio /P there were new kernel files saved to /boot.

Okay now I tried to use bootctl update, the security boot is invalid. Probably bootctl update hasn't triggered uki.

Last edited by zhihuiyuze (2025-08-13 19:30:39)

seth · 2025-08-13 20:21:04

head -n1000 /etc/mkinitcpio.d/*.preset /dev/null

zhihuiyuze · 2025-08-14 11:17:32

seth wrote:

head -n1000 /etc/mkinitcpio.d/*.preset /dev/null

==> /etc/mkinitcpio.d/linux-zen.preset <==
# mkinitcpio preset file for the 'linux-zen' package

#ALL_config="/etc/mkinitcpio.conf"
ALL_kver="/boot/vmlinuz-linux-zen"

PRESETS=('default' 'fallback')

#default_config="/etc/mkinitcpio.conf"
default_image="/boot/initramfs-linux-zen.img"
#default_uki="/efi/EFI/Linux/arch-linux-zen.efi"
#default_options="--splash /usr/share/systemd/bootctl/splash-arch.bmp"

#fallback_config="/etc/mkinitcpio.conf"
fallback_image="/boot/initramfs-linux-zen-fallback.img"
#fallback_uki="/efi/EFI/Linux/arch-linux-zen-fallback.efi"
fallback_options="-S autodetect"

==> /etc/mkinitcpio.d/linux.preset <==
# mkinitcpio preset file for the 'linux' package

#ALL_config="/etc/mkinitcpio.conf"
ALL_kver="/boot/vmlinuz-linux"

PRESETS=('default' 'fallback')

#default_config="/etc/mkinitcpio.conf"
default_image="/boot/initramfs-linux.img"
#default_uki="/efi/EFI/Linux/arch-linux.efi"
#default_options="--splash /usr/share/systemd/bootctl/splash-arch.bmp"

#fallback_config="/etc/mkinitcpio.conf"
fallback_image="/boot/initramfs-linux-fallback.img"
#fallback_uki="/efi/EFI/Linux/arch-linux-fallback.efi"
fallback_options="-S autodetect"

==> /dev/null <==

Scimmia · 2025-08-14 11:25:40

So how are you actually generating the UKI?

zhihuiyuze · 2025-08-14 11:31:47

I think yes.

I use /etc/kernel/uki.conf to do the auto signing workflow.

It works when I execute mkinutcpio -P, and I rebooted the secure boot error wouldn’t pop on. So it do signing the kernel.

But when I execute bootctl update I found that I have to do sbctl sign -s for all *.efi /boot/EFI.

Scimmia · 2025-08-14 11:42:28

The answer to 'how' cannot be 'I think yes'.

zhihuiyuze · 2025-08-14 11:44:48

Scimmia wrote:

So how are you actually generating the UKI?

bootctl list >

 
         type: Boot Loader Specification Type #2 (.efi)
        title: Arch Linux (selected)
           id: arch-linux-zen.efi
       source: /boot//EFI/Linux/arch-linux-zen.efi (on the EFI System Partition)
     sort-key: arch
      version: rolling
        linux: /boot//EFI/Linux/arch-linux-zen.efi
      options: rd.luks.name=1101ff97-2720-4676-8561-8693ca7ae6da=cryptlvm root=/dev/vg0/root rw quiet

         type: Automatic
        title: Windows Boot Manager (default)
           id: auto-windows
       source: /sys/firmware/efi/efivars/LoaderEntries-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f (on the EFI System Partition)

         type: Automatic
        title: Reboot Into Firmware Interface
           id: auto-reboot-to-firmware-setup
       source: /sys/firmware/efi/efivars/LoaderEntries-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f (on the EFI System Partition)

bootctl status > http://0x0.st/8C7N.txt

I have

 type: Boot Loader Specification Type #2 (.efi)

as you can see

Last edited by zhihuiyuze (2025-08-14 11:45:52)

zhihuiyuze · 2025-08-14 11:57:03

Scimmia wrote:

The answer to 'how' cannot be 'I think yes'.

I misunderstood you, though you wanted me to confirm I’m using UKI.

I use UKI for signing the kernel, I see from the wiki.

mkinitcpio will assemble the UKI itself unless systemd-ukify is installed. In which case, UKI creation will be offloaded to ukify unless this is explicitly disabled with the --no-ukify option.

I made it after I executed mkinitcpio -P. But I'm not very familiar with uki, so it would be better if you can tell me how to confirm that.

My uki.conf

cat /etc/kernel/uki.conf

[UKI]
SecureBootSigningTool=systemd-sbsign
SignKernel=true
SecureBootPrivateKey=/var/lib/sbctl/keys/db/db.key
SecureBootCeritifcate/var/lib/sbctl/keys/db/db.pem

And for /etc/kernel/install.conf

layout=uki
uki_generator=ukify
#uki_generator=mkinitcpio

seth · 2025-08-14 12:04:44

So if you're not using mkinitcpio to build the UKI, why do you keep editing its config and running it?
I'd suggest to leave uki_generator at mkinitcpio, fix the kernel presets to use default_uki isntead of default_image and try again.

Edit: see https://wiki.archlinux.org/title/Unifie … ecure_Boot for kernel signing w/ this approach.

Last edited by seth (2025-08-14 12:05:40)

Scimmia · 2025-08-14 12:58:21

zhihuiyuze wrote:

Scimmia wrote:
The answer to 'how' cannot be 'I think yes'.
I misunderstood you, though you wanted me to confirm I’m using UKI.
I use UKI for signing the kernel,

UKI does nothing of the sort. It's an image that includes the kernel, initramfs, and stub loader.

In the first post, you said "Rebuilt the UKI", HOW DID YOU DO THAT? How are you actually building the UKI?

zhihuiyuze · 2025-08-15 13:01:04

seth wrote:

So if you're not using mkinitcpio to build the UKI, why do you keep editing its config and running it?
I'd suggest to leave uki_generator at mkinitcpio, fix the kernel presets to use default_uki isntead of default_image and try again.
Edit: see https://wiki.archlinux.org/title/Unifie … ecure_Boot for kernel signing w/ this approach.

I previously thought that mkinitcpio was the only way to generate an image. After reviewing the wiki again, I saw that if I use mkinitcpio to generate the image, I need a /etc/initcpio/post/uki-sbsign script for signing. I did not create this script. Later, I found in the wiki that files in /usr/lib/initcpio/post/ are also read, and when installing sbsign, it automatically creates /usr/lib/initcpio/post/sbctl, so there is no need to add it manually.

Currently, I have commented out
default_image="/boot/initramfs-linux-zen.img"
and
fallback_image="/boot/initramfs-linux-zen-fallback.img".

I have modified and uncommented
default_uki="/boot/EFI/Linux/arch-linux-zen.efi"
and
fallback_uki="/boot/EFI/Linux/arch-linux-zen-fallback.efi".

The cmdline is now being read, but I still get a black screen after entering the system. The output of cat /proc/cmdline is here:
http://0x0.st/KrTz.txt

The output of journalctl -b is here:
http://0x0.st/KrTr.txt

Additionally, if I use ukify as the tool to generate the image (https://man.archlinux.org/man/ukify.1), I could not find a way for it to automatically generate the image each time a DKMS module is added or the kernel is updated. Should the configuration file be saved in kernel/uki.conf so it runs automatically? Also, it does not seem to have an option to load hooks.

Arch Linux

#1 2025-08-11 23:42:43

[SOLVED] nvidia-open-dkms keeps getting preempted by nouveau

#2 2025-08-12 06:37:33

Re: [SOLVED] nvidia-open-dkms keeps getting preempted by nouveau

#3 2025-08-12 08:14:14

Re: [SOLVED] nvidia-open-dkms keeps getting preempted by nouveau

#4 2025-08-12 08:17:46

Re: [SOLVED] nvidia-open-dkms keeps getting preempted by nouveau

#5 2025-08-12 08:40:39

Re: [SOLVED] nvidia-open-dkms keeps getting preempted by nouveau

#6 2025-08-12 11:54:36

Re: [SOLVED] nvidia-open-dkms keeps getting preempted by nouveau

#7 2025-08-12 13:24:59

Re: [SOLVED] nvidia-open-dkms keeps getting preempted by nouveau

#8 2025-08-12 13:33:48

Re: [SOLVED] nvidia-open-dkms keeps getting preempted by nouveau

#9 2025-08-12 14:02:07

Re: [SOLVED] nvidia-open-dkms keeps getting preempted by nouveau

#10 2025-08-12 14:26:20

Re: [SOLVED] nvidia-open-dkms keeps getting preempted by nouveau

#11 2025-08-13 00:59:55

Re: [SOLVED] nvidia-open-dkms keeps getting preempted by nouveau

#12 2025-08-13 05:35:06

Re: [SOLVED] nvidia-open-dkms keeps getting preempted by nouveau

#13 2025-08-13 05:44:42

Re: [SOLVED] nvidia-open-dkms keeps getting preempted by nouveau

#14 2025-08-13 14:36:19

Re: [SOLVED] nvidia-open-dkms keeps getting preempted by nouveau

#15 2025-08-13 19:27:57

Re: [SOLVED] nvidia-open-dkms keeps getting preempted by nouveau

#16 2025-08-13 20:21:04

Re: [SOLVED] nvidia-open-dkms keeps getting preempted by nouveau

#17 2025-08-14 11:17:32

Re: [SOLVED] nvidia-open-dkms keeps getting preempted by nouveau

#18 2025-08-14 11:25:40

Re: [SOLVED] nvidia-open-dkms keeps getting preempted by nouveau

#19 2025-08-14 11:31:47

Re: [SOLVED] nvidia-open-dkms keeps getting preempted by nouveau

#20 2025-08-14 11:42:28

Re: [SOLVED] nvidia-open-dkms keeps getting preempted by nouveau

#21 2025-08-14 11:44:48

Re: [SOLVED] nvidia-open-dkms keeps getting preempted by nouveau

#22 2025-08-14 11:57:03

Re: [SOLVED] nvidia-open-dkms keeps getting preempted by nouveau

#23 2025-08-14 12:04:44

Re: [SOLVED] nvidia-open-dkms keeps getting preempted by nouveau

#24 2025-08-14 12:58:21

Re: [SOLVED] nvidia-open-dkms keeps getting preempted by nouveau

#25 2025-08-15 13:01:04

Re: [SOLVED] nvidia-open-dkms keeps getting preempted by nouveau

Board footer