On 01/24/17 04:49, Richard Shaw wrote:
On Mon, Jan 23, 2017 at 1:22 PM, Ed Greshko
<ed.greshko(a)greshko.com
<mailto: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...