Here you force SDDM into starting Xorg by using “nomodeset” and nVidia modules are loaded when Xorg server is being started.
Nov 09 18:06:37 kimera.rozsas.eng.br sddm[1380]: Initializing...
Nov 09 18:06:37 kimera.rozsas.eng.br sddm[1380]: Starting...
Nov 09 18:06:37 kimera.rozsas.eng.br sddm[1380]: Logind interface found
Nov 09 18:06:37 kimera.rozsas.eng.br sddm[1380]: Adding new display on vt 7 ...
Nov 09 18:06:37 kimera.rozsas.eng.br sddm[1380]: Loading theme configuration from ""
Nov 09 18:06:37 kimera.rozsas.eng.br sddm[1380]: Display server starting...
Nov 09 18:06:37 kimera.rozsas.eng.br sddm[1380]: Running: /usr/bin/X -nolisten tcp -auth /run/sddm/{dd43b869-7924-4824-9d45-bc64eea6ffd4} -background none -noreset -displayfd 17 -seat seat0 vt7
Nov 09 18:06:37 kimera.rozsas.eng.br kernel: nvidia: loading out-of-tree module taints kernel.
Nov 09 18:06:37 kimera.rozsas.eng.br kernel: nvidia: module license 'NVIDIA' taints kernel.
without nomodeset, so I got the console insted X window system: SUSE Paste
And here no nVidia modules are present so SDDM waits for suitable graphical device before starting Xorg.
Nov 09 18:09:03 kimera.rozsas.eng.br sddm[1382]: Starting...
Nov 09 18:09:03 kimera.rozsas.eng.br sddm[1382]: Logind interface found
Nov 09 18:09:03 kimera.rozsas.eng.br systemd[1]: Started X Display Manager.
Nov 09 18:09:03 kimera.rozsas.eng.br systemd[1]: Reached target Graphical Interface.
So this is exactly the same problem as I suspected and the reason I asked you for udevadm info output. If you collected this output on clean system the problem had been obvious, but you collected output after nvidia modules had already been loaded, thus hiding it.
Provide full output of “modprobe -c”. This will show whether nvidia is blacklisted.
Bingo !
I greped /usr/lib/modprobe before for nouveau. Why I didn’t greped for nvidia too ? Goosh !
kimera:~ # grep -i nvidia /usr/lib/modprobe.d/*
/usr/lib/modprobe.d/09-nvidia-modprobe-bbswitch-G04.conf:blacklist nvidia
/usr/lib/modprobe.d/09-nvidia-modprobe-bbswitch-G04.conf:blacklist nvidia-drm
/usr/lib/modprobe.d/09-nvidia-modprobe-bbswitch-G04.conf:blacklist nvidia-modeset
/usr/lib/modprobe.d/09-nvidia-modprobe-bbswitch-G04.conf:options nvidia-drm modeset=1
/usr/lib/modprobe.d/09-nvidia-modprobe-pm-G05.conf:options nvidia NVreg_DynamicPowerManagement=0x01
/usr/lib/modprobe.d/50-blacklist.conf:blacklist nvidiafb
/usr/lib/modprobe.d/50-nvidia-default.conf:options nvidia NVreg_DeviceFileUID=0 NVreg_DeviceFileGID=482 NVreg_DeviceFileMode=0660
/usr/lib/modprobe.d/50-nvidia-default.conf:options nvidia-drm modeset=1
/usr/lib/modprobe.d/50-nvidia-default.conf:install nvidia PATH=$PATH:/bin:/usr/bin; if /sbin/modprobe --ignore-install nvidia; then if /sbin/modprobe nvidia_uvm; then if ! -c /dev/nvidia-uvm ]; then mknod -m 660 /dev/nvidia-uvm c $(cat /proc/devices | while read major device; do if "$device" == "nvidia-uvm" ]; then echo $major; break; fi ; done) 0; chown :video /dev/nvidia-uvm; fi; if ! -c /dev/nvidia-uvm-tools ]; then mknod -m 660 /dev/nvidia-uvm-tools c $(cat /proc/devices | while read major device; do if "$device" == "nvidia-uvm" ]; then echo $major; break; fi ; done) 1; chown :video /dev/nvidia-uvm-tools; fi; fi; if ! -c /dev/nvidiactl ]; then mknod -m 660 /dev/nvidiactl c 195 255; chown :video /dev/nvidiactl; fi; devid=-1; for dev in $(ls -d /sys/bus/pci/devices/*); do vendorid=$(cat $dev/vendor); if "$vendorid" == "0x10de" ]; then class=$(cat $dev/class); classid=${class%%00}; if "$classid" == "0x0300" -o "$classid" == "0x0302" ]; then devid=$((devid+1)); if ! -c /dev/nvidia${devid} ]; then mknod -m 660 /dev/nvidia${devid} c 195 ${devid}; chown :video /dev/nvidia${devid}; fi; fi; fi; done; /sbin/modprobe nvidia_drm; if ! -c /dev/nvidia-modeset ]; then mknod -m 660 /dev/nvidia-modeset c 195 254; chown :video /dev/nvidia-modeset; fi; fi
/usr/lib/modprobe.d/50-nvidia-default.conf.rpmsave:options nvidia NVreg_DeviceFileUID=0 NVreg_DeviceFileGID=482 NVreg_DeviceFileMode=0660
/usr/lib/modprobe.d/50-nvidia-default.conf.rpmsave:options nvidia-drm modeset=1
/usr/lib/modprobe.d/50-nvidia-default.conf.rpmsave:install nvidia PATH=$PATH:/bin:/usr/bin; if /sbin/modprobe --ignore-install nvidia; then if /sbin/modprobe nvidia_uvm; then if ! -c /dev/nvidia-uvm ]; then mknod -m 660 /dev/nvidia-uvm c $(cat /proc/devices | while read major device; do if "$device" == "nvidia-uvm" ]; then echo $major; break; fi ; done) 0; chown :video /dev/nvidia-uvm; fi; if ! -c /dev/nvidia-uvm-tools ]; then mknod -m 660 /dev/nvidia-uvm-tools c $(cat /proc/devices | while read major device; do if "$device" == "nvidia-uvm" ]; then echo $major; break; fi ; done) 1; chown :video /dev/nvidia-uvm-tools; fi; fi; if ! -c /dev/nvidiactl ]; then mknod -m 660 /dev/nvidiactl c 195 255; chown :video /dev/nvidiactl; fi; devid=-1; for dev in $(ls -d /sys/bus/pci/devices/*); do vendorid=$(cat $dev/vendor); if "$vendorid" == "0x10de" ]; then class=$(cat $dev/class); classid=${class%%00}; if "$classid" == "0x0300" -o "$classid" == "0x0302" ]; then devid=$((devid+1)); if ! -c /dev/nvidia${devid} ]; then mknod -m 660 /dev/nvidia${devid} c 195 ${devid}; chown :video /dev/nvidia${devid}; fi; fi; fi; done; /sbin/modprobe nvidia_drm; if ! -c /dev/nvidia-modeset ]; then mknod -m 660 /dev/nvidia-modeset c 195 254; chown :video /dev/nvidia-modeset; fi; fi
kimera:~ #
So, I am planning to remove all files that have bbswitch OR G04 in the filename.
In addition to that I am planning to remove /usr/lib/modprobe.d/50-blacklist.conf
Should I proceed ?
Do you have knowledge if /etc/modprobe.d is deprecated now ?
[quote]In addition to that I am planning to remove /usr/lib/modprobe.d/50-blacklist.conf
No. /usr/lib is for files installed by packages. If you remove it, it will come back with corresponding package update (which is inevitable in Tumbleweed).
They are orphaned files now. They pose no threat either since I don’t have the G04 version, only G05. Removed.
I’ve removed bbswitch package 1 or 2 days ago, since someone in this thread told me it is unused as I don’t have a laptop with Optimus hardware. Another leftover.
And instead of removing /usr/lib/modprobe.d/50-blacklist.conf I’ve edited and removed only the line that blacklisted the nvidiafb.
After that, I boot again, without nomodeset and the Login manager comes up automatically. Finally !
So, thank you all that help me to fix my system.
Question: Who blacklisted nvidiafb after all ? For sure it wasn’t me. I even had no knowledge of that /usr/lib/modprobe.d folder. For sure some package when I moved to 20211102.
This file belongs to suse-module-tools-16.0.13-1.1.x86_64, but I guess other packages may edit it, isn’t ?
And that folder /usr/lib/modprobe.d that overrides /etc/modprobe.d ? Anyone have an explanation about it ? It really deprecates /etc/modprobe.d ?
Anyway, I’m glad my system is back as before. I’m glad to learn a few new things and I am grateful for the help I received from all of you !
This community is awesome !
As I said, I have also not heard about /usr/lib/modprobe.d.
So I copied the blacklist file from there to /etc/modprobe.d/ and getting an warning on the next nvidia install, that 2 files are blacklisting.
So I deleted in /etc/modprobe.d/ the file.
As I already told you - this is file installed by package and it will be overwritten on next package update. It is not configuration file that is supposed to be edited by user. Besides, nvidiafb has absolutely nothing to do with your problem.
Who blacklisted nvidiafb after all ? For sure it wasn’t me.
This entry exists since at least 2009 and probably earlier.
So, after I restore the 2 files above to their original location and booting, I got the same behavior as before: text console if not passing “nomodeset” to kernel.
And removing the file 09-nvidia-modprobe-bbswitch-G04.conf and removing “blacklist nvidiafb” from “/usr/lib/modprobe.d/50-blacklist.conf”, the system boots to SSDM as expected.
So, how do you explain this ?!?!?!
I am available to dig more if you are interested.
You are right.
The line “blacklist nvidiafb” in file /usr/lib/modprobe.d/50-blacklist.conf has no effect. The system boots as expected.
On the other hand, the presence of file /usr/lib/modprobe.d/09-nvidia-modprobe-bbswitch-G04.conf cause the symptom I have experienced: no SSDM at boot time.
Why ? My system has is not a laptop with Optimus, neither I am using the G04 version of driver, but G05, since my hardware is a GeForce GTX 970 (rev a1)
Also I’ve removed all bbswitch related packages.
The file “/usr/lib/modprobe.d/09-nvidia-modprobe-bbswitch-G04.conf” is somehow a leftover .
**kimera:~ #** cp /tmp/modprobe.d/09-nvidia-modprobe-bbswitch-G04.conf /usr/lib/modprobe.d/
**kimera:~ #** rpm -qf /usr/lib/modprobe.d/09-nvidia-modprobe-bbswitch-G04.conf
file /usr/lib/modprobe.d/09-nvidia-modprobe-bbswitch-G04.conf is not owned by any package
Digging a bit I found the file “/usr/lib/modprobe.d/09-nvidia-modprobe-bbswitch-G04.conf” is part of a package named “suse-prime-*” which I don´t have.
So, looks like the name of file is not checked against the current system.
It is irrelevant if the file “/usr/lib/modprobe.d/09-nvidia-modprobe-bbswitch-G04.conf” has bbswitch and G04 in the name, it will take in anyway , only the contents of file that matter, which make sense after all.
So, all of this was caused by an obsolete file that come from who knows ? I’ve upgraded my nvidia card more than 1 year ago. I don’t remember which was the previous card, but there is a chance it used a G04 version of driver and may be I had installed that suse-prime package by mistake, realized the error, removed it and somehow the file was there not causing harm until the update at beginning of this month.
If not a Optimus machine you should not have bumblebee or suse-prime or any other Optimus management type files those are only for Optimus laptops.Have no idea why you have them on your machine they are not installed by default.
I guess this is one of a few cases when the installation of a package can harm your system, not permanently, of course, but it will break something else and it is difficult to debug.
Anyway, I’m glad everything is back to normal and I have a reasonable explanation what was wrong, thanks to the help from the dear fellows.
More than one year ago…
The removal, uninstall date it doesn’t log…It will be interesting to see how long that package was in my system.
TIL I can review the output of post script looking at zypper history. Nice !
Well, you again ignored half of my question and provided output of one command only. Why do you think I posted two lines?
The removal, uninstall date it doesn’t log…
Zypper (assuming “it” referred to zypper) most certainly logs removal if you use zypper (or in general any tool based on libzypp) to remove packages. But you did not even search the current log file, how can you know whether anything is logged or not?
If you use rpm command directly it won’t be logged (if sudo was used its invocation is logged but may already be deleted and there could be audit logs, but I am not familiar with them).