Black screen after installing RPMFusion drivers in a Fedora 30 laptop with an RTX 2060 and Intel UHD 630

Hello!

Just installed Fedora 30 on a new laptop with:

/sbin/lspci | grep -e VGA
00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 630 (Mobile)
01:00.0 VGA compatible controller: NVIDIA Corporation TU106M [GeForce RTX 2060 Mobile] (rev a1)

I have tried to install the NVIDIA drivers in two different ways and both fail:

Attemp #1:
Followed the instructions in https://rpmfusion.org/Howto/NVIDIA.
Result: A black screen after boot (can’t login)

Attemp #2:
Follow these instructions: https://www.if-not-true-then-false.com/2015/fedora-nvidia-guide/
Result: The system hangs while booting

I can only access the system again booting into runlevel 3 and uninstalling the drivers there.

I’ve got the log files as requested in the sticky threads, but I see no option to upload them here (?)

Many thanks!
attemp2-nvidia-uninstall.log (1.17 KB)
attemp2-nvidia-installer.log (9.23 KB)
nvidia-bug-report.log.gz (1.09 MB)

Hovering the mouse over an existing post of yours will reveal a paperclip icon.
https://devtalk.nvidia.com/default/topic/1043347/announcements/attaching-files-to-forum-topics-posts/
Since this is an Optimus notebook, did you check the docs on how to use PRIME?
https://github.com/bosim/FedoraPrime

Thank you for the helpful hints!

I indeed didn’t know about Fedora Prime. I had only heard about Bumblebee and that it somehow was not necessary anymore. The Github page of Fedora Prime says that it only supports Fedora 22 and 23, is it still advisable to use it in later OS versions?

Looking at the logs seems that using the repo driver has already halfway set this up. There’s only xrandr commands missing to enable the output.
https://devtalk.nvidia.com/default/topic/1022670/linux/official-driver-384-59-with-geforce-1050m-doesn-t-work-on-opensuse-tumbleweed-kde/post/5203910/#5203910
Don’t create the xorg.conf, just read the paragraph about xrandr and create the two needed .desktop files for Gnome.

Fantastic, that worked! Thank you!

I should mention that I am using the Cinnamon desktop (didn’t even think that I needed to mention that), so the final tweak was to switch from lightdm to gdm to make it work.

The battery life is now doubled thanks to the new drivers, so great! Is there any option to switch manually or automatically from the dGPU to the iGPU to save battery while I’m not using the former?

Thanks again.

I confirm that using the two desktop files are uneeded using RPM Fusion driver with GDM/Gnome.

But as you’ve mentioned to use Cinnamon Desktop, this might still be needed. I may document that in the following howto:
https://rpmfusion.org/Howto/Optimus

Ok, Fedora+Cinnamon is a rather uncommon combo. The Arch link at the beginning of the linked post contains instructions on how to configure other DMs than GDM.
Switching to intel for powersaving would require to unload/blacklist the nvidia driver and turning off the nvidia gpu, e.g. using bbswitch on boot.
nchauvet, I glanced over the contents of the current rpmfusion packages and could not find anything that would run the xrandr commands, could you point me to it?

Yeah, I guess… Now it is an official Spin: https://spins.fedoraproject.org/cinnamon/download/index.html

I seem to find contradictory directions on how to do this. Could you tell me where to read more about it?

Sounds good! Note that the actual troubleshooting steps I took were:

  1. Following generix instructions
  2. Rebooting (still got the black screen at login)
  3. Rebooting again into runlevel 3, installing and switching to gdm
    Installing gdm before rebooting is probably a good idea (:

I don’t know about a good doc to read about turning off the nvidia gpu. Outline:
Install bbswitch, have a systemd service to turn off power /etc/systemd/system/disablenvidia.service

[Unit]
Description=Disable Nvidia GPU
Before=display-manager.service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/disablenvidia.sh

[Install]
WantedBy=display-manager.service

running the script /usr/local/bin/disablenvidia.sh

#!/bin/sh
modprobe -r nvidia
modprobe bbswitch
echo "OFF" >/proc/acpi/bbswitch
logger Nvidia OFF

then the procedure to switch to intel would be

systemctl enable disablenvidia
echo -e "blacklist nvidia\nblacklist nvidia-drm\nblacklist nvidia-modeset\nblacklist nvidia-uvm" >/etc/modprobe.d/nvidia-blacklist.conf
dracut -f

and reboot.
To switch back to nvidia

systemctl disable disablenvidia
rm /etc/modprobe.d/nvidia-blacklist.conf
dracut -f

and reboot. Don’t know if ‘dracut -f’ is necessary, I’m not running Fedora.

Thanks again, generix, I’ll look into that.

I’m back because audio is now dead :( A couple of reboots after my last post neither the speakers nor the audio jack are working, apparently without reason. It’s not hardware - They work fine if I boot into Windows.

Trying to figure out what the problem was, I installed pavucontrol. It says something funny: That the (built-in) speakers are unavailable and the headphones are plugged in, although they are not.

Any ideas what to try next?

That’s not really nvidia related and debugging pulse weirdnesses is always too much pita but try this:
https://aweirdimagination.net/2018/12/16/pulseaudio-headphone-jack-troubles/

We (at RPM Fusion) don’t want to go the route of using a “/etc/modprobe.d/nvidia-blacklist.conf” because it will make the whole system “statefull”. Instead we would rely on grub2 boot cmdline to provided the appropriate blacklist.
If you need to blacklist nvidia because using nouveau, you need to add modprobe.blacklist=nvidia,nvidia_drm,nvidia_modeset from grub2 cmdline instead.

Also it seems very more efficient to rely on nouveau to deal with autosuspend (than bbswitch). (at a cost of a reboot, agreed).
https://nouveau.freedesktop.org/wiki/Optimus/
See also the power management section.

cat /sys/kernel/debug/vgaswitcheroo/switch
0:IGD:+:Pwr:0000:00:02.0
1:DIS: :DynOff:0000:01:00.0

So it’s disabled on purpose automatically.

(site note) According to #nouveau pmoreau on IRC freenodes: some MAC and Pascal card might have some issues with automatic suspend […], but it’s shouldn’t be a widespread issue.

nchauvet, please see this about using runtime suspend:
https://bugzilla.kernel.org/show_bug.cgi?id=201465
Ubuntu used that approach for some time and it caused a lot of headaches, not only because of this. Not ready for prime-time.