Tumbleweed dup 10 Oct 2020, lost GUI with nouveau (works with nomodeset)

English Install/Boot/Login
1

Dear All,

yesterday, the 10th of October 2020 upgraded my Tumbleweed installation and unfortunately “lost” my GUI…
A 2017 HP OMEN 15 laptop with an i7 and an NVidia GTX 1060 Max-Q, without any secondary graphics. Effectively, nouveau as a graphics driver has been working well since about the end of October 2017.

Immediately after the upgrade, I had Kernels 5.8.14(.1 I think) and 5.8.12 - neither worked, nor did recovery mode.
I tried 5.8.14.2 from kernel stable, same problem…
nomodeset works - so I can access everything on the computer with certain limitations.

The computer will boot up with the (usual) ACPI complaints and then hang. With nouveau.modeset=0 I will get a bluetooth complaint and then the command line enabling me to log in without a GUI.
As mentioned, nomodeset gives me the GUI.

If you can provide sufficiently explicit instructions on how to obtain pertinent logfiles, I will be happy to attempt to extract them for you.
As a side note, it seems that an AMD user had a similar issue here: https://forums.opensuse.org/showthread.php/545773-AMDGPU-failure-after-zypper-dup-today

2

I ran into a similar problem with amdgpu. I rolled back to snapshot 20201007, locked the firmware and installed again snapshot 20201008.

3

Thank you.
For this I shall follow the explanation of the system in this thread I guess:
https://forums.opensuse.org/showthread.php/535256-Tumbleweed-snapshots-usage-notes

-> I shall see how it works out and if it works.
(Not having much luck to get it to switch to a snapshot, I just stay on the current version, but that must be me…)

4

OK, quick update:

It is good to disable the update repository :smiley: - no wonder I couldn’t “upgrade” to the older packages.

Without the update repository I could revert to the older snapshot and all works, so the solution proposed worked :).
Once again thank you very much.

5

It is usually NOT a good idea to disable the Tumbleweed update repo. It is used for emergency updates to fix problems.

Just checking that repo, I see several test updates which are not installed here and don’t do anything anyway except for testing. The only other package I see there is “enigmail”.

6

Thanks for the nomodeset suggestion. This allowed me to boot up at low resolution, install NVIDIA 450.66 proprietary driver, reboot, and then back up to full resolution. When whatever cause of this problem gets fixed, I’ll go back to uninstalled NVIDIA driver. At least today I can use my system.

7

Hi
The kernel update is the cause, waiting for the repositories to be updated,. One of the reasons I stick with the hard way… plus at 455.23.04 driver… :wink:

8

100% FOSS is working fine for me without disabling KMS:

# rpm -qa | grep xf86-v
xf86-video-fbdev-0.5.0-1.10.x86_64
xf86-video-vesa-2.5.0-1.1.x86_64
# inxi -SGIay
System:
  Host: p5bse **Kernel: 5.8.14-1-default** x86_64 bits: 64 compiler: gcc v: 10.2.1
  parameters: noresume mitigations=auto consoleblank=0 vga=791 video=1440x900@60 5
  Desktop: KDE Plasma 5.19.5 tk: Qt 5.15.1 **wm: kwin_x11 dm: SDDM**
  Distro: openSUSE **Tumbleweed 20201009**
Graphics:
  Device-1: **NVIDIA** GF119 [NVS 310] vendor: Hewlett-Packard driver: nouveau
  v: kernel bus ID: 01:00.0 chip ID: 10de:107d
  Display: **x11 server: X.Org 1.20.9** compositor: kwin_x11 **driver: modesetting**
  unloaded: fbdev,vesa **alternate: nouveau**,nv,nvidia display ID: :0 screens: 1
  Screen-1: 0 s-res: **2560x2520** s-dpi: 120 s-size: 541x533mm (21.3x21.0")
  s-diag: 759mm (29.9")
  Monitor-1: DP-1 res: 2560x1440 hz: 60 dpi: 109 size: 598x336mm (23.5x13.2")
  diag: 686mm (27")
  Monitor-2: DP-2 res: 2560x1080 hz: 60 dpi: 97 size: 673x284mm (26.5x11.2")
  diag: 730mm (28.8")
  OpenGL: renderer: llvmpipe (LLVM 10.0.1 128 bits) v: 3.3 Mesa 20.1.8
  compat-v: 3.1 direct render: Yes
Info:...running in: konsole inxi: 3.1.07

You can see I’m not using the optional (not installed) nouveau DDX](https://en.wikipedia.org/wiki/Device_Dependent_X), but the upstream default. Maybe yours would have been fine with the more modern default DDX driver doesn’t have the dependence on reverse engineering that the nouveau DDX does.

9

Great info. I’ll have to look into how to do it after this glitch.

10

I’ve installed today’s kernel-firmware packages using zypper dup and uninstalled proprietary NVIDIA drivers. My system appears to be back to the normal working state of 8 October 2020.


inxi -SGIa # as regular user
**System:    Host:** XXXXX **Kernel:** 5.8.14-1-default x86_64 **bits:** 64 **compiler:** N/A  
           **parameters:** BOOT_IMAGE=/boot/vmlinuz-5.8.14-1-default root=UUID=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX splash=silent  
           resume=/dev/disk/by-id/ata-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX-part2 mitigations=auto quiet  
           **Desktop:** KDE Plasma 5.19.5 **tk:** Qt 5.15.1 **wm:** kwin_x11 **dm:** SDDM **Distro:** openSUSE Tumbleweed 20201012  
**Graphics:  Device-1:** NVIDIA GM204 [GeForce GTX 970] **vendor:** Gigabyte **driver:** nouveau **v:** kernel **bus ID:** 04:00.0  
           **chip ID:** 10de:13c2  
           **Display:** x11 **server:** X.Org 1.20.9 **compositor:** kwin_x11 **driver:** nouveau **unloaded:** fbdev,modesetting,vesa  
           **alternate:** nv,nvidia **display ID:** :0 **screens:** 1  
           **Screen-1:** 0 **s-res:** 2560x1440 **s-dpi:** 96 **s-size:** 677x381mm (26.7x15.0") **s-diag:** 777mm (30.6")  
           **Monitor-1:** DVI-I-1 **res:** 2560x1440 **hz:** 60 **dpi:** 92 **size:** 708x398mm (27.9x15.7") **diag:** 812mm (32")  
           **OpenGL:****renderer:** NV124 **v:** 4.3 Mesa 20.1.8 **direct render:** Yes  
**Info:      Processes:** 337 **Uptime:** N/A **Memory:** 15.55 GiB **used:** 1.97 GiB (12.6%) **Init:** systemd **v:** 246 **runlevel:** 5  
           **target:** graphical.target **Compilers:****gcc:** 10.2.1 **alt:** 10 **Shell:** bash **v:** 5.0.18 **running in:** konsole **inxi:** 3.1.00 



rpm -qa|grep kernel-firmware
**kernel-firmware**-realtek-20201005-3.1.noarch
**kernel-firmware**-ueagle-20201005-3.1.noarch
**kernel-firmware**-ti-20201005-3.1.noarch
**kernel-firmware**-sound-20201005-3.1.noarch
**kernel-firmware**-qlogic-20201005-3.1.noarch
**kernel-firmware**-radeon-20201005-3.1.noarch
**kernel-firmware**-platform-20201005-3.1.noarch
**kernel-firmware**-network-20201005-3.1.noarch
**kernel-firmware**-nvidia-20201005-3.1.noarch
**kernel-firmware**-media-20201005-3.1.noarch
**kernel-firmware**-mwifiex-20201005-3.1.noarch
**kernel-firmware**-mellanox-20201005-3.1.noarch
**kernel-firmware**-mediatek-20201005-3.1.noarch
**kernel-firmware**-marvell-20201005-3.1.noarch
**kernel-firmware**-prestera-20201005-3.1.noarch
**kernel-firmware**-iwlwifi-20201005-3.1.noarch
**kernel-firmware**-liquidio-20201005-3.1.noarch
**kernel-firmware**-intel-20201005-3.1.noarch
**kernel-firmware**-bnx2-20201005-3.1.noarch
**kernel-firmware**-dpaa2-20201005-3.1.noarch
**kernel-firmware**-brcm-20201005-3.1.noarch
**kernel-firmware**-ath10k-20201005-3.1.noarch
**kernel-firmware**-amdgpu-20201005-3.1.noarch
**kernel-firmware**-atheros-20201005-3.1.noarch
**kernel-firmware**-bluetooth-20201005-3.1.noarch
**kernel-firmware**-chelsio-20201005-3.1.noarch
**kernel-firmware**-i915-20201005-3.1.noarch
**kernel-firmware**-nfp-20201005-3.1.noarch
**kernel-firmware**-usb-network-20201005-3.1.noarch
**kernel-firmware**-serial-20201005-3.1.noarch
**kernel-firmware**-all-20201005-3.1.noarch



rpm -qa|grep xf86-v
**xf86-v**ideo-nouveau-1.0.16-1.2.x86_64
**xf86-v**ideo-vesa-2.5.0-1.1.x86_64
**xf86-v**ideo-fbdev-0.5.0-1.10.x86_64

After all the troubles since 8 October 2020, I wonder if the ssh-add line that I originally uncommented in my ~/.xinitrc had contributed to my problems. I won’t ever know now. It currently remains commented out. I will have to invoke ssh-add manually each time I log in so that emacs-x11 and magit won’t complain whenever I push to an ssh git repository.