error on install of nvidia-gfxG05-kmp-default

The posttrans script failed during the installation of nvidia-gfxG05-kmp-default-470.82.00_k5.14.11_2-45.1.x86_64.rpm

zypper install -f nvidia-gfxG05-kmp-default    
Loading repository data...
Reading installed packages...
Forcing installation of 'nvidia-gfxG05-kmp-default-470.82.00_k5.14.11_2-45.1.x86_64' from repository 'nvidia-tumbleweed'.
Resolving package dependencies...

The following package is going to be reinstalled:
  nvidia-gfxG05-kmp-default
...
 libkmod: kmod_module_parse_depline: ctx=0x55a6fa5707b0 path=/lib/modules/4.12.14-lp150.11-default//updates/nvidia-modeset.ko error=No such file or directory
...

Looks like it is in another path

**kimera:~ #** find -L /lib -type f -iname nvidia-modeset.ko     
/lib/modules/5.14.14-1-default/updates/nvidia-modeset.ko
**kimera:~ #**

Why the post script is trying to use a module from 4.12.14-lp150.11-default ??!!? The current kernel version is 5.14.14-1-default

**kimera:~ #** uname -r
5.14.14-1-default

What is the best way to fix this ? This is acceptable ?

**kimera:/lib/modules/4.12.14-lp150.11-default #** ln -s ../5.14.14-1-default/updates/ .

Should I open an issue at opensuse bug tracker or there is something wrong in my system ?

You did not show any evidence of it. You posted single error message without context; there is no way to even start guessing where it failed. Post full log if you really want to find the reason.

What is the best way to fix this ? This is acceptable ?

**kimera:/lib/modules/4.12.14-lp150.11-default #** ln -s ../5.14.14-1-default/updates/ .

Of course not. Module built for kernel 5.14.14 cannot be compatible with kernel 4.12.14.

Should I open an issue at opensuse bug tracker

Why do you have kernel of Leap 15.0 in Tumbleweed installation in the first place?

Post output of “rpm -qa kernel-* nvidia-*” and full log of “zypper in -f nvidia-gfxG05-kmp-default”.

turns out the folder “/lib/modules/4.12.14-lp150.11-default” was a leftover that I can not explain or I can not recall why.
My system is up and running for a few years, so, who knows.
Anyway, “rpm -qf /lib/modules/4.12.14-lp150.11-default/*” returns “file whatever is not owned by any package” for every single file in that folder.
After removing the folder and forcing the re-install of nvidia-gfxG05-kmp-default the initrd was created and the installation ended with no errrors.

But…

After the reboot, the X didn’t started as expected. I mean, it not started at all, since there is no log file.
I zeroed (cp /dev/null ) the file “/var/log/Xorg.0.log” an reboot and after the system boot, i logged in as root at console (no X) and verified the file size is still zero.
At that point, “lsmod | grep -i nvidia” returned nothing, and


kimera:~ # ls -l /var/log/Xorg.0.log
-rw-r--r-- 1 root root 0 Nov  6 17:24 /var/log/Xorg.0.log
kimera:~ # lsmod | grep -i nvidia
kimera:~ # lsinitrd | grep -i nvidia
-rw-r--r--   1 root     root          129 Oct 20 15:44 usr/lib/modprobe.d/09-nvidia-modprobe-bbswitch-G04.conf
-rw-r--r--   1 root     root           49 Oct 20 15:44 usr/lib/modprobe.d/09-nvidia-modprobe-pm-G05.conf
-rw-r--r--   1 root     root         1513 Oct 20 15:44 usr/lib/modprobe.d/50-nvidia-default.conf
-rw-r--r--   1 root     root           18 Oct 20 15:44 usr/lib/modprobe.d/nvidia-default.conf
kimera:~ # lspci | grep -i nvidia
01:00.0 VGA compatible controller: NVIDIA Corporation GM204 [GeForce GTX 970] (rev a1)
kimera:~ # systemctl get-default  
graphical.target
kimera:~ #

However if I reboot and add “nomodeset” to kernel cmd line, then the X come in as expected, showing the login manager to the user log in.
This is strange. It didn’t needed “nomodeset” to boot before. Why it needs now to X start ?
Wait ! It comes even more strange…

Then I reboot again, (zeroing the /var/log/Xorg.0.log as before) this time without modeset, and as before, the system reached the graphical target but no X running, no output in /var/log/Xorg.0.log.
Then I log in as root in console and run “startx” and the X comes in, presenting to me the root DE (KDE) completely functional, but with a twist: It is running on virtual console 1 and not 7 as one expect.
In fact if I switch to virtual desktop 7 (CTRL+ALT+F7) I found the login manager, ready to a normal user logs in. I log in as my normal user and again, everything looks right.
Then I switch to virtual desktop 1 (remember, where the root’s DE was running) just to see it closing and returning to the text console. Back to virtual console 7 and everything is still there.

Summary:

  1. Without nomodeset the system boots to graphical target but no X, not even errors or output on /var/log/Xorg.0.log.
    1a) At this point, root can start X, the root’s DE is loaded on vt1 and the graphical login manager on vt7; switching to vt1 closes the root’s DE, and return to console.

  2. Booting with nomodeset, the system boots as expected, except that nomodeset is unexpected.

I’ve preserved the X log in this 2 situations, and compare it using diff (I had to remove the time index at beginning of every line to this work):
The file tmp/Xorg_nomodeset_absent.log refers to situation 1 above; the other to situation 2:


miguel $ diff tmp/Xorg_nomodeset_absent.log tmp/Xorg_nomodeset_present.log  
1c1
< ] (--) Log file renamed from "/var/log/Xorg.pid-1384.log" to "/var/log/Xorg.0.log"
---
> ] (--) Log file renamed from "/var/log/Xorg.pid-1385.log" to "/var/log/Xorg.0.log"
16c16
< ] (==) Log file: "/var/log/Xorg.0.log", Time: Sat Nov  6 18:15:46 2021
---
> ] (==) Log file: "/var/log/Xorg.0.log", Time: Sat Nov  6 18:20:13 2021
46c46
< ] (II) Loader magic: 0x562468dbea00
---
> ] (II) Loader magic: 0x56210ef91a00
501,511d500
< ] (II) UnloadModule: "libinput"
< ] (II) UnloadModule: "libinput"
< ] (II) UnloadModule: "libinput"
< ] (II) UnloadModule: "libinput"
< ] (II) UnloadModule: "libinput"
< ] (II) UnloadModule: "libinput"
< ] (II) UnloadModule: "libinput"
< ] (II) UnloadModule: "libinput"
< ] (II) UnloadModule: "libinput"
< ] (II) NVIDIA(GPU-0): Deleting GPU-0
< ] (II) Server terminated successfully (0). Closing log file.
 miguel $

Another experiment I did: Booting on level 3 without nomodeset; got the text console as expected; log in as root and switch to graphical target (systemctl isolate graphical.target). The system reaches the graphical target but no X. No logs on Xorg.0.log either. Inconclusive. It is the same as situation 1, with an extra step.

I really dodn’t know what is going on here.

This started when I upgraded my system from 20211029 to 20211102 as I described in this related post https://forums.opensuse.org/showthread.php/561947-X-does-not-start-automatically
And yes, I always use “zypper dist-upgrade”.

I appreciate any comments that shed light on this mystery.

Nomodeset forces the running of a fallback driver NOT NVIDIA driver.

You must determine why the NVIDIA driver fails. Exactly what hardware?? is this an Optimus laptop???

What Display Manager are you using?

Provide output of “udevadm info --export-db” (upload to http://susepaste.org/)

Post:

zypper se -si kernel nvidia

Post:

grep -i 'blacklist nouveau' /etc/modprobe.d/*
grep -i 'blacklist nouveau' /usr/lib/modprobe.d/*

@Sauerland:

kimera:~ # zypper se -si kernel nvidia
Loading repository data...
Reading installed packages...


S  | Name                        | Type    | Version                   | Arch   | Repository
---+-----------------------------+---------+---------------------------+--------+------------------
i+ | kernel-default              | package | 5.14.11-1.2               | x86_64 | (System Packages)
i+ | kernel-default              | package | 5.14.14-1.1               | x86_64 | Tumbleweed-OSS
i+ | kernel-default-devel        | package | 5.14.11-1.2               | x86_64 | (System Packages)
i+ | kernel-default-devel        | package | 5.14.14-1.1               | x86_64 | Tumbleweed-OSS
i  | kernel-devel                | package | 5.14.11-1.2               | noarch | (System Packages)
i  | kernel-devel                | package | 5.14.14-1.1               | noarch | Tumbleweed-OSS
i+ | kernel-firmware-amdgpu      | package | 20211027-1.1              | noarch | Tumbleweed-OSS
i+ | kernel-firmware-ath10k      | package | 20211027-1.1              | noarch | Tumbleweed-OSS
i  | kernel-firmware-ath11k      | package | 20211027-1.1              | noarch | Tumbleweed-OSS
i+ | kernel-firmware-atheros     | package | 20211027-1.1              | noarch | Tumbleweed-OSS
i+ | kernel-firmware-bluetooth   | package | 20211027-1.1              | noarch | Tumbleweed-OSS
i+ | kernel-firmware-bnx2        | package | 20211027-1.1              | noarch | Tumbleweed-OSS
i+ | kernel-firmware-brcm        | package | 20211027-1.1              | noarch | Tumbleweed-OSS
i+ | kernel-firmware-chelsio     | package | 20211027-1.1              | noarch | Tumbleweed-OSS
i+ | kernel-firmware-dpaa2       | package | 20211027-1.1              | noarch | Tumbleweed-OSS
i+ | kernel-firmware-i915        | package | 20211027-1.1              | noarch | Tumbleweed-OSS
i+ | kernel-firmware-intel       | package | 20211027-1.1              | noarch | Tumbleweed-OSS
i+ | kernel-firmware-iwlwifi     | package | 20211027-1.1              | noarch | Tumbleweed-OSS
i+ | kernel-firmware-liquidio    | package | 20211027-1.1              | noarch | Tumbleweed-OSS
i+ | kernel-firmware-marvell     | package | 20211027-1.1              | noarch | Tumbleweed-OSS
i+ | kernel-firmware-media       | package | 20211027-1.1              | noarch | Tumbleweed-OSS
i+ | kernel-firmware-mediatek    | package | 20211027-1.1              | noarch | Tumbleweed-OSS
i+ | kernel-firmware-mellanox    | package | 20211027-1.1              | noarch | Tumbleweed-OSS
i+ | kernel-firmware-mwifiex     | package | 20211027-1.1              | noarch | Tumbleweed-OSS
i+ | kernel-firmware-network     | package | 20211027-1.1              | noarch | Tumbleweed-OSS
i+ | kernel-firmware-nfp         | package | 20211027-1.1              | noarch | Tumbleweed-OSS
i+ | kernel-firmware-platform    | package | 20211027-1.1              | noarch | Tumbleweed-OSS
i  | kernel-firmware-prestera    | package | 20211027-1.1              | noarch | Tumbleweed-OSS
i  | kernel-firmware-qcom        | package | 20211027-1.1              | noarch | Tumbleweed-OSS
i+ | kernel-firmware-qlogic      | package | 20211027-1.1              | noarch | Tumbleweed-OSS
i+ | kernel-firmware-radeon      | package | 20211027-1.1              | noarch | Tumbleweed-OSS
i+ | kernel-firmware-realtek     | package | 20211027-1.1              | noarch | Tumbleweed-OSS
i+ | kernel-firmware-serial      | package | 20211027-1.1              | noarch | Tumbleweed-OSS
i+ | kernel-firmware-sound       | package | 20211027-1.1              | noarch | Tumbleweed-OSS
i+ | kernel-firmware-ti          | package | 20211027-1.1              | noarch | Tumbleweed-OSS
i+ | kernel-firmware-ueagle      | package | 20211027-1.1              | noarch | Tumbleweed-OSS
i+ | kernel-firmware-usb-network | package | 20211027-1.1              | noarch | Tumbleweed-OSS
i  | kernel-macros               | package | 5.14.14-1.1               | noarch | Tumbleweed-OSS
i+ | libnvidia-egl-wayland1      | package | 1.1.7-3.1                 | x86_64 | Tumbleweed-OSS
i+ | nvidia-computeG05           | package | 470.82.00-45.1            | x86_64 | nvidia-tumbleweed
i+ | nvidia-gfxG05-kmp-default   | package | 470.82.00_k5.14.11_2-45.1 | x86_64 | nvidia-tumbleweed
i+ | nvidia-glG05                | package | 470.82.00-45.1            | x86_64 | nvidia-tumbleweed
i  | purge-kernels-service       | package | 0-8.2                     | noarch | Tumbleweed-OSS
i  | python38-ipykernel          | package | 6.4.1-1.1                 | noarch | Tumbleweed-OSS
i+ | x11-video-nvidiaG05         | package | 470.82.00-45.1            | x86_64 | nvidia-tumbleweed
kimera:~ # grep -i 'blacklist nouveau' /etc/modprobe.d/*
kimera:~ # grep -i 'blacklist nouveau' /usr/lib/modprobe.d/*
/usr/lib/modprobe.d/09-nvidia-modprobe-bbswitch-G04.conf:blacklist nouveau
/usr/lib/modprobe.d/nvidia-default.conf:blacklist nouveau
kimera:~ # 

bbswitch ? It is new to me…

According to “systemctl status display-manager” I am using the KDE default, SSDM.
The output of udevadm: SUSE Paste

I am not sure about that, because after X started, passing nomodeset to kernel, “lsmod | grep -i nvidia” shows several nvidia modules. Check my port to details. It is there !

It is no fail at all ! Did you saw the test I did zeroing the X log file before it runs ? The Xorg.0.log is empty ! In fact it was not started !
I zeroed it because at first I was confused with the content, until I realize the content I was seeing is from previous successful run. So just for peace of heart, I zeroed it to be sure any new content comes from that run.

It is a desktop. Output of KDE info center:


Operating System: openSUSE Tumbleweed 20211102
KDE Plasma Version: 5.23.2
KDE Frameworks Version: 5.87.0
Qt Version: 5.15.2
Kernel Version: 5.14.14-1-default (64-bit)
Graphics Platform: X11
Processors: 8 × Intel® Core™ i7-3770 CPU @ 3.40GHz
Memory: 15.6 GiB of RAM
Graphics Processor: NVIDIA GeForce GTX 970/PCIe/SSE2

I do not know, if /usr/lib/modprobe.d do the same job as /etc/modprobe.d…

But I have seen on my Computer, that there is no blacklist file in /etc/modprobe.d anymore, but I can not remind me to delete a file…

So I have copied it from /usr/lib/modprobe.d to /etc/modprobe.d

nomodeset is normally not used anymore because of optimus graphics (Intel-Nvidia), Intel needs modesetting

What graphics is inside:

/sbin/lspci -nnk | grep -EiA3 'display|3d|vga'

Is bbswitch installed:

zypper se -si bbswitch

I have no knowledge of the second modprobe.d folder ! This is new for me. Even so, it is there for my surprise.
Can you comment about the second one, please ?

I have no knowledge of the second modprobe.d folder ! This is new for me. Even so, it is there for my surprise.
Can you comment about the second one, please ?

This was also new for me, see my last thread.

Sorry, you asked for display manager and I answered with login manager.
Anyway, it is KDE default, Kwin, although I don’t know how to verify this on cmd line.

Good to know…


**kimera:~ #** /sbin/lspci -nnk | grep -EiA3 'display|3d|vga'
01:00.0 **VGA** compatible controller [0300]: NVIDIA Corporation GM204 [GeForce GTX 970] [10de:13c2] (rev a1)
        Subsystem: Gigabyte Technology Co., Ltd Device [1458:3684]
        Kernel driver in use: nvidia
        Kernel modules: nouveau, nvidia_drm, nvidia
**kimera:~ #** zypper se -si bbswitch
Loading repository data...
Reading installed packages...

S | Name                 | Type    | Version              | Arch   | Repository
--+----------------------+---------+----------------------+--------+------------------
i | bbswitch             | package | 0.8-11.38            | x86_64 | Tumbleweed-OSS
i | bbswitch-kmp-default | package | 0.8_k5.14.11_1-11.35 | x86_64 | (System Packages)
i | bbswitch-kmp-default | package | 0.8_k5.14.14_1-11.38 | x86_64 | Tumbleweed-OSS
**kimera:~ #**


BTW, I got the same lspci output with or without nomodeset , even in the last I have to start X manually as I described before. So nvidia module is loaded in both situations. The complete Xorg.0.log show the same too.

So why bbswitch?

LANG=C zypper if bbswitch
Loading repository data...
Reading installed packages...


Information for package bbswitch:
---------------------------------
Repository     : OSS
Name           : bbswitch
Version        : 0.8-lp153.2.8
Arch           : x86_64
Vendor         : openSUSE
Installed Size : 25,7 KiB
Installed      : No
Status         : not installed
Source package : bbswitch-0.8-lp153.2.8.src
Summary        : Bumblebee ACPI kernel module
Description    : 
    bbswitch is a kernel module which automatically detects the required
    ACPI calls for two kinds of Optimus laptops.

Not needed, delete it.

OK. Done. I remember it was installed recently, I mean 1-2 months ago… I guess the zypper recommended packages installed it ?

All bbswitch packages and restart?
There are kernel module packages kmps…

Yes, all of them.
Not changes after all.
Reboot, nomodeset is NOT present in kernel cmd line, system give me the console.
Log in as root, startx, switch to vt7, log in as normal user.

That looks OK. nvidia gets master-of-seat tag so should not delay graphical session.

Do you use automatic login? Is it possible that KDE starts Wayland session?

Please provide full output of “journalctl -b” as root immediately after boot, before you start anything.

No, I don’t use auto login. The session is X not Wayland, I can see that on login manager running on vt7. see below.

I generate 3 outputs of journalctl as requested.

  1. with nomodeset in kernel params, so the X starts automatically: SUSE Paste
  2. without nomodeset, so I got the console insted X window system: SUSE Paste
  3. the same as 2, then I run “startx”: SUSE Paste

Note about 3: I ran “startx” at vt1, X starts at vt1, I switch to vt7 and I see the login manager ready to log in an user, then I switch back to vt1 and see the X closing on vt1, then I run journalctl. The X on vt7 is still running and completely funcional.