My boot log is very long, so I will paste here only the most relevant parts of it.
I am not sure, but it seems that the wrong nvidia driver rules which start early at boot create display problems with plain shell.
Please let me know if I should search for something more specific.
gen 18 20:05:36 Sharky systemd-udevd[680]: Reading rules file: /usr/lib/udev/rules.d/60-nvidia.rules
gen 18 20:05:36 Sharky systemd-udevd[680]: /usr/lib/udev/rules.d/60-nvidia.rules:2 Invalid value "/usr/bin/bash -c '/usr/bin/mknod -Z -m 666 /dev/nvidiactl c $(grep nvidia-frontend /proc/devices | cut -d \ -f 1) 255'" for RUN (char 61: invalid substitution type), ignoring.
gen 18 20:05:36 Sharky systemd-udevd[680]: /usr/lib/udev/rules.d/60-nvidia.rules:3 Invalid value "/usr/bin/bash -c 'for i in $(cat /proc/driver/nvidia/gpus/*/information | grep Minor | cut -d \ -f 4); do /usr/bin/mknod -Z -m 666 /dev/nvidia${i} c $(grep nvidia-frontend /proc/devices | cut -d \ -f 1) ${i}; done'" for RUN (char 28: invalid substitution type), ignoring.
gen 18 20:05:36 Sharky systemd-udevd[680]: /usr/lib/udev/rules.d/60-nvidia.rules:4 Invalid value "/usr/bin/bash -c '/usr/bin/mknod -Z -m 666 /dev/nvidia-modeset c $(grep nvidia-frontend /proc/devices | cut -d \ -f 1) 254'" for RUN (char 66: invalid substitution type), ignoring.
gen 18 20:05:36 Sharky systemd-udevd[680]: /usr/lib/udev/rules.d/60-nvidia.rules:5 Invalid value "/usr/bin/bash -c '/usr/bin/mknod -Z -m 666 /dev/nvidia-uvm c $(grep nvidia-uvm /proc/devices | cut -d \ -f 1) 0'" for RUN (char 62: invalid substitution type), ignoring.
gen 18 20:05:36 Sharky systemd-udevd[680]: /usr/lib/udev/rules.d/60-nvidia.rules:6 Invalid value "/usr/bin/bash -c '/usr/bin/mknod -Z -m 666 /dev/nvidia-uvm-tools c $(grep nvidia-uvm /proc/devices | cut -d \ -f 1) 1'" for RUN (char 68: invalid substitution type), ignoring.
[...]
gen 18 20:05:37 Sharky systemd-logind[766]: VT changed to 1
gen 18 20:05:37 Sharky sddm[809]: Failed to read display number from pipe
gen 18 20:05:37 Sharky sddm[809]: Attempt 1 starting the Display server on vt 2 failed
[...]
gen 18 20:05:39 Sharky systemd-logind[766]: VT changed to 2
gen 18 20:05:39 Sharky systemd-logind[766]: VT changed to 1
gen 18 20:05:39 Sharky sddm[809]: Failed to read display number from pipe
gen 18 20:05:39 Sharky sddm[809]: Attempt 2 starting the Display server on vt 2 failed
[...]
gen 18 20:05:42 Sharky systemd-logind[766]: VT changed to 1
gen 18 20:05:42 Sharky sddm[809]: Failed to read display number from pipe
gen 18 20:05:42 Sharky sddm[809]: Attempt 3 starting the Display server on vt 2 failed
gen 18 20:05:42 Sharky sddm[809]: Could not start Display server on vt 2
This is just a guess, but maybe worth a try. If you go into edit mode in grub2 menu (press e), and change nvidia-drm.modeset=1 to 0 and see if it boots into a tty?
I donāt have ānvidia-drm.modesetā in my grub2 menu; only ārd.driver.blacklist=nouveauā is there.
I deleted that part in console mode and booted. System logs showed something different (the other log was from recovery mode). Looks like my system regularly loaded nvidia drivers and no display issues were reported, but I couldnāt use any shell anyway.
gen 19 10:53:42 Sharky kernel: nvidia: loading out-of-tree module taints kernel.
gen 19 10:53:42 Sharky kernel: nvidia: module license 'NVIDIA' taints kernel.
gen 19 10:53:42 Sharky kernel: Disabling lock debugging due to kernel taint
gen 19 10:53:42 Sharky kernel: nvidia: module verification failed: signature and/or required key missing - tainting kernel
gen 19 10:53:42 Sharky kernel: nvidia-nvlink: Nvlink Core is being initialized, major device number 241
gen 19 10:53:42 Sharky kernel:
gen 19 10:53:42 Sharky kernel: nvidia 0000:01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=io+mem
[...]
gen 19 10:53:42 Sharky kernel: NVRM: loading NVIDIA UNIX x86_64 Kernel Module 525.78.01 Mon Dec 26 05:58:42 UTC 2022
gen 19 10:53:42 Sharky systemd-udevd[691]: event19: Failed to call EVIOCSKEYCODE with scan code 0x7c, and key code 190: Invalid argument
gen 19 10:53:42 Sharky kernel: nvidia_modeset: no symbol version for nvidia_register_module
gen 19 10:53:42 Sharky kernel: nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 525.78.01 Mon Dec 26 05:38:56 UTC 2022
[...]
gen 19 10:53:43 Sharky systemd[1]: Starting systemd-user-sessions.service - Permit User Sessions...
gen 19 10:53:43 Sharky systemd[1]: Starting systemd-hostnamed.service - Hostname Service...
gen 19 10:53:43 Sharky systemd[1]: Finished systemd-user-sessions.service - Permit User Sessions.
gen 19 10:53:43 Sharky systemd[1]: Starting plymouth-quit-wait.service - Hold until boot process finishes up...
gen 19 10:53:43 Sharky systemd[1]: Starting plymouth-quit.service - Terminate Plymouth Boot Screen...
gen 19 10:53:43 Sharky systemd[1]: Finished plymouth-quit-wait.service - Hold until boot process finishes up.
gen 19 10:53:43 Sharky systemd[1]: Started getty@tty1.service - Getty on tty1.
gen 19 10:53:43 Sharky systemd[1]: Reached target getty.target - Login Prompts.
gen 19 10:53:43 Sharky systemd[1]: Finished plymouth-quit.service - Terminate Plymouth Boot Screen.
Hmmmā¦ Thatās odd, as I have nvidia-drm.modeset=1 in my grub entries, and I thought that was added when installing the dkms drivers, but maybe I added that line myself as I know itās needed in Hybrid gfx situations.
I also have rd.driver.blacklist=nouveau as without that, Iāll either not boot correctly, or the system will freeze shortly after.
Just to let all know that the issue I reported has been solved with the latest kernel updates.
Currently I am running the kernel 6.3.5-desktop-3omv2390 and my system wakes up regularly from suspend mode.
Reviving an old thread, but it looked like the most relevant to my question.
So if I understand this right, the newest Nvidia drivers are completely reliant on Nvidia themselves putting them in as a kernel update that all Linux distros then have to use to get the updates? I just saw that the 570 Beta drivers just released officially, so when would you normally expect a rolling distro like OpenMandriva ROME to gain access to it? Would be nice to learn more about the process!
The nvidia drivers do not get submitted to the kernel like AMD and Intel drivers do. They are shipped as a separate package. As for when they show up in the OM repos, they first have to get built by the package maintainer, tested in cooker repos to make sure they work, and then they will get pushed to the rolling/rome repos.
I donāt have nvidia nor do I know when they will get updated.
Unfortunately, because nvidia is terrible at versioning their 3 driver release branches (sometimes prod is newer, sometimes beta, sometimes new feature), we often resort to what is going to work with the kernel. This is why 470 and lower have been relegated to Legacy in our repos. nvidia has publicly stated they will not support older drivers on the newer kernel. All of this leaves us in a unique situation other distros do not have, because they choose to tailor the versions of software they use and the types of users they expect in order to maintain popularity in the out of the box user base.
What I have noticed from my short time here, is they want to use maintained software to the extent possible, but also newer software so we donāt run into a sealed older version of components with lack of features even stable users would like to have.
This is interesting. That means my Nvidia GPU (GeeForce 840M; 2014ish, iirc needing v. 470) will go perpetually unused as Iām not willing to eternally sit on older kernels. The built-in Intel GPU does the job just fine for my modest needs.
Funny how a company would go to war against FOSS like that/make life so difficult.
Error snippet when attempting to install: - nothing provides kernel-desktop = 6.7.1-1 needed by nvidia-legacy-kmod-desktop-470.223.02-6_6.7.1_1.x86_64 from rolling-x86_64-non-free
I assume this means 6.7.1-1 is the latest supported kernel.
Interesting read overall. Bottom line, next computer Iāll just stay away from Nvidia all-together.
Your only hope is nouveau. While it still uses the proprietary firmware blobs, they are exchanging information back and forth now. Meaning nouveau should fill the gap including 3D rendering eventually.
Iāve been doing this for a while, for my personal machines. For my work machine, unfortunately, I get what I get (it has Nvidia, but Iāve gotten it to work with OM).
I have been going the well-traveled, safe route thatās worked for Linux people for years: buy a Thinkpad. I make sure I buy an AMD-based Thinkpad. They tend to be less expensive anyway. Stay away from the E series. I am partial to the P or T series.
So using the built in Nouveau driver? Or the Nvidia drivers? I think the age of mine will lock me out forever unless the Nouveau driver works on backwards compatibility (but honestly, I wouldnāt blame them for not spending precious hours on doing that. Seems expanding forward compatibility would be the best use of their time).
NVidia drivers with envycontrol installed. If you donāt do it that way, the NVidia chip consumes power even though itās not in use and drains your battery prematurely. I put it in hybrid mode and then forget about it (I donāt game anymore, and I certainly wouldnāt game on my work machine anyway
Just a FYI I am dualbooting Mint22 and Rome. I did a fresh install of rome and got the dkms-kmod-open 575 drivers going with kde RTX3080 and kernel 6.14ā¦anyway I have some odd bug that spikes cpu usage whenever you move the mouse or do any other activity. Google Gemini and I went over and over possibilities and we decided its a bug or regression. Im just on my old trusty Mint for now but I was getting FOMO for Wayland.
We donāt support the dkms-kmod for everyday use. That is specifically for testing it on a development kernel. If you are going to use it, be testing a kernel we are going to add to Cooker, and have upstream accounts to create forum posts and source code forge issues. Otherwise, please use the regular open driver built against the installed kernel. Since nvidia drivers are in the non-free repo, you should probably make those upstream accounts, anyway.
No, the open built driver should work unless you have multiple GPUās or some notebooks with USB external monitors donāt work well.
The point of my response is that we donāt really directly support nvidia drivers other than to successfully build them. Users with the hardware will need to test them and possibly submit issues upstream. Given the closed nature (yes, the open driver has closed requirements also) we will be unable to fix those issues on our side.
We are using a newer kernel than most distros would use. The only time you should use the dkms kmod is to test a new release from the kernel project. Given the current landscape with wayland and X11, you may not get any support for X11 from nvidia indefinitely.
