On Qua, 2016-09-14 at 21:56 +0200, Nicolas Chauvet wrote:
2016-09-14 20:43 GMT+02:00 Sérgio Basto <sergio(a)serjux.com>:
>
> On Qua, 2016-09-14 at 13:16 -0500, Richard Shaw wrote:
>
> On Wed, Sep 14, 2016 at 12:12 PM, Nicolas Chauvet <kwizart(a)gmail.co
> m> wrote:
>
> 2016-09-14 18:01 GMT+02:00 Richard Shaw <hobbes1069(a)gmail.com>:
> >
> > I've had a few failures but not really sure as to the cause, but
> > I've been
> > toying around with doing the final RPM install with a systemd
> > service
> > instead of calling dnf directly with the kernel posttrans script.
> >
> > Thoughts? Pitfalls?
> I really don't understand the method here.
> Can you reproduce any issue ? or do you have received informal
> informations that the posttrans script wasn't working for a reason
> ?
> Because for now It's working fine with me all the time, so there is
> probably an unknown corner case here.
>
>
> Reproduce, no, but I've had a couple of occasions where I was not
> able to
> get to graphical boot. I just read about the need to run depmod on
> a Fedora
> thread. I didn't think about that so I manually erased the RPMs and
> let
> akmod rebuild them which fixed the problem.
>
>
> yes , after install kmod you should load the kmods modules , it may
> work
> without it , because X load it but we should ensure modprobe
> nvidia.ko (not
> depmod .. )
The documentation has always said that you need to reboot once the
driver is installed/updated (and immediately after).
1/ Because that's easier than to restart any process that have the
wrong (mesa) libGL.
2/ Because nvidia driver use some kind of contiguous memory that
might
not be available after the boot.
3/ Because it relies on certains kernel boot options that was set by
the package, so you need to reboot anyway.
>
> for example VirtualBox instructions:
>
> dnf install VirtualBox kernel-devel-$(uname -r) akmod-
> VirtualBox
> akmods
> systemctl restart systemd-modules-load.service
It could be possible to use a trigger on systemd-modules-load.service
after kmod-foo will install.
At least it would be a generic way to solve the problem when a given
kmod drops a /usr/lib/modules-load.d file
This should be handled by kmodtool at least. But I would prefer that
a
reboot is documented (the less is done on user's back, the better).
I can add akmod-VirtualBox to the main package VirtualBox.spec.
When we got foo-kmodsrc package we could and should build just one
akmod-foo. The source of akmod-VirtualBox-5.1.6-1 is VirtualBox-kmod-
5.1.6-1.fc23.src.rpm , VirtualBox-kmod-5.1.6-1.fc23.src.rpm got
VirtualBox-kmod.spec and VirtualBox-OSE-kmod-1.6.4-kernel-variants.txt
(this VirtualBox-OSE-kmod-1.6.4-kernel-variants.txt is the same for
years and have 4 bytes, we may eliminate easily)
# kmodtool does its magic here
%{expand:%(kmodtool --target %{_target_cpu} --repo rpmfusion --kmodname
%{name} %{?buildforkernels:--%{buildforkernels}} %{?kernels:--for-
kernels "%{?kernels}"} --filterfile %{SOURCE1} 2>/dev/null) }
kmodtool produce an template scriplet under the spec itself with expand
and build the kmod rpm using the command '/sbin/akmodsbuild --target
x86_64 --kernels 4.5.7-202.fc23.x86_64 /usr/src/akmods/VirtualBox-
kmod.latest' where VirtualBox-kmod.latest is a symlink to VirtualBox-
kmod-5.1.6-1.fc23.src.rpm
So we just build onetime akmod (in main package) we may produce kmods
with
akmodsbuild --target x --kernel y VirtualBox-kmod-5.1.6-
1.fc23.src.rpm (which is in akmod-VirtualBox)
I think we save some loops in the code, I'm a little tired , if I don't
explain well please ask me to explain again please, also seems to me
kmodtool could be in same package of akmods.
Also have the benefit that we may enable debuginfo builds , and since
we don't produce pre-built kmods (yet?) also we just need update one
package instead two.
Cheers,
--
Sérgio M. B.