yet another propose Re: Akmods run RPM install as service?

[Sérgio Basto]

On Qua, 2016-09-14 at 21:56 +0200, Nicolas Chauvet wrote:
> 2016-09-14 20:43 GMT+02:00 Sérgio Basto <sergio at 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 at gmail.co
> > m> wrote:
> > 
> > 2016-09-14 18:01 GMT+02:00 Richard Shaw <hobbes1069 at 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: VirtualBox.spec.patch
Type: text/x-patch
Size: 2631 bytes
Desc: not available
URL: <https://lists.rpmfusion.org/pipermail/rpmfusion-developers/attachments/20160915/453fc453/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: VirtualBox-kmod.spec.tmpl.patch
Type: text/x-patch
Size: 1793 bytes
Desc: not available
URL: <https://lists.rpmfusion.org/pipermail/rpmfusion-developers/attachments/20160915/453fc453/attachment-0001.bin>
-------------- next part --------------
xen