On 01/24/17 04:49, Richard Shaw wrote:

On Mon, Jan 23, 2017 at 1:22 PM, Ed Greshko <ed.greshko@greshko.com> wrote:

I don't see a need for adding dkms support either. But the akmods method does need

enhancement.

1. Yes, users reboot before kmod is built. Then they panic when they have a flashing
cursor as it is being built on reboot. So, there needs to be either an inhibitor as you
mention and/or a way to inform the user on reboot that the kmod is being built.

I'll have to see about building a test package but I think I may have achieved this using systemd-inhibit within the akmodsposttrans service...

I don't know how the "systemd-inhibit" works. If it simply prevents the completion of the dnf or packaged update until the kmod is built that would be fine.

The problem/issue I see is if the user is allowed to reboot but then something happens that is out of the ordinary for them which makes them conclude their system is hung. Such as, hitting the reboot and the gui remains for an extended period. Or, hitting reboot but then having a blank screen for an extended period of time with no indication of what is going on. These things may be especially disconcerting to folks with older/slower HW.

2. Some folks will have the dnf "tracer" plugin installed. This is supposed to tell the
user what processes need to be restarted or if a reboot is needed after updates are done.
But with this plugin enabled the kmods will fail to install. So, even if the user waits
enough time for the kmods to build they won't be installed. This will again result in a
flashing cursor at reboot and panic the user that is accustomed to a quick boot process.

This is the 2nd occurrence of a problem like this that I've heard of. We could disable plugins during installation of the kmod packages BUT if we ever develop a plugin to aid in the above, then we could be back in the same situation...