Date Modified Tags Linux / Fedora

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:

  1. 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
    
  2. 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:

  1. Right click on the WiFi icon the lower right of the screen (the Plasma NetworkManager applet on the panel) and select "Configure Network Connections...".
  2. On the dialog box that comes up, select a WiFi network and then select the "Wi-Fi Security" tab for that network.
  3. Using the drop-down selection box below the "Password" box on the "Wi-Fi Security" tab, select "Store password for all users (not encrypted)".
  4. 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.
  5. 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.

Discover installing LibreOffice

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.