As noted few days ago, I decided to give OpenSUSE another chance. This time, for at least a month, and then give it my final judgement. I’ll likely write about motivation for going on this journey down the road, but for now, this is update on what has been weird for me on OpenSUSE side of things and the things that got on my nerves in this past few days.
In previous article I didn’t mention that in fact I went for the OpenSUSE Tumbleweed with KDE Plasma desktop. Consequently in this article you might notice that some issues are OpenSUSE annoyances, while others are KDE ones. I’ll try to elaborate each point as I go along and it should be pretty clear which one is which.
KDE Wallet
After the first login, when connecting to a WiFi, I got prompted to set up KDE Wallet. Default selection would suggest I should use GPG based encryption, but instead of going through some preliminary configuration (getting my Yubikey setup etc.) I decided to go for a blowfish based encryption.
I entered the same password I use for my user login in the KDE Wallet setup process in hope that Wallet will be automatically unlocked at login.
Unfortunately, next time I rebooted the machine, system prompted me for the Wallet password. Very user friendly… NOT!
After short investigation I noticed that package required for that functionality is not installed by default, so I promptly solved that
sudo zypper in pam_kwalletThis made everything work as expected, but it puzzles me why this is not provided by default. If I’m not mistaken, Arch pulls pam_kwalletd by default, as a dependency of KDE Wallet package, so let’s say OpenSUSE could try to be a bit more user-friendly in that regard.
WiFi connection time
While on the topic of WiFi I’ve observed one peculiar thing; that even after setting up pam_kwallet, WiFi connection took some time for initial handshake. After each boot, or resume from sleep, I would say it takes around 10 seconds for WiFi connection to be re-established.
Perhaps I am a bit too spoiled by the Fedora’s lightning speed. And perhaps this is KDE doing something weird. But both GNOME and KDE use NetworkManager underneath, so I guess there should theoretically be no difference between OpenSUSE KDE and Fedora GNOME, but that’s just in theory.
Update - 2020-12-28: I tried to enable the option called “All users may connect to this network” in network settings in hope that will speed up (connect to wifi before the login), but unfortunately issue persists.
Disk encryption
As any sensible person, carrying laptop around in my backpack, I encrypt my whole disk using LUKS. Just in case device gets stolen or lost or whatever.
Due to the way how OpenSUSE has decided to implement the encryption on EFI based systems, each time I boot the system, I get prompted for a password… twice…
This is easily solve-able and is even described in OpenSUSE Wiki article.
Regardless, first one prompted by EFI is ugly as hell, while the second one is the nice one. Not sure how Fedora does it but I am used to their “flickerless boot” so much that I consider everything else “an regression”.
Boot speed
Oh, and also, that decryption process seems to be quite slow on my Ryzen CPU based laptop for some reason. I would bet it takes more than shown in the following excerpt from systemd-analyze. But that may just be an “perceived slowness” or something like that.
ivan@swift3:~> systemd-analyze blame | head -5
7.367s dracut-initqueue.service
6.836s systemd-cryptsetup@cr_nvme.service
934ms dracut-pre-udev.service
690ms display-manager.service
601ms firewalld.service As you can see, almost 15 second is spent in that initial phase, and I’d bet it takes another 20 or so after entering my password in EFI prompt. Anyhow, analyze command still shows quite concerning numbers on a laptop that boots other distributions (Arch, Fedora, Ubuntu…) in few seconds
Startup finished in 5.125s (firmware) + 30.053s (loader) + 1.752s (kernel) + 9.070s (initrd) + 2.130s (userspace) = 48.132s
graphical.target reached after 2.121s in userspace
Screen backlight
For some reason, backlight of the screen is not remembered across the reboots. Each time the system boots it starts with 0% which is quite dim.
ivan@swift3:~> sudo systemctl status systemd-backlight@backlight\:amdgpu_bl0.service
● systemd-backlight@backlight:amdgpu_bl0.service - Load/Save Screen Backlight Brightness of backlight:amdgpu_bl0
Loaded: loaded (/usr/lib/systemd/system/systemd-backlight@.service; static)
Active: active (exited) since Sun 2020-12-27 20:04:46 CET; 22min ago
Docs: man:systemd-backlight@.service(8)
Process: 893 ExecStart=/usr/lib/systemd/systemd-backlight load backlight:amdgpu_bl0 (code=exited, status=0/SUCCESS)
Main PID: 893 (code=exited, status=0/SUCCESS)
Dec 27 20:04:46 swift3 systemd[1]: Starting Load/Save Screen Backlight Brightness of backlight:amdgpu_bl0...
Dec 27 20:04:46 swift3 systemd-backlight[893]: amdgpu_bl0: Saved brightness 10 too low; increasing to 12.
Dec 27 20:04:46 swift3 systemd[1]: Finished Load/Save Screen Backlight Brightness of backlight:amdgpu_bl0.And although it says 10 is saved brightness, I’m not sure if that’s correct. Primarily as I don’t know what the unit of measurement is. If it’s percentage, then, it’s clearly a lie. This may be the issue with the GPU I have, but since it’s not latest Vega graphics, I’d hope that all things would be polished by now in recent kernel such as on the one Tumbleweed ships. Needless to say, this works fine on other distributions…
Emacs
One peculiar thing I’ve observed is that emacs package is already pre-installed, I guess due to some group selected while performing network install. I was very glad to see that. In order to get the GUI version though, you have to install separate package (emacs-x11), but that’s just fine.
Package (un)install
I was playing a bit with i3 window manager in combination with KDE, and that package pulled in few dependencies. Unfortunately, when removing the package those aren’t cleaned up automatically
ivan@swift3:~> sudo zypper remove i3
Reading installed packages...
Resolving package dependencies...
The following package is going to be REMOVED:
i3
1 package to remove.
After the operation, 1.7 MiB will be freed.There’s a handy switch for the zypper command to clean those up (-u) but it seems it doesn’t work after you already uninstalled the package, so I, naturally, went through this charade:
ivan@swift3:~> sudo zypper remove -u
Too few arguments.
At least one package name is required.
ivan@swift3:~> sudo zypper remove -u i3
Reading installed packages...
'i3' not found in package names. Trying capabilities.
No provider of 'i3' found.
Resolving package dependencies...
Nothing to do.
ivan@swift3:~> sudo zypper in i3
Loading repository data...
Reading installed packages...
Resolving package dependencies...
The following NEW package is going to be installed:
i3
1 new package to install.
Overall download size: 953.7 KiB. Already cached: 0 B. After the operation, additional 1.7 MiB will be used.
ivan@swift3:~> sudo zypper remove -u i3
Reading installed packages...
Resolving package dependencies...
The following 16 packages are going to be REMOVED:
dmenu i3 i3lock i3status libconfuse2 libev4 libstartup-notification-1-0 libxcb-xrm0 perl-AnyEvent perl-AnyEvent-I3 perl-common-sense perl-Guard
perl-JSON perl-JSON-XS perl-Task-Weaken perl-Types-Serialiser
16 packages to remove.
After the operation, 3.9 MiB will be freed.Conclusions
So far I’ve noticed some things that OpenSUSE decides to do a bit differently, and even some rough edges as you can see, but I’ll continue my exploration and be open-minded.
Some things are really frustrating while others require a bit more playing to resolve them. In any case, if those were solved for me by the distribution maintainers, I’d be much happier with the distribution.