Error out early when can't sign kernel modules

[bicarbonate]

Running the installer on a fresh F25 install returns:

[bhart@SysAdmin-02 displaylink]$ sudo ./displaylink-driver-1.2.58.run
[sudo] password for bhart: 
Verifying archive integrity... All good.
Uncompressing DisplayLink Linux Driver 1.2.58  100%  
DisplayLink Linux Software 1.2.58 install script called: install
Distribution discovered: "Fedora release 25 (Twenty Five)"
Installing
Configuring EVDI DKMS module
Registering EVDI kernel module with DKMS
Building EVDI kernel module with DKMS
Installing EVDI kernel module to kernel tree
EVDI kernel module built successfully
Installing x64-ubuntu-1404/DisplayLinkManager
Installing libraries
Installing firmware packages
Installing license file
Adding udev rule for DisplayLink DL-3xxx/5xxx devices
The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
settings in the [Install] section, and DefaultInstance for template units).
This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
   .wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
   a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
   D-Bus, udev, scripted systemctl call, ...).
4) In case of template units, the unit is meant to be enabled with some
   instance name specified.
ln: failed to create symbolic link '/lib/systemd/system-sleep/displaylink.sh': File exists
Job for dlm.service failed because the control process exited with error code.
See "systemctl status dlm.service" and "journalctl -xe" for details.
[bhart@SysAdmin-02 displaylink]$ 

I know theres no release for 25 currently.. but I wanted to ask about the section mentioning the Unit files have no install config. Is that intended? Is there anything I can do to resolve this?

[bicarbonate]

More info, 'journalctl -xe'

`-- The result is failed. Nov 05 21:38:58 SysAdmin-02 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=displaylink comm="systemd" exe="/usr/lib/systemd/sys Nov 05 21:38:58 SysAdmin-02 systemd[1]: displaylink.service: Unit entered failed state. Nov 05 21:38:58 SysAdmin-02 systemd[1]: displaylink.service: Failed with result 'exit-code'. Nov 05 21:38:58 SysAdmin-02 modprobe[7634]: modprobe: ERROR: could not insert 'evdi': Required key not available Nov 05 21:38:58 SysAdmin-02 systemd[1]: dlm.service: Control process exited, code=exited status=1 Nov 05 21:38:58 SysAdmin-02 systemd[1]: Failed to start DisplayLink Manager Service. -- Subject: Unit dlm.service has failed -- Defined-By: systemd

-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel

-- Unit dlm.service has failed. `

[bicarbonate]

Was forced to remove evdi/displaylink totally. After teh above errors I wound up disabling secure boot to resolve the 'required key not available'. Rebooting the login page I'd click on my username, type my password and hit enter and teh screen would blank off for a second then when it returns Im back at the choose user prompt. Attached is my Xorg.log file.. I had to run a 'sudo displaylink-installer' -uninstall to regain GUI login. Xorg.0 (copy).txt

and Xorg would crash.

[hadess]

There's multiple problems here, one of which we can't do anything about:

• first, we should detect that the kernel is running in Secure Boot, and disable our dkms run. We won't be able to sign the modules, so won't be able to load the necessary kernel module. That won't be a problem when evdi is upstream, and shipped as part of the distribution (https://github.com/DisplayLink/evdi/issues/25)
• secondly, the DisplayLink binary seem to think that they will be able to always successfully load the evdi kernel module. You'll need to file a bug against the proprietary parts of the DisplayLink daemon. See http://support.displaylink.com/ on how to do that.

Retitling the bug.

[bicarbonate]

Not in chronological order but I attempted the below "before" I totally disabled Secure Boot in my comment above

I found how to sign the modules outlined here in teh 3rd answer by Majal: http://askubuntu.com/questions/762254/why-do-i-get-required-key-not-available-when-install-3rd-party-kernel-modules

I no longer got the required key errors after I did this. However shortly after this.. I removed the previous versions of evdi from /usr/src/.../dkms/ Xorg would bomb out on me when trying to login. So I was forced to uninstall everything.

[ssaavedra]

The kernel module signing problem is not limited to this package but it's actually also how RPMfusion's akmods work: you may not be able to sign the modules automatically but you still build and install them, waiting for the user to sign them for you. The design problem tied to secure boot is difficult to solve because currently it's a trade-off between security and ease.

It would be nice to show some warning on installing reminding the user to sign the module, but it would be great if the rpm manager somehow warned about the issue.

[hadess]

I'm not sure where the "RPM manager" fits in when we compile the module by hand. Sure it's possible to import your own signing key, or replace the default Microsoft Secure Boot key in the BIOS, but that's not something we can automate.

We should make sure to try and load the module ourselves in the .service file, so that we don't try to run the daemon if the module isn't available (failed to compile or couldn't be loaded), so as to avoid the above crashes.

[hadess]

We should make sure to try and load the module ourselves in the .service file, so that we don't try to run the daemon if the module isn't available (failed to compile or couldn't be loaded), so as to avoid the above crashes.

Which is already what we do. I wonder if it carries on loading the daemon if ExecPreStart fails.

[ssaavedra]

From this line:

[bhart@SysAdmin-02 displaylink]$ sudo ./displaylink-driver-1.2.58.run

it is my understanding that this issue is related to DisplayLink and that you are not even using our package. Is that so, @bicarbonate ?

[ssaavedra]

Which is already what we do. I wonder if it carries on loading the daemon if ExecPreStart fails.

We do, but DisplayLink's runfile may not.

[bicarbonate]

Sorry about that, I know for a fact I tried your package and I likely tried the 'official' Ubuntu one as well for giggles. I'm going to retry yours this weekend on Fedora 24 and will report back.

[ssaavedra]

Any news here?

[ssaavedra]

Closing due to lack of feedback