Displaylink Service Failure at update (F44)

Ask Fedora
1

Morning! First time contributing, wanting to report a bug, do let me know if it is the right place to do so.

Troubleshot the issue with the assistance of AI, this post was not made or reviewed with AI

Specs

  • Lenovo Thinkpad T14 Gen5
  • Fedora 44
  • Kernel 6.19.14-300.fc44.x86_64
  • Gnome 50.1
  • CPU/GPU: Ryzen 7 Pro 8840U/Radeon 780M Integrated

Scenario: Update run on 2026-05-07 03:04:33, kmod-evdi replaced

  • Previous version: kmod-evdi-6.19.14-300.fc44.x86_64-0:1.14.16-1.fc44.x86_64
  • Upgraded version: kmod-evdi-6.19.15-300.fc44.x86_64-0:1.14.16-1.fc44.x86_64

Issue: Display Link Driver not functioning

  • Symptoms
    – Computer on, plugged into Lenovo 40AF dock, peripherals worked, external displays did not come on. Rebooted, with dock plugged in, no effect.
  • Troubleshooting
    –systemctl status revealed that the displaylink service was masked
    –akmods --force showed the key was rejected by service

Resolution

  • kmodgenca -a and mokutil --import /etc/pki/akmods/certs/public_key.der
  • Rebooted and enrolled new MOK
  • System started normally and displaylink.service started, displays were now active
2

NOT a bug.
The evdi driver must be signed. If secure boot is disabled this is not required, but when secure boot is enabled it is mandatory.

The signing key is created by kmodgenca and enrolled into the bios by mokutil so secure boot can verify the signed module

From what repo did you get that driver package? I can’t seem to locate the rpm for fedora.

3

Yep, definitely not a bug to need to sign the driver. Somewhat new to being on Linux nearly fully time so pardon me if I say a few things wrong or if I’ve missed something obvious.

There was no change in my repos over the prior two updates which is why this losing signing threw me off. Here is the repo list I’m working from:

repo id repo name
fedora Fedora 44 - x86_64
fedora-cisco-openh264 Fedora 44 openh264 (From Cisco) - x86_64
fedora-multimedia negativo17 - Multimedia
rpmfusion-nonfree-nvidia-driver RPM Fusion for Fedora 44 - Nonfree - NVIDIA Driver
rpmfusion-nonfree-steam RPM Fusion for Fedora 44 - Nonfree - Steam
updates Fedora 44 - x86_64 - Updates
4

When I attempt to install akmod-evdi after enabling the repo fedora-multimedia I get this.

$ sudo dnf install kmod-evdi
Updating and loading repositories:
Repositories loaded.
Package                                                    Arch          Version                                                    Repository                            Size
Installing:
 kmod-evdi                                                 x86_64        1.14.16-1.fc43                                             fedora-multimedia                  0.0   B
Installing dependencies:
 akmod-evdi                                                x86_64        1.14.16-1.fc43                                             fedora-multimedia                109.7 KiB
 displaylink                                               x86_64        6.2.0-1.fc43                                               fedora-multimedia                 15.3 MiB
 libevdi                                                   x86_64        1.14.16-1.fc43                                             fedora-multimedia                 56.8 KiB
Installing weak dependencies:
 xorg-x11-displaylink                                      x86_64        6.2.0-1.fc43                                               fedora-multimedia                131.0   B

Transaction Summary:
 Installing:         5 packages

By default, when using akmod packages such as akmod-evdi the driver is built using akmods, which uses the signing key as noted above.

It seems the kmod-evdi package you have installed was built and signed by akmods from the akmod-evdi package.

I cannot explain why there would be a difference in the way the module was signed or if there even is a difference. This description of events almost seems as if you may have had secure boot disabled and might have somehow enabled it at the same time as performing the installation.

There may be similar symptoms when doing a bios firmware upgrade since that wipes out any user installed keys within bios and then would require the user repeat the mokutil import steps to enable loading locally built driver modules.

Only you would be able to identify whatever changes may have been done around the time this failure occurred, but it appears something changed related to the signing key.
Whether that was a forced change of the signing key, a bios firmware update, or a recent enabling of secure boot, it is impossible for us to tell (only the local user would know). AFAIK only one of those 3 changes would result in the symptoms and the fix you described.

5

Thanks for the detailed response! Only thing I could point to without digging too deep is if I missed a bios update that was pushed, which didn’t break anything until the update. Outside of that, secure boot was always enabled on this machine.

6

A bios update would only be performed when using fwupdmgr for some systems, or manually otherwise. It is never performed automatically. Sometimes packagekit may prompt the user to perform firmware updates but it still requires user approval before changes are done.

Generally the signing keys under /etc/pki/akmods/certs/ are only created once; either manually using kmodgenca the first time akmods is installed or automatically with the first reboot after akmods is installed.

Once that key is created and imported into bios it is always used to sign the modules and never changes unless the user either removes the old key and a new one is created automatically or kmodgenca is forced to create a new key.

Having secure boot enabled long term seems to rule out the possibility of changing its status as a possibility.

You can see how many locally created signing keys are in bios with the command
mokutil -l | grep Issuer and the ones of interest would be the ones that show your local hostname. This may be a way to identify the cause if more than one is shown as locally created.