FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 09-26-2011, 08:07 PM
Pierre-Yves Chibon
 
Default Need systemd unit file help.

On Mon, 2011-09-26 at 15:00 -0500, Richard Shaw wrote:
> > The right solution is for the user to just uncheck the kernel from
> the list
> > of packages to update in the PackageKit GUI of choice (be it gnome-
> > packagekit, KPackageKit or Apper) if the kmod doesn't show up along
> with it.
> > It's not rocket science.
>
> No, it's not rocket science, but it does require manual intervention
> on the part of the user who may or may not understand the relationship
> between the kmod driver and the kernel. Shouldn't updating (by kmod,
> or akmod) be more or less transparent to the end user?

Then maybe we could add some logic into yum that (a)kmod could come with
a configuration file which does this (ie: blocking the kernel from
updating until the corresponding (a)kmod is available).

Pierre
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-26-2011, 08:21 PM
Richard Shaw
 
Default Need systemd unit file help.

On Mon, Sep 26, 2011 at 3:07 PM, Pierre-Yves Chibon <pingou@pingoured.fr> wrote:
> On Mon, 2011-09-26 at 15:00 -0500, Richard Shaw wrote:
>> > The right solution is for the user to just uncheck the kernel from
>> the list
>> > of packages to update in the PackageKit GUI of choice (be it gnome-
>> > packagekit, KPackageKit or Apper) if the kmod doesn't show up along
>> with it.
>> > It's not rocket science.
>>
>> No, it's not rocket science, but it does require manual intervention
>> on the part of the user who may or may not understand the relationship
>> between the kmod driver and the kernel. Shouldn't updating (by kmod,
>> or akmod) be more or less transparent to the end user?
>
> Then maybe we could add some logic into yum that (a)kmod could come with
> a configuration file which does this (ie: blocking the kernel from
> updating until the corresponding (a)kmod is available).

I would think this has been discussed before... But to play devil's
advocate. What if someone is running a modified kernel? Sure if they
know how to do that then they should know how to update their drivers
prior to installing it, but in that case akmods is more of a
package/tool of convenience.

Richard
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-26-2011, 08:30 PM
Simo Sorce
 
Default Need systemd unit file help.

On Mon, 2011-09-26 at 21:54 +0200, Kevin Kofler wrote:
> The right solution is for the user to just uncheck the kernel from the
> list
> of packages to update in the PackageKit GUI of choice (be it gnome-
> packagekit, KPackageKit or Apper) if the kmod doesn't show up along
> with it.
> It's not rocket science.

... says the rocket engineer ...

Simo.

--
Simo Sorce * Red Hat, Inc * New York

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-28-2011, 01:52 PM
Richard Shaw
 
Default Need systemd unit file help.

On Mon, Sep 26, 2011 at 11:32 AM, Lennart Poettering
<mzerqung@0pointer.de> wrote:
> My question to you: why are these modules built at boot time at all? Why
> not at install time? Seems like the more appropriate time to me, given
> that the set of kernel packages does not change during boot, but only at
> install time.

I'm still learning about the package but it appears that the build on
boot is really just a catch-all. There's actually a script it puts in
/etc/kernels/postinst.d/ in order to rebuild the kernel modules after
a new kernel install.

I think the problem is that sometimes a new kernel is installed
(testing or other manual method) that doesn't pull in the kernel-devel
package... of course, if that's not corrected before reboot then the
run on boots going to fail as well.

Thanks,
Richard
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-28-2011, 01:56 PM
Richard Shaw
 
Default Need systemd unit file help.

On Mon, Sep 26, 2011 at 12:34 PM, Doug Ledford <dledford@redhat.com> wrote:
> ----- Original Message -----
>> Well, you can move your service into the early boot part if
>> necessary. However, there's a fundamental problem here: iiuc you
>> compile
>> driver modules at boot and want them recognized by the system during
>> the
>> same boot run. That's hardly possible though. To compile your modules
>> you probably need the full set of file systems around (i.e. /var and
>> /tmp), but that's only available after udev was started and driver
>> loading triggered. So the earliest time you can build the drivers is
>> already too late to load them properly.
>
> You can always trigger the device you are building for again once the build is complete.

Do you have some hints or a link describing how to do that?


> So, long story short, there are difficulties, not the least of which is the poorly understood usage of the %trigger capabilities in rpm.

I've read up a little on %trigger but I'm not sure if it can be used
in this case since akmods basically builds an RPM package from a
source RPM package and installs it. If I try to use %triggerin then
I'm already in an RPM session so I don't know how I could trigger an
install. Currently akmods gets around that by putting a script in
/etc/kernel/postinst.d/.

If %trigger can handle this then I'd really like to know how because
that would help fix the problem of a new kernel install without the
accompanying kernel-devel package.

Thanks,
Richard
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 03:59 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org