8:43 a.m.
I would like to implement DKMS support for the nvidia driver.
Adding the support would add much to the work load and would offer users the choice of
what they use.
The other benefit is I believe it will work better with offline updates as it builds
during the transaction.
9:26 a.m.
Hi,
On 23-01-17 09:43, Leigh Scott wrote:
I would like to implement DKMS support for the nvidia driver.
Adding the support would add much to the work load and would offer users the choice of
what they use.
The other benefit is I believe it will work better with offline updates as it builds
during the transaction.
+1 from me, I see now problems with adding DKMS support as an option,
https://rpmfusion.org/Packaging/KernelModules/Kmods2#Why_not_simply_use_dkms
Even recommends offering it as an option.
Regards,
Hans
12:59 p.m.
2017-01-23 9:43 GMT+01:00 Leigh Scott <leigh123linux(a)googlemail.com>:
I would like to implement DKMS support for the nvidia driver.
Adding the support would add much to the work load and would offer users the choice of
what they use.
Still relevant today: http://www.islinuxaboutchoice.com/
Quoting:
"Software is hard. The way to fix it is to fix it, not sweep it under the
rug."
I'm not opposed to this, but I'm not fond of either. I prefer to only
have one codepath and fix it instead of two unfixed.
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).
- 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.
- Probably the akmod script should be triggered earlier (as soon as
the kernel-devel is installed , instead of a kernel postrans). Then
hold a lock on dnf so it can install right after the transaction ends.
- Need better testing with offline update, but assuming dkms work
wihtout testing it is not an acceptable argument.
Those issues affect all akmod users, so they won't be perfectly hidden
under the carpet by just migrating nvidia.
So I'm not fund of moving to dkms, but I won't hold the proposition
either. It means +0 for me.
--
-
Nicolas (kwizart)
2:05 p.m.
On Mon, Jan 23, 2017 at 6:59 AM, Nicolas Chauvet <kwizart(a)gmail.com> wrote:
2017-01-23 9:43 GMT+01:00 Leigh Scott
<leigh123linux(a)googlemail.com>:
> I would like to implement DKMS support for the nvidia driver.
> Adding the support would add much to the work load and would offer users
the choice of what they use.
Still relevant today: http://www.islinuxaboutchoice.com/
Quoting:
"Software is hard. The way to fix it is to fix it, not sweep it under the
rug."
I'm not opposed to this, but I'm not fond of either. I prefer to only
have one codepath and fix it instead of two unfixed.
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.
- 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)...
for module in $(ls /usr/lib/modules/$(uname -r)/extra/)
do modprobe $module
done
Or something to that effect.
- Probably the akmod script should be triggered earlier (as soon as
the kernel-devel is installed , instead of a kernel postrans). Then
hold a lock on dnf so it can install right after the transaction ends.
- Need better testing with offline update, but assuming dkms work
wihtout testing it is not an acceptable argument.
Even better would be a way to add a package to the current transaction but
that would be very complicated...
Thanks,
Richard
7:22 p.m.
On 01/23/17 20:59, Nicolas Chauvet wrote:
2017-01-23 9:43 GMT+01:00 Leigh Scott
<leigh123linux(a)googlemail.com>:
> I would like to implement DKMS support for the nvidia driver.
> Adding the support would add much to the work load and would offer users the choice
of what they use.
Still relevant today: http://www.islinuxaboutchoice.com/
Quoting:
"Software is hard. The way to fix it is to fix it, not sweep it under the
rug."
I'm not opposed to this, but I'm not fond of either. I prefer to only
have one codepath and fix it instead of two unfixed.
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).
- 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.
- Probably the akmod script should be triggered earlier (as soon as
the kernel-devel is installed , instead of a kernel postrans). Then
hold a lock on dnf so it can install right after the transaction ends.
- Need better testing with offline update, but assuming dkms work
wihtout testing it is not an acceptable argument.
Those issues affect all akmod users, so they won't be perfectly hidden
under the carpet by just migrating nvidia.
So I'm not fund of moving to dkms, but I won't hold the proposition
either. It means +0 for me.
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.
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.
8:49 p.m.
On Mon, Jan 23, 2017 at 1:22 PM, Ed Greshko <ed.greshko(a)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...
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...
Thanks,
Richard
9:56 p.m.
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...
10 p.m.
On Mon, Jan 23, 2017 at 3:56 PM, Ed Greshko <ed.greshko(a)greshko.com> wrote:
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>
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.
Nothing to do with DNF, haven't found a solution to that one yet. It
inhibits shutdown/reboot until the command completes. I need to test it
with a fake setup perhaps /usr/bin/sleep 3600 and see if I get any kind of
GUI prompt about what is going on, it does have some command line options I
assume are used to display to the user.
Thanks,
Richard
12:19 a.m.
On 01/24/17 06:00, Richard Shaw wrote:
Nothing to do with DNF, haven't found a solution to that one yet.
It inhibits
shutdown/reboot until the command completes. I need to test it with a fake setup perhaps
/usr/bin/sleep 3600 and see if I get any kind of GUI prompt about what is going on, it
does have some command line options I assume are used to display to the user.
I did not know systemd-inhibit was a command. I'm not so sure how good it will be as
I
just tried the following from a KDE session.
1. Log-in
2. Bring up a konsole and su to root.
3. Enter the command "systemd-inhibit /usr/bin/sleep 120"
4. Go to the KDE menu and "Leave--->Reboot" then confirm reboot.
5. Result - KDE session ends, screen blanks for a few seconds, login screen appears and
the system never reboots.
2 p.m.
On Mon, Jan 23, 2017 at 6:19 PM, Ed Greshko <ed.greshko(a)greshko.com> wrote:
On 01/24/17 06:00, Richard Shaw wrote:
> Nothing to do with DNF, haven't found a solution to that one yet. It
inhibits
> shutdown/reboot until the command completes. I need to test it with a
fake setup perhaps
> /usr/bin/sleep 3600 and see if I get any kind of GUI prompt about what
is going on, it
> does have some command line options I assume are used to display to the
user.
>
I did not know systemd-inhibit was a command. I'm not so sure how good it
will be as I
just tried the following from a KDE session.
1. Log-in
2. Bring up a konsole and su to root.
3. Enter the command "systemd-inhibit /usr/bin/sleep 120"
4. Go to the KDE menu and "Leave--->Reboot" then confirm reboot.
5. Result - KDE session ends, screen blanks for a few seconds, login
screen appears and
the system never reboots.
Interesting... Using my new kernel posttrans method I did a kernel
reinstall which initiated a build of the nvidia kmod and immediately gave
the reboot command. Systemd closed the SSH session so I assumed that it
didn't work but when the system came back up the new kmod package was
installed and when I got home from work the X was up without issue so it
seemed to work for me.
At least it wouldn't have let you shut down the system during the build
process but I had hoped the integration would have been better.
You could try using the --who --why options and see if something is
presented to the user...
Thanks,
Richard
7:14 p.m.
I didn't bother with a github side branch for such a simple addition but
here's the scratch build...
http://koji.rpmfusion.org/kojifiles/work/tasks/5063/75063/akmods-0.5.7-0....
And if you want to look at the "source" files first....
http://koji.rpmfusion.org/kojifiles/work/tasks/5063/75063/akmods-0.5.7-0....
Thanks,
Richard
1:57 p.m.
On Wed, Jan 25, 2017 at 3:31 AM, Nicolas Chauvet <kwizart(a)gmail.com> wrote:
2017-01-24 20:14 GMT+01:00 Richard Shaw
<hobbes1069(a)gmail.com>:
> I didn't bother with a github side branch for such a simple addition but
Sorry, but if you want a review from the community you have to do a
minimal effort.
I thought you might object :)
I'm not a git expert, I know enough for packaging/SCM purposes and a little
more. I don't see that I have access to create a branch on rpmfusion/akmods
on github. Are you asking me to fork and do a pull request?
Thanks,
Richard
2:13 p.m.
2017-01-25 14:57 GMT+01:00 Richard Shaw <hobbes1069(a)gmail.com>:
On Wed, Jan 25, 2017 at 3:31 AM, Nicolas Chauvet
<kwizart(a)gmail.com> wrote:
>
> 2017-01-24 20:14 GMT+01:00 Richard Shaw <hobbes1069(a)gmail.com>:
> > I didn't bother with a github side branch for such a simple addition but
> Sorry, but if you want a review from the community you have to do a
> minimal effort.
I thought you might object :)
Please fork from your github account push there:
git checkout test-01
git add remote github git@github.com:hobbes1069/akmods.git
git push github test-01
Thx
--
-
Nicolas (kwizart)
2650
days inactive
2654
days old
rpmfusion-developers@lists.rpmfusion.org
15 comments
5 participants
participants (5)
-
Ed Greshko -
Hans de Goede -
Leigh Scott -
Nicolas Chauvet -
Richard Shaw