Fedora 29 KDE Plasma Desktop Edition on a Dell XPS M1530
Standardizing on Fedora Linux
For several months, I have been using Solus Linux on an older Dell XPS M1530 laptop, as documented in my post in installing Solus and my follow-up post after 4 months. In general, the experience was good, but with Fedora 29 running on my main desktop, it required several extra steps to verify various web site builds using Pelican. Further, I was seeing some significant instabilities in Firefox on Solus that I haven’t seen under Fedora. Given these issues, I decided to make things easier by moving the XPS M1530 laptop to Fedora 29.
Which Version of Fedora?
With the desire to standardize on Fedora, the next question I needed to answer is what version of Fedora to install. Fedora’s main version of Fedora Workstation ships with the GNOME Desktop Environment by default. I’ve used Fedora Workstation and it’s predecessors since Fedora Core 1. On my main desktop machine at home, my wife would mention and demonstrate various stability issues with GDM and GNOME (though, she didn’t quite say it like that), so I thought I would look into some alternatives.
With the significant amount of good press KDE Plasma has been receiving on various podcasts (Ask Noah, Linux Unplugged, Destination Linux, and others), I thought I would try out Plasma on Fedora since there was a potential that it would be more stable and lighter than GNOME. I installed Plasma using:
sudo dnf group install "KDE (K Desktop Environment)"
when running Fedora 28 on the desktop. To try to improve stability, I also tried using KDM and SDDM for the display managers as alternatives to GDM. For more information on how to change display managers, take a look at Fedora Switch Display Manager – GDM/SDDM/LXDM/LightDM/KDM/XDM.
After some time, though, it was fairly clear that the desktop probably needed a clean installation of Fedora since a number of things with the system weren’t quite right–the display managers weren’t reliable when switching among multiple users, snapd didn’t work without a number of SELinux errors, etc. The system had been installed originally with Fedora 23 (or so) and had been upgraded through Fedora 29.
Over the Christmas break, I reinstalled Fedora 29 on the main desktop
using Fedora 29 KDE Plasma Desktop
Edition, preserving the files
in /home by using the “Custom” paritioning option for the disk
settings for the Anaconda installer (reformatting all LVM logical
volumes except for the one holding the home directories). So far so
good–I haven’t seen a lot of issues on the desktop.
Fedora 29 KDE Plasma Desktop Edition on the Dell XPS M1530
The Fedora 29 KDE Plasma Desktop Edition is a “spin” of Fedora 29 that focuses on delivering a full Plasma Desktop experience for Fedora. The main applications installed are from the large list of KDE Applications that are available. Further, the SDDM display manager is installed by default, which seems to nicely integrated with Plasma.
Preinstallation
Before installation, I backed up my home directory off of the Solus
install as well the /etc directory (just in case) onto a USB stick.
My LVM partitioning scheme under Solus was a bit annoying since I
didn’t have a separate volume for /home, otherwise, I would have
been able to install Fedora over Solus without affecting my home
directory - I won’t make that mistake again.
Installation
The KDE Plasma Desktop Edition uses the same installer, Anaconda, as the standard Workstation uses, so installation was very familiar. I reclaimed the entire disk since there was no separate LVM volume for the home directories and I had backing things up, as noted above.
Like with Solus, the Broadcom BCM4312 wireless card wasn’t recognized by Fedora out of the box. Unlike Solus, the wired Ethernet device - a Marvell Technology Group Ltd. 88E8040 PCI-E Fast Ethernet Controller - did not just work - I will talk more about this issue below. Without any networking, I continued with the installation.
I did run into another issue during the installation that caused the system to either shutdown or reboot - maybe I bumped the power by accident. The laptop went into a reboot loop that I had to stop by rebooting to the Fedora KDE Plasma Desktop Edition installation USB stick again and reinstalling. I don’t know the cause of the problem and if it was user error during installation or a problem with the installer since the system was unattended during the install once all of the basic information for Anaconda was provided.
Note that while I added a password for the root account, I didn’t add any user accounts during installation. With the second reinstallation successful, I added a normal user after the successful boot. At that point, I restored my home directory files from my backup on a USB stick and the installation was complete.
Ethernet Problems
The fact that the Ethernet controller didn’t work out of the box was
quite confusing and surprising, but eventually I thought to look at
the script ifcfg-enp9s0 located in /etc/sysconfig/network-scripts,
where the settings for Fedora network interfaces are stored. In the
file, there was a workaround of some sort that was a part of the
installation for the Ethernet interface that looked like:
ETHTOOL_OPTS="autoneg off speed 100 duplex half"
I thought to look here because I’ve had an old Dell desktop computer
that seemed to have some network speed limitations when running under
Fedora. In the end, using ethtool I discovered it was running half
duplex, i.e., the network interface could only talk one direction at a
time. After some looking around, I noticed there was an extra line
much like the example above that forced the Ethernet controller into
100 Mb at half duplex, despite being a Gigabit Ethernet controller -
something had automatically configured this setting in the
installation for the old Dell desktop. Once I removed the line for
the desktop, more reasonable network speeds were achieved.
For this Dell XPS laptop, commenting out the ETHTOOL_OPTS line and
rebooting caused the Ethernet networking to come up as expected.
Once Ethernet was working, I performed a system update using dnf as
follows:
sudo dnf update
WiFi Setup for the Broadcom BCM4312 using Fedora
To deal with the fact that Linux, by default, does not have any open-source drivers for the Broadcom BCM4312, I had to install the proprietary Broadcom drivers for this wireless card.
To do this for Fedora 29 (using the Ethernet interface), I did the following:
-
I installed the RPMFusion free and non-free repositories using:
sudo dnf install https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm https://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm -
I installed the wireless meta-package “kmod-wl” using:
sudo dnf install kmod-wl
At that point, the wireless drivers were installed, especially, the
broadcom-wl package, which supports the BCM4312. While it may not
have been necessary, I rebooted Fedora and made sure that the wireless
enable switch was “on” and wireless was working. I did notice that
the first boot after the installation took a little time. I believe
that this is because Fedora was compiling the kernel module(s) for the
wireless network interface dynamically at boot time, so be aware that
it might take a little bit of time to boot when there are new kernels.
Unfortunately, the wireless under Plasma has been a bit odd even when the drivers have been installed. Basically, the Plasma NetworkManager applet has problems connecting to networks that it can see. Frequently, when I log in, NetworkManager complains that “No secrets was provided” and won’t connect. It seems like this is somehow related to the KDEWallet and not providing the network passwords. As I note in https://ask.fedoraproject.org/en/question/131093/fedora-29-kde-wifi-kwallet-issue-durig-startup/, there are a few workarounds.
The most convenient work around is to do the following:
- Right click on the WiFi icon the lower right of the screen (the Plasma NetworkManager applet on the panel) and select “Configure Network Connections…”.
- On the dialog box that comes up, select a WiFi network and then select the “Wi-Fi Security” tab for that network.
- Using the drop-down selection box below the “Password” box on the “Wi-Fi Security” tab, select “Store password for all users (not encrypted)”.
- Of course, you should make sure the right password is entered in the “Password” box, but even with the correct password I had problems using the “Store password for this user only (encrypted)” setting. This seems to suggest that there is some sort of bad KDEWallet integration (or something similar). With the “Store password for all users (not encrypted)” option, I have not been getting the “No secrets were provided” message.
- Repeat steps 2-4 for each WiFi network listed in the dialog box. Oddly I didn’t have to re-enter the password that had been stored, just select “Store password for all users (not encrypted)”, so clearly it had remembered the password somehow.
Alternatively, I suspect that using the “Ask for this password every time” for a WiFi connection for Step 3 above might be another alternative to “Store password for all users (not encrypted)”, though, it would not be as inconvenient.
As another workaround I did learn that the following can be used to manually bring up the wireless interface with a specific access point SSID:
sudo nmcli -a connection up <the SSID>
It is worth noting that I used the KDE Plasma network settings tool to
configure the SSID for the wireless interface, so Fedora had files
like ifcfg-<the SSID> in /etc/sysconfig/network-scripts.
Performing that configuration is needed to use the nmcli connection
command above. Also, note that the -a option is provided so that
nmcli asks for the WiFi password for the given access point, which
is why this technique works. Otherwise, nmcli complained that it
didn’t know the WiFi password.
This may be a common problem with KDE (for example, https://www.reddit.com/r/kde/comments/8ubk44/513_arch_wifi_gets_disconnected_at_startup_saying/).
NVIDIA GPU
As with Solus, Fedora does not automatically have the proprietary drivers for the NVIDIA GPU (a lowly GeForce 8600M GT), as a part of the installation. It is possible to use RPMFusion to do the installation - see RPMFusion NVIDIA Howto for more information. Using the instructions in Determining your card model, it is clear that the GeForce 8600M GT requires the 340xx series of driver.
Since I already have the RPMFusion repositories installed to support the wireless card, all I needed to do next was:
sudo dnf install xorg-x11-drv-nvidia-340xx akmod-nvidia-340xx
sudo dnf update -y
and reboot. To actually reboot, I tried using the Plasma ‘Reboot’
option, but it generated an error - probably because I had just
changed the X server setup underneath the session. To actually
reboot, I just did sudo reboot in a terminal.
After rebooting, I noticed that the usual Fedora boot progress screen was different, but the familiar “NVIDIA” logo did appear as it started up SDDM.
I did have a bit of a scare at first login. It seemed like some sort of modifier key was being held on because the keyboard seemed to be acting oddly for all applications. Using the mouse, I logged out of the session. When I logged back in, everything has been OK.
Compared to running Solus on this same Dell laptop, using Fedora’s KDE Plasma spin has been a little rougher dealing with proprietary drivers and the interesting Ethernet problem I ran into.
Install Visual Studio Code on Fedora 29
I have started to use Visual Studio Code a lot, especially, when using the Go (golang) programming language. Here are the steps for performing that installation, based on the Visual Studio Code docs for setting up on Linux:
sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc
sudo sh -c 'echo -e "[code]\nname=Visual Studio Code\nbaseurl=https://packages.microsoft.com/yumrepos/vscode\nenabled=1\ngpgcheck=1\ngpgkey=https://packages.microsoft.com/keys/microsoft.asc" > /etc/yum.repos.d/vscode.repo'
dnf check-update
sudo dnf install code
To break down what the commands are doing, the first line is importing
a Microsoft key that can be used to verify that Microsoft built the
package. The second line creates a YUM repository .repo file so
that dnf knows how to talk to the Microsoft Visual Studio Code YUM
repository. The third line does a check of the YUM repositories for
updates (getting dnf to talk to the Microsoft Visual Studio Code
repository for the first time). Finally, the last line actually
installs Visual Studio Code.
Discover Software Center and Plasma Software Management
The Plasma Discover Software Center is the KDE method for installing
software with a graphical client. Interaction with Discover is fairly
easy and you get access to the large number of applications available
with Fedora. If you install snapd, snap packages will also show up
in the Dicover application under Fedora.
One thing that is a bit surprising is that when you install an
application, you then immediately end up updating the very application
you just installed, assuming updates are available. It isn’t clear to
me why the updated version isn’t just installed in the first place.
When installing using dnf on the command line, the updated
application would be installed first instead of requiring an initial
install and then an update.
Another odd thing is that worth noting is that, on the Dell laptop, I haven’t been able to figure out how to use Discover for updates. I can select the “Updates” button on the left hand and I get a listing of packages to update, but the buttons for actually executing the update in are disabled.
Below is a screenshot of Discover as I install LibreOffice–something that the KDE Plasma Desktop Edition does not include by default.
As a part of Plasma, I do see a notification that software updates are available. You can click on the notification and request software updates from the notification, which is convenient and seems to work quite well.
As noted in my post on Solus
Linux, Fedora has many
more open-source packages available for installation from the Fedora
repositories. Solus Linux does make it easy to install some proprietary
software, which takes a little more effort for Fedora. In general, I
appreciate Fedora’s depth and quantity of open-source software
solutions. For example, installing and Go and Rust only requires a
dnf install golang and dnf install rust, respectively.
Initial Impressions
With a few rough edges for installation, including the need to install proprietary drivers for wireless and graphics drivers. Further, it has taken a little work to get the wireless configuration applet (NetworkManager) to quickly connect to a wireless network automatically and modifying the wired network configuration file required to bring the wired network interface up.
I’ll write an update if anything interesting arises.