Why does it seem to be so difficult to install Leap 15 on a PC with NVIDIA hardware?

English Install/Boot/Login
1

Oh I never wanted to install openSUSE on hardware with NVIDIA graphics, after seeing all those posts on this forum over the years reporting problems with this hardware - or the software needed to run it!
That, and because I don’t play games, is why I - for myself - bought hardware with processor graphics, which even seems to be as difficult as buying hardware without windoze preinstalled!

I refer to the situations on two laptops with NVIDIA graphics and Leap 15.0 installed, reported in
https://forums.opensuse.org/showthread.php/533906-Leap-15-0-Console-login-problem?p=2891682#post2891682

One of the laptops with NVIDIA graphics that I had trouble with, was a present.
The other laptop isn’t mine.

After reading in this forum that a kernel update would be available, I tried another installation of Leap 15.0 on the laptop with core i3 and GeForce 310M.

First the DVD installer got hang, because I forgot to give ‘nomodeset’ for installation (I’m still not used to that!).
With that nomodeset, installation was “successful” (see below).
Besides the installer “DVD” (that I dd’d on a USB stick), I used the four online repositories.
The kernel thus is the most recent one for leap 15.0 that came out today, 4.12.14-lp150.12.45-default.

During installation, for the bootloader settings I removed “nomodeset” (as well as “splash=silent quiet”).
This time the suggestion to not to install Mesa-dri-nouveau didn’t appear (I’m wondering why, and this one was installed, as I discovered later on).

On the first reboot, the KDE desktop doesn’t appear, only a mouse cursor.

At least Ctrl-Alt-F1 and “shutdown -h now” worked then.

Reboot.
This time I use “e” at Grub2 to add “nomodeset” as boot option.

I get into KDE (graphics are distorted, what I expected), but the system seems to run stable - at first glance.

Using YaST, I deleted Mesa-dri-nouveau.

Reboot.
(this time no “nomodeset”).

KDE gets up. It seems to run.

While starting firefox I get a bug in the KDE panel at the bottom of the desktop, telling me that Kwin had been terminated.
(Was this a result of starting firefox? Don’t know really, this is multitasking …).

Otherwise, the system seems to run stable.

It now seems that I don’t have to install the proprietary NVIDIA drivers to get a stable Leap 15.0.

Comment:

I myself have gathered some experience installing different versions of openSUSE over the years.

But what would be the expectations of a user that is new to Linux and openSUSE?
I once was a newbie too. I didn’t forget this.

Besides, openSUSE 13.2 and even Leap 42.3 do work fine with this kind of hardware, apart of the fact that under Leap 42.3 submenues sometimes flicker, which I accept, but which as well may be disturbing to a newbie.

2

This problem has nothing to do with nVidia.

3

Simple answer: NVidia pays nobody to write FOSS, employing a policy that maintaining secrecy produces competitive edge.

Simplistic solution: Employ as much effort as required to ensure none of your money makes its way into NVidia coffers.

I’ve purchased NVidia product a grand total of 3 times, and spent no more than $30US per piece. In each case, it was either new-old-stock or used, and designed at least 5 years prior to acquisition, giving reverse engineers ample time to produce for it a passable FOSS driver.

4

This reminds me of cases of an entropy-starved cRNG (cryptographic random-number generator) in the kernel. Usually assisted by »haveged«, the kernel tries to collect random data from hardware timings and user interaction in its entropy pool. During boot, this pool can be too small to act as a source to create true random numbers, especially if the system is virtualized where things can be even more uniform and lacking of entropy. Unfortunately, one of the first clients for random-number generation can be sshd during boot, or the display manager right after it. I’ve seen it happen that the system seems to freeze mid-boot as you described; then, after pressing a few keys and/or moving the mouse (i.e. manually increasing system entropy), the boot continues, KDM/SDDM etc present their login screen (or perform an auto-login in my case), and the system is up and running.

This effect should be rare because of havege/haveged, but I’ve seen it happen on physical installations on occasion. You can have a look searching through the kernel messages:

dmesg -dT | grep -i random

… which, in case of my freshly booted openSUSE Leap 15 this morning, yields:

[Sat Jan 19 07:53:39 2019 <    0.021799>] random: systemd: uninitialized urandom read (16 bytes read)
[Sat Jan 19 07:53:39 2019 <    0.000027>] random: systemd: uninitialized urandom read (16 bytes read)
[Sat Jan 19 07:53:39 2019 <    0.000010>] random: systemd: uninitialized urandom read (16 bytes read)
[Sat Jan 19 07:53:39 2019 <    0.001119>] random: fast init done
[Sat Jan 19 07:53:40 2019 <    0.093842>] random: crng init done
[Sat Jan 19 07:53:40 2019 <    0.000001>] random: 7 urandom warning(s) missed due to ratelimiting

I can see that I could use some more entropy during boot as well. Still, and judging by dmesg dumps of others on the web, this appears to be pretty normal.

As for your NVidia troubles, I only can recommend watching your logs closely, and after every change you make to the system. Usually, checking all of the following logs for changed behavior should produce a few clues:

  • dmesg

  • journalctl -b # system log from most recent boot onwards

  • tail -f -n $LINES ~/.xsession-errors /var/log/Xorg.0.log # have it run along daily work in a terminal window; any lines marked (WW) or (EE) should deserve special attention:

  • grep ‘(WW|EE)’ ~/.xsession-errors /var/log/Xorg.0.log this grep displays any Xorg-related errors or warnings

  • less /var/log/kdm.log # … or the log of SDDM, or of the display manager of your choice

  • nvidia-smi # more like a command-line status utility than a log

Finally, »a trap for young players« (as EEVblog’s Dave Jones likes to put it in his aussie accent):
If you manually reconfigure things (graphics drivers, other periphery, system tuning, adding or removing system RPMs), never forget to run dracut as root user before booting your system, or else your changes may be ignored during early boot (right after GRUB) because those changes haven’t made it yet into the initrd (initial RAM disk) used by the kernel to bootstrap the rest of your system. Using YaST, this happens automatially after relevant changes; without YaST, you have to think about launching dracut on your own. I have fallen into this trap several times on my main rig while experimenting with Nouveau/NVidia-proprietary drivers, wondering why my changes won’t manifest during boots.

I can only imagine that mobile GPUs can add more complexity, especially with laptops that use buggy BIOS-/ACPI-power management (try the latest BIOS update); or which use their integrated Intel (or AMD-APU) graphics core for saving power and only activate the NVidia GPU when necessary for 3D stuff. Does your machine do that?
Happy testing. Cheers!

5

When I first installed openSuse on a new laptop with nvidia graphics, in late 2018, the display didn’t work. Pressed by other activities, I put the computer (HP Omen) aside. Then I saw that a software update from openSuse included a new list of supported hardware, so I tried again in January 2019. A fresh installation resulted in a functioning computer with hi-res graphics. I hope these problems are behind us now.