6:35 p.m.
I'm not sure who's followed the discussion on fedora-devel so I'll recap
here:
We basically have two options:
1. Require that the akmod driver packages pack an
akmod-<pkgname>.target file that gets symlinked to
"/lib/systemd/system/akmods.service.wants/"
Which should run once on the earliest requirement.
OR
2. Have each akmod driver package package it's own service unit file
(<pkgname>.service) which will run base on it's own need (if multiple
akmod packages are installed, akmods will get run more than once).
Personally, I like #2 better but I'm open to suggestion.
I think the plan would be:
1. File a bug against each akmod driver package to get a .service file
included in the package. I'll provide a template to follow to make
this as easy as possible.
2. I'll leave the akmod service on for the time being as a catch-all
until #1 is complete.
The next question is what fedora version is the target? I think the
current policy would allow this for F16 since it hasn't been released
yet, but we're quickly running out of time.
Does anyone have an athoratative list of akmod packages? I get the following:
# yum list akmod-*
[SNIP]
akmod-nvidia.x86_64 1:280.13-2.fc15.2 @rpmfusion-nonfree-updates
akmod-VirtualBox-OSE.x86_64 4.0.4-2.fc15 rpmfusion-free
akmod-catalyst.x86_64 11.7-1.fc15 rpmfusion-nonfree-updates
akmod-ndiswrapper.x86_64 1.56-1.fc15.2 rpmfusion-free
akmod-nvidia-173xx.x86_64 173.14.31-1.fc15 rpmfusion-nonfree-updates
akmod-openafs.x86_64 1.6.0-0.pre4.fc15.1 rpmfusion-free
akmod-rt2860.x86_64 2.4.0.0-2.fc15 rpmfusion-free
akmod-rt2870.x86_64 2.4.0.1-2.fc15 rpmfusion-free
akmod-rt3070.x86_64 2.3.0.4-2.fc15 rpmfusion-free
akmod-wl.x86_64 5.60.48.36-2.fc15.1 rpmfusion-nonfree
Thanks,
Richard
8:51 p.m.
If no one pipes up I'm going to assume silence means agreement. :)
Along those lines I think I have several of the akmods bugs taken care
of so I'll probably build packages at least for devel/rawhide soon for
testing since they need to be pushed out to users regardless of the
systemd conversion.
Any brave souls want to test it out?
Richard
9:41 p.m.
2011/9/27 Richard Shaw <hobbes1069(a)gmail.com>:
If no one pipes up I'm going to assume silence means agreement.
:)
Along those lines I think I have several of the akmods bugs taken care
of so I'll probably build packages at least for devel/rawhide soon for
testing since they need to be pushed out to users regardless of the
systemd conversion.
Any brave souls want to test it out?
Richard
I don't know how many akmod users really built their modules at the boot step.
Akmods is supposed to "trigger" a packaged kernel installation and
rebuilt the specific akmod packages, so in "most ?" situations, the
modules are supposed to be already available on early boot if not in
initramfs.
This will probably not work when kernel is not packaged or packaged in
a way that doesn't know /etc/kernel/* scripts.
On the opposite side, we could still consider to build the module on
stop and implement a fallback to deselect the latest kernel if some
modules fail to build for any reason.
The problem with the build on boot is that if something goes wrong,
it's probably already too late and it is very annoying to recover from
there. But It can still be possible to reload prefdm or the network
and that should cover the most case when the build succeed.
So I think only the akmods package should have an units file for now
and see how it goes and if using a specific unit for each akmod really
worth it.
Nicolas (kwizart)
1:45 p.m.
On Tue, Sep 27, 2011 at 4:41 PM, Nicolas Chauvet <kwizart(a)gmail.com> wrote:
I don't know how many akmod users really built their modules at
the boot step.
Akmods is supposed to "trigger" a packaged kernel installation and
rebuilt the specific akmod packages, so in "most ?" situations, the
modules are supposed to be already available on early boot if not in
initramfs.
This begs the question: If it's supposed to be built upon kernel
install then do we even really need a service? If the correct files
are not available on kernel install then why would they all of a
sudden available after a reboot?
This will probably not work when kernel is not packaged or packaged
in
a way that doesn't know /etc/kernel/* scripts.
If' someone is running a from scratch kernel, should we even try to
support that usage? I would think people using a non-packaged kernel
should know how to take care of building kernel modules themselves.
On the opposite side, we could still consider to build the module on
stop and implement a fallback to deselect the latest kernel if some
modules fail to build for any reason.
The problem with the build on boot is that if something goes wrong,
it's probably already too late and it is very annoying to recover from
there. But It can still be possible to reload prefdm or the network
and that should cover the most case when the build succeed.
Agreed.
So I think only the akmods package should have an units file for now
and see how it goes and if using a specific unit for each akmod really
worth it.
Maybe we should run on shutdown instead of boot? This should be pretty
easily done with systemd...
One other option. It was mentioned on fedora-devel that %trigger in
the akmods spec might be the better option than relying on
/etc/kernel/postinst.d/ but I'm not sure how that would work with
needing to install a package...
Richard
4804
days inactive
4806
days old
rpmfusion-developers@lists.rpmfusion.org
3 comments
2 participants
participants (2)
-
Nicolas Chauvet -
Richard Shaw