On 6 July 2015 at 11:53, Ed Greshko <ed.greshko(a)greshko.com&gt; wrote: Sounds good Ed - sorry to sound so ignorant. "As suggested in akmods.log"... no such file found on my F22 install? What does 'manually do it' mean please? TiA -- Dave Pawson XSLT XSL-FO FAQ. Docbook FAQ. http://www.dpawson.co.uk

Thanks Ed. That's quite a long list... In which order please - top of file down or last upwards? All have the same timestamp? 2015/07/02 06:53:36 akmods: Building RPM using the command '/bin/akmodsbuild --target x86_64 --kernels 4.0.6-300.fc22.x86_64 /usr/src/akmods/nvidia-kmod.latest' 2015/07/02 06:53:50 akmodsbuild: * Rebuilding /usr/src/akmods/nvidia-kmod.latest for kernel(s) 4.0.6-300.fc22.x86_64: warning: user mockbuild does not exist - using root 2015/07/02 06:53:50 akmodsbuild: warning: group mockbuild does not exist - using root 2015/07/02 06:53:50 akmodsbuild: warning: user mockbuild does not exist - using root 2015/07/02 06:53:50 akmodsbuild: warning: group mockbuild does not exist - using root 2015/07/02 06:53:50 akmodsbuild: warning: user mockbuild does not exist - using root 2015/07/02 06:53:50 akmodsbuild: warning: group mockbuild does not exist - using root 2015/07/02 06:53:50 akmodsbuild: Installing /usr/src/akmods/nvidia-kmod.latest 2015/07/02 06:53:50 akmodsbuild: Building target platforms: x86_64 2015/07/02 06:53:50 akmodsbuild: Building for target x86_64 2015/07/02 06:53:50 akmodsbuild: Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.v7umVj 2015/07/02 06:53:50 akmodsbuild: + umask 022 2015/07/02 06:53:50 akmodsbuild: + cd /tmp/akmodsbuild.wv915hso//BUILD 2015/07/02 06:53:50 akmodsbuild: + kmodtool --target x86_64 --repo rpmfusion --kmodname nvidia-kmod --filterfile /tmp/akmodsbuild.wv915hso/SOURCES/nvidia-kmodtool-excludekernel-filterfile --obsolete-name nvidia-newest --obsolete-version 346.72 --for-kernels 4.0.6-300.fc22.x86_64 2015/07/02 06:53:50 akmodsbuild: %package -n kmod-nvidia-4.0.6-300.fc22.x86_64 2015/07/02 06:53:50 akmodsbuild: Summary: nvidia kernel module(s) for 4.0.6-300.fc22.x86_64 2015/07/02 06:53:50 akmodsbuild: Group: System Environment/Kernel 2015/07/02 06:53:50 akmodsbuild: Provides: kernel-modules-for-kernel = 4.0.6-300.fc22.x86_64 2015/07/02 06:53:50 akmodsbuild: Provides: nvidia-kmod = %{?epoch:%{epoch}:}%{version}-%{release} 2015/07/02 06:53:50 akmodsbuild: Requires: nvidia-kmod-common 2015/07/02 06:53:50 akmodsbuild: Requires(post): /usr/sbin/depmod 2015/07/02 06:53:50 akmodsbuild: Requires(postun): /usr/sbin/depmod 2015/07/02 06:53:50 akmodsbuild: Provides: kmod-nvidia-newest-4.0.6-300.fc22.x86_64 = 346.72 2015/07/02 06:53:50 akmodsbuild: Obsoletes: kmod-nvidia-newest-4.0.6-300.fc22.x86_64 < 346.72 2015/07/02 06:53:50 akmodsbuild: Requires: kernel-uname-r = 4.0.6-300.fc22.x86_64 2015/07/02 06:53:50 akmodsbuild: BuildRequires: kernel-devel-uname-r = 4.0.6-300.fc22.x86_64 2015/07/02 06:53:50 akmodsbuild: %post -n kmod-nvidia-4.0.6-300.fc22.x86_64 2015/07/02 06:53:50 akmodsbuild: /usr/sbin/depmod -aeF /boot/System.map-4.0.6-300.fc22.x86_64 4.0.6-300.fc22.x86_64 > /dev/null || : 2015/07/02 06:53:50 akmodsbuild: %postun -n kmod-nvidia-4.0.6-300.fc22.x86_64 2015/07/02 06:53:50 akmodsbuild: /usr/sbin/depmod -aF /boot/System.map-4.0.6-300.fc22.x86_64 4.0.6-300.fc22.x86_64 &> /dev/null || : 2015/07/02 06:53:50 akmodsbuild: 2015/07/02 06:53:50 akmodsbuild: %description -n kmod-nvidia-4.0.6-300.fc22.x86_64 2015/07/02 06:53:50 akmodsbuild: This package provides the nvidia kernel modules built for the Linux 2015/07/02 06:53:50 akmodsbuild: kernel 4.0.6-300.fc22.x86_64 for the %{_target_cpu} family of processors. 2015/07/02 06:53:50 akmodsbuild: %files -n kmod-nvidia-4.0.6-300.fc22.x86_64 2015/07/02 06:53:50 akmodsbuild: %defattr(644,root,root,755) 2015/07/02 06:53:50 akmodsbuild: %dir /usr/lib/modules/4.0.6-300.fc22.x86_64/extra 2015/07/02 06:53:50 akmodsbuild: /usr/lib/modules/4.0.6-300.fc22.x86_64/extra/nvidia/ 2015/07/02 06:53:50 akmodsbuild: 2015/07/02 06:53:50 akmodsbuild: 2015/07/02 06:53:50 akmodsbuild: 2015/07/02 06:53:50 akmodsbuild: %global kmodinstdir_prefix /usr/lib/modules/ 2015/07/02 06:53:50 akmodsbuild: %global kmodinstdir_postfix /extra/nvidia/ 2015/07/02 06:53:50 akmodsbuild: %global kernel_versions 4.0.6-300.fc22.x86_64___%{_usrsrc}/kernels/4.0.6-300.fc22.x86_64 2015/07/02 06:53:50 akmodsbuild: 2015/07/02 06:53:50 akmodsbuild: + cd /tmp/akmodsbuild.wv915hso/BUILD 2015/07/02 06:53:50 akmodsbuild: + rm -rf nvidia-kmod-346.72 2015/07/02 06:53:50 akmodsbuild: + /usr/bin/mkdir -p nvidia-kmod-346.72 2015/07/02 06:53:50 akmodsbuild: + cd nvidia-kmod-346.72 2015/07/02 06:53:50 akmodsbuild: + /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w . 2015/07/02 06:53:50 akmodsbuild: + tar --use-compress-program xz -xf /usr/share/nvidia-kmod-346.72/nvidia-kmod-346.72-x86_64.tar.xz 2015/07/02 06:53:50 akmodsbuild: + echo 'Patch #0 (nv-linux-arm.patch):' 2015/07/02 06:53:50 akmodsbuild: Patch #0 (nv-linux-arm.patch): 2015/07/02 06:53:50 akmodsbuild: + /usr/bin/cat /tmp/akmodsbuild.wv915hso/SOURCES/nv-linux-arm.patch 2015/07/02 06:53:50 akmodsbuild: + /usr/bin/patch -p1 --fuzz=0 2015/07/02 06:53:50 akmodsbuild: patching file kernel/nv-linux.h 2015/07/02 06:53:50 akmodsbuild: Hunk #1 succeeded at 241 (offset 1 line). 2015/07/02 06:53:50 akmodsbuild: + for kernel_version in 4.0.6-300.fc22.x86_64___/usr/src/kernels/4.0.6-300.fc22.x86_64 2015/07/02 06:53:50 akmodsbuild: + cp -a kernel _kmod_build_4.0.6-300.fc22.x86_64 2015/07/02 06:53:50 akmodsbuild: + exit 0 2015/07/02 06:53:50 akmodsbuild: Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.t2o0ZA 2015/07/02 06:53:50 akmodsbuild: + umask 022 2015/07/02 06:53:50 akmodsbuild: + cd /tmp/akmodsbuild.wv915hso//BUILD 2015/07/02 06:53:50 akmodsbuild: + cd nvidia-kmod-346.72 2015/07/02 06:53:50 akmodsbuild: + for kernel_version in 4.0.6-300.fc22.x86_64___/usr/src/kernels/4.0.6-300.fc22.x86_64 2015/07/02 06:53:50 akmodsbuild: + pushd _kmod_build_4.0.6-300.fc22.x86_64/ 2015/07/02 06:53:50 akmodsbuild: /tmp/akmodsbuild.wv915hso/BUILD/nvidia-kmod-346.72/_kmod_build_4.0.6-300.fc22.x86_64 /tmp/akmodsbuild.wv915hso/BUILD/nvidia-kmod-346.72 2015/07/02 06:53:50 akmodsbuild: + make -j4 KERNEL_UNAME=4.0.6-300.fc22.x86_64 SYSSRC=/usr/src/kernels/4.0.6-300.fc22.x86_64 IGNORE_CC_MISMATCH=1 IGNORE_XEN_PRESENCE=1 IGNORE_PREEMPT_RT_PRESENCE=1 module which is preceded by 2015/07/02 06:53:50 akmodsbuild: NVIDIA: calling KBUILD... which I'm guessing is the kick off command. Execute all these? regards On 6 July 2015 at 12:59, Ed Greshko <ed.greshko(a)greshko.com&gt; wrote: -- Dave Pawson XSLT XSL-FO FAQ. Docbook FAQ. http://www.dpawson.co.uk

On 07/06/15 20:10, Dave Pawson wrote: <snip> I do not believe the lines you quoted are from /var/cache/akmods/akmods.log I believe they are from /var/cache/akmods/nvidia-something/something.failed.log The last line in /var/cache/akmods/akmods.log (at least mine) reads... 2015/06/28 18:26:01 akmods: '/usr/sbin/akmods --force' as root. So, the command to run before reboot is... /usr/sbin/akmods --force

On 6 July 2015 at 13:24, Ed Greshko <ed.greshko(a)greshko.com&gt; wrote: Yes, not looking properly - again. 2015/07/06 13:00:05 akmods: Hint: Some kmods were ignored or failed to build or install. 2015/07/06 13:00:05 akmods: You can try to rebuild and install them by by calling 2015/07/06 13:00:05 akmods: '/usr/sbin/akmods --force' as root. Quite right. One to remember! Much appreciated Ed. Thanks. Dave P -- Dave Pawson XSLT XSL-FO FAQ. Docbook FAQ. http://www.dpawson.co.uk

On Mon, Jul 6, 2015 at 8:00 AM, Dave Pawson <dave.pawson(a)gmail.com&gt; wrote: There is a reason that they failed to rebuild right after kernel update but it's likely to be the same problem others have experienced, dnf not releasing it's lock on the rpm database soon enough. They are not enabled by default (there's a special list of services allowed to be enabled by default, and akmods isn't on it) but there are two systemd services you can enable that help in this specific situation. You can try as root (or sudo): $ systemctl enable akmods.service and/or $ systemctl enable akmods-shutdown.service The first attempts another rebuild during the boot cycle and the other on shutdown. Of course if there's a different problem, for instance something changed in the kernel that the binary drivers haven't accounted for, then obviously it won't help there. I'd like to find a way to notify the user on failure but haven't found a simple way to do that. Thanks, Richard

On Mon, Jul 6, 2015 at 8:26 AM, Dave Pawson <dave.pawson(a)gmail.com&gt; wrote: Unlikely... This is only a hunch so I would appreciate verification but: I had the services enabled by default using the post install scripts in the RPM but systemd was updated to only honor the special list as far as I can tell. I didn't change the scripts in the package but noticed on a fresh install that they were not enabled! Thanks, Richard

On Mon, Jul 6, 2015 at 8:37 AM, Dave Pawson <dave.pawson(a)gmail.com&gt; wrote: Maybe, I'm pretty tied up for the next couple of days but I may try doing a fresh install in a virtualmachine and test things out. Thanks, Richard

On 07/12/15 04:25, Dave Pawson wrote: FWIW, I am a KDE user and normally update via dnf. However I just tested and if I update via apper, invoked from systray, the rpms get built and installed without extra work. One thing to remember, the rebuild/install process happens after apper completes and tells you your system is up-to-date. So, you need to wait a bit before rebooting to the new kernel.

On 06/07/15 14:07, Richard Shaw wrote: Richard Excuse me if this was documented elsewhere in this thread, but I didn't see it explicitly. I'm seeing the no installed kmod issue after a kernel upgrade and reboot too. I have those akmods services enabled but they detect that the build during the nightly update failed (due to the transaction lock issue) and don't bother to try again. (in my case I use yum-deprecated for the nightly updates). 2015/07/16 10:43:04 akmods: Checking kmods exist for 4.0.7-300.fc22.x86_64 2015/07/16 10:43:08 akmods: Ignoring nvidia-340xx-kmod as it failed earlier 2015/07/16 10:43:08 akmods: Hint: Some kmods were ignored or failed to build or install. 2015/07/16 10:43:08 akmods: You can try to rebuild and install them by by calling 2015/07/16 10:43:08 akmods: '/usr/sbin/akmods --force' as root. I didn't see a fix for this in your note about the new akmods package you have in testing or in other recent threads, but I might have overlooked something. A dirty workaround for me would be to make the akmods.service file run /usr/sbin/akmods --force as the ExecStart line, but I have seen reports on google that you can't easily pass parameters to the ExecStart command like that. Can you advise please on the best (automatic) work around. Thanks Roderick

Am 16.07.2015 um 14:16 schrieb Roderick Johnstone: there is likely a akmods folders in /var/lib/ as for any other software with runtime data, the information about the previous fail is there so just purge that folder - due package install on a virgin setup it's empty by definition nonsense - most services are using params and it's no problem disable a service, clone it's unit in /etc/systemd/system/, modify it there and enable the service again so it don't get overwritten by updates

On 16/07/15 14:20, Roderick Johnstone wrote: So, having copied the akmods.service file to /etc/systemd/system (as Harald Reindl suggested) and added --force it is now building and installing the kmod on reboot. (Actually I also removed --from-init which I realise now was probably a mistake but probably not causing the problems I'm seeing here.) However, the kernel module is not loaded and so the graphical display does not start until either I reboot again or change run levels and run modprobe nvidia. Any idea whats going on here? Thanks. Roderick

On 22/07/15 21:46, Richard Shaw wrote: I'm actually using sddm so gdm.service is disabled for me and sddm.service is enabled. I do have a sym link: /etc/systemd/system/display-manager.service -> /usr/lib/systemd/system/sddm.service so I'm not sure why its not working as expected. I can certainly test that and report back if you like. Roderick

On Thu, Jul 23, 2015 at 5:37 AM, Roderick Johnstone <rmj(a)ast.cam.ac.uk&gt; wrote: I'm guessing that the kernel tries at boot but the module doesn't get built and installed until after the kernel is loaded so the module just isn't there in time. The more I think about it the more useless the startup script seems to be, the shutdown one should catch this situation and then the module should be available on reboot... I need to think about this some more. Do you also have the shutdown service enabled? Thanks, Richard

On Thu, Jul 23, 2015 at 8:22 AM, Roderick Johnstone <rmj(a)ast.cam.ac.uk&gt; wrote: Well the answer to your first statement is no then yes then no :) For some reason I setup the shutdown service to run akmods directly instead of calling a script which would "collect" the installed kernels, so no, it would only try to build for the current kernel via "uname -r". Then yes, because I just changed the service file to run a script which would grab all of the installed kernels and pass them to akmods. Then no, because it can only build kernel modules for kernels that have the appropriate kernel-devel package installed, but currently unlike the kernel itself, only one kernel-devel package is typically installed at one time. :) Could you follow all that? So basically once I build new packages, the shutdown script will attempt to build modules for every kernel-devel package installed, whether it be the latest or not (though it typically should be). Ok, now that that's covered I have a crazy idea... For systemd service type "oneshot" which the akmod service is, you can have multiple ExecStart= directives. Why couldn't we have two, something like: [Service] Type=oneshot RemainAfterExit=true ExecStart=/usr/sbin/akmods --from-init ExecStart=-/usr/sbin/modprobe nvidia Anything know why that wouldn't work? That should fix the problem with building modules on startup. Thanks, Richard

On Thu, Jul 23, 2015 at 10:58 AM, Roderick Johnstone <rmj(a)ast.cam.ac.uk&gt; wrote: That's likely the issue. I thought the same as well but noticed I only have one kernel-devel package installed (and it wasn't even the latest one!) dnf still needs some polishing for sure! No, with oneshot+multiple ExecStart's they are run in order, the first one must exit (and exit cleanly) before the next one is executed. I'm not sure if you noticed that I moved the "-" at the beginning. This tells systemd to treat it like it succeeds even if it fails (non-zero exit). Since there's no point in running modpobe if akmods failed i moved it to the modprobe line. I don't want to use --force in case there's a real problem with building the rpms, but I altered the akmods script (I hope correctly) to not treat failure to install a permanent failure so it should try again the next time akmods is run. Good to hear! Anyone want to try a testing package? I don't want to build an official package yet because we still don't have bodhi for updates so there's no way to stop it from being pushed to stable without a direct email to a human. Thanks, Richard

On 23/07/15 17:07, Richard Shaw wrote: There seems to be some relevant discussion at: https://bugzilla.redhat.com/show_bug.cgi?id=1062997 and related bugs. Roderick