On Mon, Jan 23, 2017 at 6:59 AM, Nicolas Chauvet <kwizart(a)gmail.com> wrote:
...
> So to be more accurate, I don't think the recent issue raised
by
> akmods users can be solved by dkms.
> - Users reboot before the kmod is built by akmod for the next kernel
> (we need to implement inhibitor for that).
I'm still experimenting with my setup to use a systemd service instead of
just running the akmods script via kernel posttrans. So far it seems to work
but I'm nervous about implementing it without wider testing. I may create a
test package for some brave souls. It does specifically have a conflict with
the shutdown target but I'm not sure if that would inhibit and attempted
shutdown/reboot or not.
If you feel you need your changes to be reviewed, please
push a side
branch on github and do a koji scratch build.
I prefer that over pushing untested changes in our packages.
> - module isn't loaded if build/install is occurring during
boot.
> (previous workaround was to have an explicit modprobe nvidia after
> akmod.service, there is a need for a better workaround).
> I've tried to contact some at #nouveau, there is a need to dive into
> the nouveau drm code. What I would expect is a userspace tool to
> trigger (again) the kernel module loading mechanism on related
> hardware.
Are you completely against the modprobe method universially or because it
was done blindly? I could come up with a script that would only perform the
modprobe if there was a module to load (and make it more universal)...
The problem
with this modprobe nvidia method is that it's indeed blind.
for module in $(ls /usr/lib/modules/$(uname -r)/extra/)
do modprobe $module
done
Or something to that effect.
Actually , it could be a better way to solve the
problem, once it can
check which kmod(s) is(are) actually installed.
In the nvidia cases, there are now 3 kernel modules, so the loading