Black screen on Nvidia after updating to 20260428

English Install/Boot/Login
,
461

That is exactly what I did. Problem lies when I try to do any modifications. It seems like it is not meant to be modified directly. Piecing things together yelds steps like this:

  1. Clone https://github.com/openSUSE/kernel-source and switch to appropriate branch (stable for tumbleweed).
  2. Clone mainline Linux kernel repository from kernel.org (Undocumented.)
  3. export LINUX_GIT=/path/to/mainline-linux-repo (Undocumented. Used in build scripts.)
  4. Do changes. (Sparsely documented.)
  5. ./scripts/tar-up

That produces kernel-source folder that can be used with osc.

462

The Readme in the kernel-source itself has some hints:

463

It sure is helpful but it misses out some important points that I had to figure out myself.

464

Just check out from OBS osc co openSUSE:Factory kernel-source?

465

Yup. Then config I need to change is config/x86_64/default inside config.tar.bz2. That archive is generated by a tar-up script from https://github.com/openSUSE/kernel-source.

466

I updated my system today with zypper dup and was welcomed with a magenta screen after some normal boot messages. No console terminal switch possible, just long power off press gets me out of this.

Sorry, didnā€™t read every post here, but is my impression of this thread correct that currently, over two weeks later, tumbleweed with nvidia open driver g06 or g07 is still broken for a lot of users?

Tried last kernel 6.19.5-1 which seemed to help some - not me, same same.
Tried rescue mode ā†’ blue screen, also just long power off press to get out
Tried runlevel 3 on grub linux commandline - same magenta
Tried runlevel 3 with 6.19.5-1 ā†’ get text console and can ssh login. So I can test/restore/configure from there, e.g. get this info:

joachim@job6:~> inxi -GSaz
System:
  Kernel: 6.19.5-1-default arch: x86_64 bits: 64 compiler: gcc v: 15.2.1 clocksource: tsc
    avail: hpet,acpi_pm parameters: BOOT_IMAGE=/boot/vmlinuz-6.19.5-1-default
    root=/dev/mapper/system-root resume=/dev/system/swap mitigations=auto quiet security=selinux
    selinux=1 rd.driver.blacklist=nouveau 3
  Console: pty pts/2 DM: SDDM Distro: openSUSE Tumbleweed 20260512
Graphics:
  Device-1: NVIDIA GB206 [GeForce RTX 5060 Ti] vendor: Micro-Star MSI driver: N/A
    alternate: nouveau non-free: 550-580.xx+ status: current (as of 2025-11) arch: Lovelace
    code: AD1xx process: TSMC n4 (5nm) built: 2022+ pcie: gen: 5 speed: 32 GT/s lanes: 8 link-max:
    lanes: 16 bus-ID: 01:00.0 chip-ID: 10de:2d04 class-ID: 0300
  Device-2: Advanced Micro Devices [AMD/ATI] Raphael vendor: ASUSTeK driver: amdgpu v: kernel
    arch: RDNA-2 code: Navi-2x process: TSMC n7 (7nm) built: 2020-22 pcie: gen: 4 speed: 16 GT/s
    lanes: 16 ports: active: none empty: DP-1, DP-2, HDMI-A-1, Writeback-1 bus-ID: 79:00.0
    chip-ID: 1002:164e class-ID: 0300 temp: 44.0 C
  Display: unspecified server: X.org v: 1.21.1.21 with: Xwayland v: 24.1.11 driver: X:
    loaded: modesetting unloaded: vesa failed: nvidia alternate: fbdev,nouveau,nv dri: radeonsi
    gpu: amdgpu tty: 253x63
  Monitor-1: Unknown-1 model: Samsung S34J55x serial: <filter> built: 2021 res: 3440x1440
    dpi: 110 gamma: 1.2 size: 797x333mm (31.38x13.11") diag: 864mm (34") modes: 1024x768
  API: EGL v: 1.5 hw: drv: amd radeonsi platforms: device: 0 drv: radeonsi device: 1 drv: swrast
    gbm: drv: radeonsi surfaceless: drv: radeonsi inactive: wayland,x11
  API: OpenGL v: 4.6 vendor: mesa v: 26.1.0 note: console (EGL sourced) renderer: AMD Ryzen 7
    7800X3D 8-Core Processor (radeonsi raphael_mendocino ACO DRM 3.64 6.19.5-1-default), llvmpipe
    (LLVM 22.1.4 256 bits)
  API: Vulkan v: 1.4.341 layers: 3 device: 0 type: cpu name: llvmpipe (LLVM 22.1.4 256 bits)
    driver: mesa llvmpipe v: 26.1.0 (LLVM 22.1.4) device-ID: 10005:0000 surfaces: N/A
  Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo de: kscreen-console,kscreen-doctor
    gpu: nvidia-smi wl: wayland-info x11: xdpyinfo, xprop, xrandr

I updated because I tried to run ardour and it repeatedly crashed when trying to setup a recording session - it worked fine earlier, but I havenā€™t used it for some time, so I thought updating is a good idea - so wrong :smiley:

Any best practice to get it working as good as possible now - if possible with latest packages other than kernel and nvidia? Not used to this kind of cherry pickingā€¦

467

Hiya. Currently video output on RTX 20 series and newer on 7.0.x kernels is unstable. I have described a workaround in this post. That will allow you to keep your system up to date until this issue is fixed. Iā€™m working on a fix and hopefully soon Iā€™ll be able report if it worked or not.

2 Likes
468

cool, thanks!
In the meantime I got some help from claude: went through snapshot reboots until one worked (my last 6.x kernel), made it a regular snapshot, rebooted, locked several kernel and nvidia packages and repeated zypper dup ā€¦ ongoing. If it doesnā€™t work Iā€™ll gladly get back to your long term kernel approach.

469

I think I may have found a workaround (at least working for me, 7.0.5-1-default, G07 595.71.05):
https://bugzilla.suse.com/show_bug.cgi?id=1263825#c107

initcall_blacklist=sysfb_init in the kernel cmdline may work as a workaround. Downside: no early display until nvidia-drm loads (GRUB and BIOS output are unaffected, only the kernel boot phase has no display).

3 Likes
470

Hiya. Glad itā€™s working for you. But please read comments on issue. Your test with voluntary preemption mode is invalid. Option gets recognised but ignored because kernel doesnā€™t support it. You can verify that in a system log. If you see Dynamic Preempt: unsupported mode: voluntary that means kernel ignored your request and reverted to full preemption mode.

471

Related? https://github.com/ublue-os/bazzite/commit/c6884ad9966d9f2381686797d64c6acf2363285b
Didnā€™t try this workaround but reading the issue it seems to be pretty similar

472

I tried it and it doesnā€™t change anything on my system, still same hang: https://bugzilla.suse.com/show_bug.cgi?id=1263825#c114

473

That only reinforces my theory about preemption. No amount of config and kernel parameter hacks will help if system scheduler decides to interrupt GPU initialisation process. And that is more likely to happen when there are a lot of processes running like during boot. All you can do is pray that scheduler will sequence processes correctly and wonā€™t preempt GPU initialisation.

P.S. Thatā€™s why things like disabling plymouth work. The fewer things running during GPU initialisation the less chance of it getting preempted.

1 Like
474

@Lioli7k you should run systemd-analyze plot > boot.svg so you can visualize the boot up of your system

1 Like
475

Ooo. Didnā€™t knew about that one. Thanks.

476

Setting

reliably boots my system with no problems though. ā€œNo efidrm, no handover, nvidia-drm initializes as the first and only DRM device. System boots and desktop works.ā€

Would be interesting if thatā€™s the case for others as well.

2 Likes
477

Tested setting fb.lockless_register_fb=1 just now. 3 boots. 0 successful initialisations. Screen remained black. journalctl confirms that option was applied. Gonna try your option too.

478

That sysfb_init blacklisting worked on my system.

I do think the preemption may be the issue. My system is old and there are only 4 cores and no smt so an increased chance of needing to preempt versus a system with 20 cores or whatever.

Changing that .config option though is a whole distro decision and not a simple fix for this. Turning off preemption will have performance impact, and increased latency, less responsiveness etc. Fwiw.

3 Likes
479

Alright, youā€™re onto something with this one. It works on my PC as well. 3 attempts and all worked well. But I still wonder if itā€™s caused by preemption. At the very least it nicely narrows it down.

3 Likes
480

Yes, seems initcall_blacklist=sysfb_init works for me as well - no black screen, no artefacts or instabilities later during work.

3 Likes