Starting Clean with Fedora 30: Using Fedora on the Dell Precision 5520, Part 4

By Paul Graham

Previous Posts

In my previous posts (First Post, Second Post, Third Post on using Fedora on my Dell Precision 5520, I described some of my experiences in using Fedora on that laptop. This is a quick update on those experiences, with an explanation why I decided to mostly start clean with Fedora 30.

Fedora 29

Since the previous post (last summer!), I have updated Fedora to version 29 (and version 30 just today). The update was very smooth using the command line instructions from Fedora Magazine–check out their latest articles for a variety of things about Fedora and Linux more generally.

As with previous versions of Fedora, I have found Fedora 29 to be quite usable on a daily basis. Here is an article on the nice features of the latest release of Fedora Workstation.

Generally, Fedora 29 ran well on my Dell Precision 5520 laptop with only some quirks along the way, some of which I will mention below.

Precision 5520 Firmware Upgrade Directly in Linux

I am still enjoying the firmware upgrades that are supported directly in the GNOME Software application for the Dell Precision 5520 laptop. In the previous post, I noted the improvement I saw in compatibility with my Thunderbolt-based Dell TB-16 Dock. I find the ability to perform the upgrade in Linux excellent–it definitely beats the bad old days of MS-DOS boot media just to update the PC’s firmware. For those that are unfamiliar with this feature, GNOME Software application provides notifications of updates, including firmware. Assuming you have your computer attached to wall power, you can just hit Install in the updates section of Software and you just have to reboot for the changes to take effect. I have done the upgrades smoothly a few times now. In this day and age where CPU vulnerabilities are found regularly, having easy BIOS/firmware updates is a great feature.

As an update to the previous post discussing the use of external monitors with the Precision 5520 with a Thunderbolt dock, no matter what I did with the Dell TB-16 Dock, I could not get it to drive two Dell UltraSharp 32 UltraHD 4K monitors through a high-end Belkin KVM. The TB-16 could drive the monitors flawlessly without the KVM, but, when connected to the KVM, eventually there would be some significant noise or corruption with the screens. I tried different drivers and desktop environments, but it didn’t make a difference.

Eventually, I tried a StarTech.com USB-C Dock with Dual-DisplayPort connections. The difficulty with this hardware (and similar models) is the use of DisplayLink. There are no simple drivers to install for Fedora, but the company does make a driver for Ubuntu. They also acknowledge in a post that the drivers they provide can be ported to other distributions (but they aren’t going to do it). Thankfully, some folks have developed a GitHub project that can be used to repackage the Ubuntu drivers for Fedora and CentOS.

The downside is that, as far as I can tell, you have to build the RPM yourself. Being a Linux hardware and software developer, this wasn’t hard once you have some basic development packages installed. I suspect that those tools are likely covered by the Development Tools and RPM Development Tools group packages in Fedora. Specifically, you should be able to run:

sudo dnf groupinstall "Development Tools"
sudo dnf groupinstall "RPM Development Tools"

On one of the Fedora 30 machines, I also had to install the gcc-c++ package and the libdrm-devel package for the build to complete. The build process actually pointed out the names of these packages when the build failed, so hopefully many folks can perform the build with some hints from running make.

Once you install the tools, you can clone the repository by executing the following:

git clone https://github.com/displaylink-rpm/displaylink-rpm.git

and then enter the displaylink-rpm directory and type make to build an RPM. The process builds both 32-bit and 64-bit binaries, placing the new RPMs in the i386 and x86_64 subdirectories, respectively.

One of the great things about Fedora is that it tracks changes in the kernel fairly quickly. Of course, that is also a challenge since custom drivers may need to be rebuilt. In my experience, I rebuilt the latest version of the RPM (git pull; make) to make sure I had a reasonable chance of having a driver that would work with my new kernel. Then, I would need to uninstall and re-install new the DisplayLink RPM to get things to work again. This shouldn’t be necessary–it seems like DKMS or some similar system should be able to handle these changes, but I don’t think this is used in the package.

In more rare instances, I had to follow the instructions provided on GitHub or in the README.md file that comes with the code and perform a make rawhide build. This uses the latest package and source to build the driver. When the kernel was a bit too new (too many changes), using make rawhide frequently did the trick.

I should also note that I did the above, of course, with a laptop so I always had some sort of a screen when the drivers needed maintenance. I would remove the driver and make sure I rebuilt the driver just in case it was needed, both of which could be done safely in a graphical environment. To do the driver install, I would either log in remotely or switch to a virtual terminal (after logging out of the graphical environment) to perform the driver re-install. If you are in a graphical environment when you install the driver, things make act oddly (mainly, lockup, if I remember correctly).

This Startech.com dock worked fine with the two 4K displays and the Belkin KVM, which has been nice. The problem, of course, is that the kernel updates so frequently that I have to do this uninstall/re-install operations regularly. With CentOS, the kernel updates may not come quite so often, so I could see how living with DisplayLink would be less work. Until I find a better dock, though, I still use the Startech.com DisplayLink dock, which serves me well despite the maintenance.

NVIDIA Drivers: The Demise of the Simple Fedora 30 Upgrade

Today, I finally got around to updating the laptop to Fedora 30. The problem I ran into is that there were some packages from the negativo17 repositories that were preventing a clean update form Fedora 29 to Fedora 30, bummer. I decided to just “bite the bullet” and do a clean install of Fedora 30, preserving my data.

One complicating factor is that the main partitions in LVM were actually encrypted with LUKS 2, so this was a new experience for me. As it turned out, the installation went fine. I had to provide the installer my decryption password to decrypt the LVM filesystems and then I used the “Custom” partitioning option so I could try to be lazy and just keep my data. In the Custom partitioning screen, I selected the old root, boot, boot/efi, and swap partitions and mapped them into the Fedora 30 installation following the mount points they used to be at under Fedora 29 (the tools provides this information). Further, I selected “Reformat” for each of these partitions.

For the data partition (/home/), I just selected the partition, providing it with the /home/ mount point for Fedora 30, making sure it was not going to be reformatted. Once the installation was done, I created a new user account at startup with my old username and it seemed to work OK, since my home directory would then be the same.

Also, I don’t have other users on the laptop, so the user ID (UID) and group ID (GID) mappings were trivial for the new installation. In a case where you aren’t the only user (and you can’t easily add the users back in the same order), it might be better to use the useradd command-line utility to carefully configure things. Of course, you could also keep the same user names and then use

chown -R <username>:<groupname> /home/<username>

to change the owner and group of the home directories to meet the new UID/GID mappings. I thought I would mention this since I know it might be a pitfall that others may run into that didn’t apply in my case.

So, surprisingly, even with dealing with encrypted partitions, the clean install of Fedora 30 using the existing partitions seemed to work out just fine. Time will tell if there are any hiccups.

Evolution

GNOME’s Evolution continues to be my daily workhorse when working with my corporate mail server. I am not sure I have seen a lot of differences since the previous posts, but is continues to work for me.

One interesting situation that I have noticed is that, when I use Kerberos authentication for talking to the corporate Exchange mail server, under GNOME I have to re-enter some credentials to access my calendar, to-do lists, etc. Mail does work without the additional login. Under Plasma, the Kerberos setup works fine for everything, so I tended to use Plasma on Fedora 29 before the recent upgrade. It will be interesting to see if things work better under GNOME with Fedora 30.

All in all, though, Evolution continues to work well. It might not be as pretty as some clients, but it gets the job done. As noted in the previous post, I would be a little wary using Evolution for doing some calendaring functions.

I am sure there are several other comments and stories to tell, but I think this has hit the highlights.