Fedora32, Gnome, Wayland and Nvidia

Problem

Using Fedora since version F30 with Intel or Nouveau driver. I like it a lot because Wayland/Gnome works very well with monitors having different DPI, e.g. Retina Display on Notebook combined with an old office monitor. Recently I bought a new PC for working (Ryzen 7) and gaming (Nvidia Geforce RTX 2070). I installed Fedora 32 and Windows 10 on the new system and was happy to see my system working without problems. For work, I would use Fedora and for Gaming, I use Windows 10. I was very pleased with the Fedora experience, everything worked as smooth as silk, not tearing or flickering issues at all. (I had bad experiences in the past, normally the first thing I do on Linux is disabling the Nvidia card and use Intel Processor Graphic only.)
But after a few hours of working, I noticed that the system was not as fast as expected. `htop` showed that all 16 cores where utilized by gnome-shell for 2-3%. As soon as I had Chrome opened or doing stuff with Visual Studio Code CPU load on all cores spiked. After doing some research and experiments I discovered that my super fast RTX 2070 graphics card is not even near to be supported by the nouveau driver. Everything is done by the CPU, no hardware acceleration at all. As the system has no Intel Processor with integrated graphics, I tried the proprietary Nvidia driver again.

My System

Nice summary also available in Gnome Settings / About

• Date (date -I): 2020-05-03                                                             
• Kernel (uname -r): 5.6.8-300.fc32.x86_64                                    
• Gnome (gnome-shell --version): GNOME Shell 3.36.1  
• CPU (cat /proc/cpuinfo | grep -m1 "model name"): AMD Ryzen 7 3700X 8-Core Processor 
• Graphics (lspci | grep VGA): TU106 [GeForce RTX 2070] (rev a1) 

Helpful Tools

• `echo $XDG_SESSION_TYPE` prints X11 or Wayland
• show current kernel parameters `cat /proc/cmdline`
• show currently loaded kernel modules `lsmod | grep nvidia` or `lsmod | grep nouveau`
• Instructions to install Nvidia driver

Changing Kernel Parameters

• `sudo vim /etc/default/grub` to edit `GRUB_CMDLINE_LINUX="..."`
• `sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg` to apply changes
• `reboot`

/etc/modprobe.d/

I'm not an expert in this topic, but I also needed to blacklist modules and set module parameters in `/etc/modeprobe.d/nvidia.conf`. To activate those changes it was necessary to regenerate the /boot/initramfs-* files. `sudo dracut --force` is the most simple and dangerous way as it generates and overwrites the intiramfs for the currently running kernel. Better move the existing initramfs away with `sudo mv /boot/initramfs-$(uname -r).img /boot/backup-initramfs-$(uname -r)` before
starting experiments.

Findings

After following the [instructions](https://www.if-not-true-then-false.com/2015/fedora-nvidia-guide/)
the system booted up fine and I instantly saw that moving windows or using Chrome
did not trigger high cpu load any more. Even WebGL Demos in Chrome were running with neglectable cpu load. But then I noticed I was running on X11 and not on Wayland any more. I googled around and could not find any useful information if it is possible to use the NVIDIA driver
with wayland. So I tried to enable it.

Enabling Wayland in Fedora32 for proprietary Nvidia driver

Comment out the gdm-disable-wayland in `/usr/lib/udev/rules.d/61-gdm.rules`
# disable Wayland when using the proprietary NVIDIA driver
DRIVER=="nvidia", RUN+="/usr/libexec/gdm-disable-wayland"
Enable experimental kernel mode setting (from NVIDIA perspective)

• Add `nvidia-drm.modeset=1` to `GRUB_CMDLINE_LINUX`
• Add `options nvidia-drm modeset=1` to `/etc/modprobe.d/nvidia.conf`
• update grub and initramfs and reboot

Running on Wayland with proprietary Nvidia driver

After reboot Wayland was active, and I could log in. Looks promising. `nvidia-settings` was no longer working, but `nvidia-smi` was. Also lsmod shows me that the nvidia driver was active. Firefox and Gnome looked fine, no cpu usage spikes. By then it was time for lunch and I suspended
the computer. After lunch I pressed Space and saw corrupted log in screen but was able to login. Unfortunately, all the graphics were corrupted, you could see only the rectangles of the windows. Still I was able to reboot, and my system was usable again.
I spent hours trying to diagnose and fix those issues, but no relevant errors in journalctl, and no findings with Google. It tried the systemd suspend mechanism as described in the Nvidia drivers readme but with no success. In the end I decided to go without suspend capability and just turn off and on again.
On the next day, I continued to do some work again. When using Visual Studio Code, Gnome immediately crashed. It seems that all applications running in Xwayland (a compatibility mode
for applications not running natively on Wayland) crashed after a while, especially after resizing the window. Just resizing an Xwayland app triggered the crash.

Conclusion - Back to X11 with proprietary Nvidia driver

So in the end, as long as Chrome and Visual Studio Code are not natively supporting Wayland, Wayland is unusable with Nvidia drivers. It's a pity, that a company earning lots of money with their pretty fast cards is not able to provide a stable linux driver, a thing that a few volunteers were able to to do with the nouveau driver. It would be nice if Nvidia would a least help them a little bit to get support for newer Nvidia cards into the nouveau driver.

Don't use curl in Dockerfiles

Today I broke a production server because a docker image had missing files. How could this happen? The build was green, the app was tested, docker built the image without any errors.

When I looked at the Dockerfile I found some curl commands to download additional .jar files directly from the internet. They contained some specialized logging logic that was not used during the tests, but made the application fail in production. It turned out that those files no longer exist on the internet. And that's the reason for my provocative blog titel:

curl will exit with code 0 even if the server responds with a 404 Not Found status code, because from a protocol point of view everything was correct. In this case scripts and dockerfiles will not fail but silently ignore failed downloads. To be honest, there is a --fail option for curl, but it's not fail safe and you have to know it. That's the reason why I now prefer wget for downloading files in scripts. It will by default return a non zero exit code if the download fails, and therefore failing the script. If you need to pipe the downloaded file to stdout you can do it with wget -O - <url> too.

Fixing WiFi repeater issues on Ubuntu 15

I'm quite happy with my switch from Windows to Linux. Despite my initial fears of having to compile the kernel because of driver issues, my Asus notebook with Xubuntu 15 worked out of the box and even WiFi works like a charm. At home I have my workplace under the roof and therefore the signal strength is quite bad. So bought a cheap WiFi repeater and the internet was fast again. Unfortunately sometimes it get slow again, especially after waking up from sleep. After spending some time with iw* command line tools I finally found out what was going on.

It seemed that for some reason I got connected to the WiFi access point in the basement and not to the repeater. You could use the excellent wavemon tool to monitor the signal strength of all available access points. (sudo apt-get install wavemon && sudo wavemon)

As you can see in the screenshot, two access points with the same name (first column) but different BSSIDs (second column) are visible.

The fix was really easy even if I had to use the mouse for it  ;-) Click on your WiFi symbol and choose "Edit Connections ...". Then choose your WiFi connection and press the "Edit" button. Click on the "WiFi" tab. In the BSSID dropbox choose the one you want to connect with (The one with the strongest signal shown in wavemon). Don't forget to press "Save". That's it.