Black screen on Nvidia after updating to 20260428

[Cid944]

Update to kernel 7.0.9-1, still black screen.

[mzimmerm]

A bit different for me , but still not working - no black screen but the NVIDIA driver does not load when booting with 7.0.9-1.

But perhaps by now I messed things up, I installed a long-term kernel with long term NVIDIA driver and did run the update when booted from the long-term kernel. Restart into 7.0.9-1, no NVIDIA driver loaded, defaults to VESA. Surprisingly, booting into the long term still works, so it did not de-install the long term NVIDIA driver.

[csrinivas]

updated to kernel 7.0.9. again greeted by a green screen. back to initcall entry for now.

My question is what is that i miss with initcall? If it is just missing the boot process visual on screen, i won’t mind it.

[Lioli7k]

See my earlier post that explains drawbacks of this approach.

Black screen on Nvidia after updating to 20260428

Until Nvidia driver is up and running you won’t be able to see TTY. So if anything is gonna go wrong (like root filesystem failed to mount or Nvidia driver is broken) you won’t be able to see or address it. Other than that nothing dangerous. P.S. In case of full disk encryption that also means you have to enter password blindly if it’s being asked for.

[Lioli7k]

User space part of a driver is the same for both default and longterm. If you want to be able to boot into both you need to install both KMP packages. Only one is selected by default for whatever reason…

i  | nvidia-open-driver-G07-signed-kmp-default  | package | 595.71.05_k7.0.9_1-2.5       | x86_64 | repo-oss
i  | nvidia-open-driver-G07-signed-kmp-longterm | package | 595.71.05_k6.18.31_1-2.5     | x86_64 | repo-oss

[Cid944]

@csrinivas It seems that the HW initialization for the graphic cards have changed with the update from kernel 6.x.x to 7.x.x. For several of the users in this forum appending initcall_blacklist=sysfb_init to the GRUB_CMDLINE_LINUX_DEFAULT in the default grub configuration “solved” the problem including myself. Downside is, that there nearly no console output during boot. I consider this as a workaround and not as a fix.

[hendersj]

I would probably recommend that using this option should be combined with ensuring the Magic SysRq functionality is enabled. That way if things get hung up and you can’t ssh into the system, you can at least do a reasonably clean shutdown by syncing the drives, unmounting them, and then rebooting (SysRq+S, SysRq+U, SysRq+B - in that order).

It is important when doing that to make sure that the drive activity has actually finished after each of the first two commands, however - as far as I know, they each take place immediately.

[mzimmerm]

Yes, thanks for the follow up. I did install the proprietary versions (default and longterm) and can boot to both but ONLY with the initcall_blacklist=sysfb_init in the GRUB_CMDLINE_LINUX_DEFAULT.

I think the necessary condition is to install the kmp-default when booted from the latest kernel, and kmp-longterm when booted from the longterm kernel. I originally messed that up and the kmp-default did not boot. Hopefully I am not giving an invalid information as I tried too many things to get my system to work.

[Cid944]

I don’t understand why the full proprietary G07 nVidia driver is not available through the openSUSE repos. On other distros it is already available.

[hendersj]

This question isn’t really on-topic for this discussion. But see https://en.opensuse.org/Restricted_formats#Proprietary_Linux_kernel_modules_which_include_Linux_headers for some information about it.

Short version: It’s a conscious decision that “openSUSE” be “open” software, and by definition, proprietary software isn’t open.

But if you have further questions about it, the Open Chat section is a better place to ask. However be aware that this is a project policy decision that is highly unlikely to change, so trying to advocate for a change is not likely to be fruitful. Happy to answer questions, but we’re not going to debate it.

[mchnz]

Seems to work for me initcall_blacklist=sysfb_init - without that I see messages about GPU resets, and sessions fall over periodically. This would be:

TW 20260520
NVIDIA GeForce RTX 3060 LHR
Ryzen 5 5600  TUF GAMING B550-PLUS WIFI II 
X11 and Wayland plasma6
kernel-default-7.0.9-1.1
nvidia-common-G07-595.71.05-1.x86_64
nvidia-open-driver-G07-signed-cuda-kmp-default-595.71.05_k7.0.9_1-2.5.x86_64
nvidia-persistenced-595.71.05-1.x86_64
nvidia-compute-utils-G07-595.71.05-1.x86_64
libnvidia-gpucomp-595.71.05-1.x86_64
nvidia-modprobe-595.71.05-1.x86_64
kernel-firmware-nvidia-20251018-1.1.noarch
libnvidia-cfg-595.71.05-1.x86_64
nvidia-gl-G07-595.71.05-1.x86_64
nvidia-compute-G07-595.71.05-1.x86_64
libnvidia-egl-x111-1.0.5-150700.1.1.x86_64
libnvidia-ml-595.71.05-1.x86_64
libnvidia-egl-wayland1-1.1.21-150700.1.1.x86_64
libnvidia-egl-gbm1-1.1.3-150700.1.1.x86_64
nvidia-video-G07-595.71.05-1.x86_64
nvidia-libXNVCtrl-595.71.05-1.x86_64
nvidia-settings-595.71.05-1.x86_64

[FrankyU2]

@dart364

dmesg | grep -E ‘initcall’ | grep -E ‘fb|framebuffer|simple|drm|sysfb|efifb|vesafb’

Did not get to try this until now. My output was the following…

[    0.000000] [      T0] Command line: BOOT_IMAGE=/boot/vmlinuz-7.0.9-1-default root=/dev/mapper/system-root resume=/dev/system/swap nvidia-drm.modeset=1 plymouth.enable=0 rd.driver.blacklist=nouveau security=selinux selinux=1 nvidia_drm.fbdev=1 initcall_debug mitigations=off
[    0.074662] [      T0] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-7.0.9-1-default root=/dev/mapper/system-root resume=/dev/system/swap nvidia-drm.modeset=1 plymouth.enable=0 rd.driver.blacklist=nouveau security=selinux selinux=1 nvidia_drm.fbdev=1 initcall_debug mitigations=off
[    0.215240] [      T1] initcall efi_earlycon_remap_fb+0x0/0x70 returned 0 after 0 usecs
[    0.321054] [      T1] initcall fbmem_init+0x0/0x50 returned 0 after 0 usecs
[    1.378238] [      T1] initcall libaescfb_init+0x0/0x1a0 returned 0 after 12 usecs
[    1.517689] [      T1] initcall drm_core_init+0x0/0xa0 returned 0 after 641 usecs
[    1.517745] [      T1] initcall efidrm_platform_driver_init+0x0/0x20 returned 0 after 27 usecs
[    1.517785] [      T1] initcall simpledrm_platform_driver_init+0x0/0x20 returned 0 after 17 usecs
[    1.517823] [      T1] initcall vesadrm_platform_driver_init+0x0/0x20 returned 0 after 16 usecs
[    1.538209] [      T1] initcall sysfb_init+0x0/0x1a0 returned 0 after 6841 usecs
[    1.538358] [      T1] initcall framebuffer_driver_init+0x0/0x20 returned 0 after 16 usecs
[    2.014262] [      T1] initcall efi_earlycon_unmap_fb+0x0/0x50 returned 0 after 0 usecs
[   47.603831] [   T1092] initcall nv_linux_drm_init+0x0/0xff0 [nvidia_drm] returned 0 after 1601388 usecs

[FrankyU2]

Hope your new Nvidia card works with your motherboard and additionally you don’t suffer from this issue. While looking at my current boot log via journalctl I noticed this.

calling  quirk_nvidia_no_bus_reset+0x0/0x30 @ 1
May 23 12:29:42 hp-suse kernel: pci 0000:01:00.1: quirk_nvidia_no_bus_reset+0x0/0x30 took 0 usecs
May 23 12:29:42 hp-suse kernel: pci 0000:01:00.2: [10de:1ad8] type 00 class 0x0c0330 PCIe Endpoint
May 23 12:29:42 hp-suse kernel: pci 0000:01:00.2: BAR 0 [mem 0x4042000000-0x404203ffff 64bit pref]
May 23 12:29:42 hp-suse kernel: pci 0000:01:00.2: BAR 3 [mem 0x4042040000-0x404204ffff 64bit pref]
May 23 12:29:42 hp-suse kernel: pci 0000:01:00.2: calling  quirk_nvidia_no_bus_reset+0x0/0x30 @ 1

I don’t know if this has much bearing on the issue because no hypervisor is active. It seems to be called multiple times.

quirk_no_bus_reset is a Linux kernel flag applied to specific Nvidia GPUs (like the T4, select Blackwell chips, and various consumer models) to prevent the kernel or VM hypervisors from forcing a Secondary Bus Reset (SBR) or Function Level Reset (FLR), which can cause the GPU to permanently fall off the PCIe

Interestingly the recovery method for a host level passthru is a nvidia-smi reset.

[dart364]

@FrankyU2

Hope your new Nvidia card works with your motherboard and additionally you don’t suffer from this issue. While looking at my current boot log via journalctl I noticed this.

``

Well kind of a strange thing to say but the new 3070 ti works with initcall_blacklist=sysfb_init and I got da bug now !! Woohoo !! Seriously though gonna go do some testing to see if the card is working properly then start in on the bug. I forgot to uninstall my 580 (latest the “hard way”) drivers so I’m running on those right now.

[FrankyU2]

Bugs away

[dart364]

Well sorry but I updated to the NVIDIA-Linux-x86_64-595.71.05 drivers the “hard way”, chose the proprietary version annnnnd I can boot with no added params in my kernel command line.

I am a member of the vid and render groups like @malcolmlewis and I can post my inxi -GSaz(it’s farther up ) again but the only thing that has changed is the vid card and driver. Here is my 90-nvidia-conf for modprobe. The uvm entries are just me experimenting but who knows they might be doing something …

dart@windeath:~> cat /etc/modprobe.d/90-nvidia.conf 
# Modprobe won't load nvidia_uvm without this !?
# softdep nvidia post: nvidia_uvm

# See 'modinfo nvidia | sort' for list and
# See "cat /proc/driver/nvidia/params" for the actual settings

options nvidia \
	NVreg_PreserveVideoMemoryAllocations=1 \
	NVreg_EnableStreamMemOPs=1 \

# For Wayland 
options nvidia_drm \
	modeset=1 \

# Placeholder for nvidia_modeset
# See 'systool -vm nvidia_modeset'
# There are no parameters for nvidia_modeset .. yet

# Placeholder - Unified memory
# use 'systool -vm nvidia_uvm' to see all settings
options nvidia_uvm \
	uvm_page_table_location=vid \
	uvm_force_prefetch_fault_support=1 \
	uvm_fault_force_sysmem=1 \
	uvm_exp_gpu_cache_sysmem=1 \
	uvm_exp_gpu_cache_peermem=1 \

dart@windeath:~> 

Good luck …

[malcolmlewis]

@dart364 Gald it’s working

Did you use any additional options to the run file install?

Did you look at the output from cat /proc/driver/nvidia/params | sort to compare any differences?

[dart364]

I did not use any additional options … just chose to use proprietary in the dialog although I could have used the command line option instead … I haven’t sorted the differences yet but I did see that the uvm_force_prefetch_fault_support=1 was invalid for this card so I got rid of that … I will also be adding your NVreg_UsePageAttributeTable=1 because it seems like a good idea … did it for one boot and saw no difference so I removed it for additional testing for now just to keep things as close to my original config as possible … will compare the other params tomorrow

Next time I will use ./NVIDIA .<version>.run --kernel-module-type=proprietary “or -M proprietary” -s just so I don’t have to deal with questions from the installer

[malcolmlewis]

@dart364 By default it will use the open driver, likewise I prefer to use the system glvnd, not the built in version…

./NVIDIA-Linux-x86_64-$RUN_VERSION.run \
    --ui=none \
    --no-questions \
    --accept-license \
    --disable-nouveau \
    --no-install-libglvnd \
    --no-cc-version-check \
    --kernel-module-type=proprietary

[dart364]

Ok … just added NVreg_UsePageAttributeTable=1 and just had to use the initcall_blacklist=sysfb_initto boot … removed it and rebooted now it boots fine again …