Re: Need systemd unit file help.
On Mon, Sep 26, 2011 at 12:34 PM, Doug Ledford dledf...@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
Re: Need systemd unit file help.
On Mon, Sep 26, 2011 at 11:32 AM, Lennart Poettering mzerq...@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
Re: Need systemd unit file help.
On Sat, 24.09.11 08:48, Richard Shaw (hobbes1...@gmail.com) wrote: I just took over the akmods package at RPM Fusion and one of the many BZ requests is to convert it to systemd. The current suggestion is: [Unit] Description=Builds and install new kmods from akmod packages After=syslog.target (Starting with F16 After=syslog.target is not necessary anymore and should be dropped from unit file. But that's orthogonal to your mail otherwise.) Before=prefdm.service [Service] Type=oneshot ExecStart=-/usr/sbin/akmods --from-init [Install] WantedBy=multi-user.target But this only works for people using the video driver akmod packages. There are also other packages such as network drivers and possibly others. Is there some way to make this more dynamic so that the run dependencies can be defined by what akmod packages are installed? 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. 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 think I remember reading a thread where one unit file can call other unit files? Is there some way to setup a akmods.d/ type directory where the individual akmod driver packages can stick unit files? You can do something similar the way Michal suggested. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need systemd unit file help.
- 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. 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. Because a kernel install can happen after the package that rebuilds the module is installed and the kernel rpm doesn't itself build these modules. Now, you might be able to use a %trigger in rpm, but in general, several people in the past have resorted to boot time builds so that if you boot up on a new kernel and the custom driver was already installed, then the custom drivers get built for the new kernel. In some cases (although it can probably be argued this is a bad driver make process), the driver might require the running kernel be what it is building for and then you would *have* to wait until the first time that particular kernel is booted to build the module. So, long story short, there are difficulties, not the least of which is the poorly understood usage of the %trigger capabilities in rpm. -- Doug Ledford dledf...@redhat.com GPG KeyID: CFBFF194 http://people.redhat.com/dledford -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need systemd unit file help.
Am 26.09.2011 18:32, schrieb Lennart Poettering: 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. because akmods is used to build kernel-modules after the kernel was updated and the komd-package not - this was before vmxnet3 as example hardly needed for vmware because without network yum makes no fun another example are the nvidia-drivers - for normal users it is not acceptable have no GUI after update / reboot normally the kmod-packages are updated the same time as the kernel in stable repos, but you can not guarantee this for external repos everytime, especially that the mirror you catched is recent enough signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need systemd unit file help.
Reindl Harald wrote: because akmods is used to build kernel-modules after the kernel was updated and the komd-package not - this was before vmxnet3 as example hardly needed for vmware because without network yum makes no fun another example are the nvidia-drivers - for normal users it is not acceptable have no GUI after update / reboot normally the kmod-packages are updated the same time as the kernel in stable repos, but you can not guarantee this for external repos everytime, especially that the mirror you catched is recent enough But akmods are a very hackish solution to that problem. Building modules on the end user system sucks on a binary distribution. It drags in the whole GCC toolchain, kernel-devel and the source code for the modules and the whole system is a huge kludge, as evidenced also by this thread. 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. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need systemd unit file help.
On Mon, Sep 26, 2011 at 2:54 PM, Kevin Kofler kevin.kof...@chello.at wrote: But akmods are a very hackish solution to that problem. Building modules on the end user system sucks on a binary distribution. It drags in the whole GCC toolchain, kernel-devel and the source code for the modules and the whole system is a huge kludge, as evidenced also by this thread. Yes, but it works :) 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? Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 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
Re: Need systemd unit file help.
On Mon, Sep 26, 2011 at 3:07 PM, Pierre-Yves Chibon pin...@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
Re: 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
Re: Need systemd unit file help.
Am 26.09.2011 21:54, schrieb Kevin Kofler: Reindl Harald wrote: normally the kmod-packages are updated the same time as the kernel in stable repos, but you can not guarantee this for external repos everytime, especially that the mirror you catched is recent enough But akmods are a very hackish solution to that problem. Building modules on the end user system sucks on a binary distribution. It drags in the whole GCC toolchain, kernel-devel and the source code for the modules and the whole system is a huge kludge, as evidenced also by this thread. 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. well - nobody is forcing you to use akmod there are kmod-open-vm-tools AND akmod-open-vm-tools as example i have the akmod-packages on the buildmachine if there is an important security-kernel-update and kmod packages not available this machine builds the binaries the other machines get the kernel-update via deployment-scripts AND the pre-compiled kernel-modules from akmod signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need systemd unit file help.
On Sat, 24 Sep 2011 08:48:16 -0500 Richard Shaw wrote: I just took over the akmods package at RPM Fusion and one of the many BZ requests is to convert it to systemd. The current suggestion is: [Unit] Description=Builds and install new kmods from akmod packages After=syslog.target Before=prefdm.service [Service] Type=oneshot ExecStart=-/usr/sbin/akmods --from-init [Install] WantedBy=multi-user.target But this only works for people using the video driver akmod packages. There are also other packages such as network drivers and possibly others. Is there some way to make this more dynamic so that the run dependencies can be defined by what akmod packages are installed? I think I remember reading a thread where one unit file can call other unit files? Is there some way to setup a akmods.d/ type directory where the individual akmod driver packages can stick unit files? You can have every akmod-* package ship a /lib/systemd/system/akmod-*.target file to specify the ordering, e.g. akmod-foo-video-driver.target: [Unit] Description=akmod for foo After=akmods.service Before=prefdm.service And ship a symlink /lib/systemd/system/akmods.service.wants/akmod-*.target Or, instead of building all the modules from akmods.service, you can build them using 'akmods --akmod ...' from their own akmod-*.service where the ordering will be defined as needed. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need systemd unit file help.
On Sun, Sep 25, 2011 at 7:01 AM, Michal Schmidt mschm...@redhat.com wrote: You can have every akmod-* package ship a /lib/systemd/system/akmod-*.target file to specify the ordering, e.g. akmod-foo-video-driver.target: [Unit] Description=akmod for foo After=akmods.service Before=prefdm.service And ship a symlink /lib/systemd/system/akmods.service.wants/akmod-*.target So this method will run on the earliest requirement of all installed akmod packages? Or, instead of building all the modules from akmods.service, you can build them using 'akmods --akmod ...' from their own akmod-*.service where the ordering will be defined as needed. Here they provide their own .service file and akmods could be run more than once during boot if the user has more than one akmod package installed? I like the first option because it seems more elegant, but also more complicated. I like the second option because it puts the onus of getting the .service file right on the maintainer of the driver package and not me :) Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need systemd unit file help.
Richard Shaw wrote: On Sun, Sep 25, 2011 at 7:01 AM, Michal Schmidt mschm...@redhat.com wrote: Or, instead of building all the modules from akmods.service, you can build them using 'akmods --akmod ...' from their own akmod-*.service where the ordering will be defined as needed. Here they provide their own .service file and akmods could be run more than once during boot if the user has more than one akmod package installed? I think the idea is to run it only for each specific akmod, not for all at once. I like the first option because it seems more elegant, but also more complicated. I like the second option because it puts the onus of getting the .service file right on the maintainer of the driver package and not me :) I think the second option is more elegant, it fits more into the spirit of parallelized boot. I guess it even allows building independent akmods in parallel. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Need systemd unit file help.
I just took over the akmods package at RPM Fusion and one of the many BZ requests is to convert it to systemd. The current suggestion is: [Unit] Description=Builds and install new kmods from akmod packages After=syslog.target Before=prefdm.service [Service] Type=oneshot ExecStart=-/usr/sbin/akmods --from-init [Install] WantedBy=multi-user.target But this only works for people using the video driver akmod packages. There are also other packages such as network drivers and possibly others. Is there some way to make this more dynamic so that the run dependencies can be defined by what akmod packages are installed? I think I remember reading a thread where one unit file can call other unit files? Is there some way to setup a akmods.d/ type directory where the individual akmod driver packages can stick unit files? Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
