On Tue, 2015-06-30 at 07:34 -0400, Tom Horsley wrote: > If you don't give it time to recompile the driver > after the yum update and before a reboot, things > can be in a confusing state and it won't recompile > after the boot. (At least that is what I have > observed). > > I always run "top" after a yum update and wait till > all the compilation and rpm activity disappears before > I type "reboot". > > If you install akmod-nvidia again, it will probably > update the driver at that time and you'll be back > to normal. I'm using dnf (forgot to mention this is F22) but presumably the same applies. However I did let some time pass before rebooting, not because I was waiting for a recompilation but it just happened that way. I also tried removing and reinstalling akmod-nvidia and it made no difference. In any case I would have expected the update not to complete until the module had finished recompiling.

On 06/30/15 19:47, Patrick O'Callaghan wrote: > On Tue, 2015-06-30 at 07:34 -0400, Tom Horsley wrote: > > If you don't give it time to recompile the driver > > after the yum update and before a reboot, things > > can be in a confusing state and it won't recompile > > after the boot. (At least that is what I have > > observed). > > > > I always run "top" after a yum update and wait till > > all the compilation and rpm activity disappears before > > I type "reboot". > > > > If you install akmod-nvidia again, it will probably > > update the driver at that time and you'll be back > > to normal. > I'm using dnf (forgot to mention this is F22) but presumably the > same > applies. However I did let some time pass before rebooting, not > because > I was waiting for a recompilation but it just happened that way. I > also > tried removing and reinstalling akmod-nvidia and it made no > difference. > > In any case I would have expected the update not to complete until > the > module had finished recompiling. I have been seeing the same thing you're seeing. I haven't tracked down the cause as of yet. However, after doing the dnf upgrade of the kernel check in /var/cache/akmod and check the log. You may see something like this.... [root@meimei akmods]# tail akmods.log 2015/06/28 18:25:41 akmods: Building and installing nvidia-304xx-kmod 2015/06/28 18:25:41 akmods: Building RPM using the command '/bin/akmodsbuild --target x86_64 --kernels 4.0.6-300.fc22.x86_64 /usr/src/akmods/nvidia-304xx-kmod.latest' 2015/06/28 18:26:00 akmods: Installing newly built rpms 2015/06/28 18:26:01 akmods: Could not install newly built RPMs. You can find them and the logfile 2015/06/28 18:26:01 akmods: 304.125-3.10-for-4.0.6 -300.fc22.x86_64.failed.log in /var/cache/akmods/nvidia-304xx/ 2015/06/28 18:26:01 akmods: Hint: Some kmods were ignored or failed to build or install. 2015/06/28 18:26:01 akmods: You can try to rebuild and install them by by calling 2015/06/28 18:26:01 akmods: '/usr/sbin/akmods --force' as root. At this point you have 2 choices. Check the /var/cache/akmods/nvidia -"driver" directory to see if the rpm has actually been built or run the command as a user as shown in the log. In the case above it would be /bin/akmodsbuild --target x86_64 --kernels 4.0.6-300.fc22.x86_64 /usr/src/akmods/nvidia-304xx-kmod.latest and install the resulting rpm.

On Tue, 30 Jun 2015 13:19:47 +0100 Patrick O'Callaghan wrote: > So the problem is not with compilation, it's with dnf locking itself > out. That's probably why yum runs the akmod compile in the background rather than waiting on it because when it waited on it, the database was locked :-).

My only "fix" (really a workaround) was to run the process manually, when dnf wasn't locking it out. There's clearly a race of some kind with the normal installation process.

On 06/30/15 22:21, Richard Shaw wrote: > On Tue, Jun 30, 2015 at 7:50 AM, Patrick O'Callaghan < pocallaghan(a)gmail.com <mailto:pocallaghan@gmail.com>> wrote: > > My only "fix" (really a workaround) was to run the process manually, > when dnf wasn't locking it out. There's clearly a race of some kind > with the normal installation process. > > > What's interesting here is that the shutdown service or start service should catch this, UNLESS, it doesn't catch the situation where the compilation completes but the install does not... > > Do you have both/either services enabled? > I'm not familiar with a shutdown or start service. [root@acer ~]# systemctl status shutdown ● shutdown.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead) [root@acer ~]# systemctl status start ● start.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead FWIW, I see the failure to install the akmod built rpms on 2 systems 100% of the time since upgrading to F22.

On Tue, Jun 30, 2015 at 9:28 AM, Ed Greshko <ed.greshko(a)greshko.com&gt; wrote: > On 06/30/15 22:21, Richard Shaw wrote: > > On Tue, Jun 30, 2015 at 7:50 AM, Patrick O'Callaghan < > pocallaghan(a)gmail.com <mailto:pocallaghan@gmail.com>> wrote: > > > > My only "fix" (really a workaround) was to run the process > > manually, > > when dnf wasn't locking it out. There's clearly a race of > > some kind > > with the normal installation process. > > > > > > What's interesting here is that the shutdown service or start > > service > should catch this, UNLESS, it doesn't catch the situation where the > compilation completes but the install does not... > > > > Do you have both/either services enabled? > > > > I'm not familiar with a shutdown or start service. > > [root@acer ~]# systemctl status shutdown > ● shutdown.service > Loaded: not-found (Reason: No such file or directory) > Active: inactive (dead) > [root@acer ~]# systemctl status start > ● start.service > Loaded: not-found (Reason: No such file or directory) > Active: inactive (dead > > FWIW, I see the failure to install the akmod built rpms on 2 > systems 100% > of the time since upgrading to F22. > Sorry, I should have been more specific, the services are called "akmods" and "akmods-shutdown". Enabling either one should help... The shutdown one if dnf releases the lock before you shutdown or the bootup one in case that one fails. $ systemctl status akmods ● akmods.service - Builds and install new kmods from akmod packages Loaded: loaded (/usr/lib/systemd/system/akmods.service; enabled) Active: active (exited) since Sun 2015-06-14 11:20:19 CDT; 2 weeks 1 days ago Main PID: 852 (code=exited, status=0/SUCCESS) CGroup: /system.slice/akmods.service $ systemctl status akmods-shutdown ● akmods-shutdown.service - Builds and install new kmods from akmod packages Loaded: loaded (/usr/lib/systemd/system/akmods-shutdown.service; enabled) Active: active (exited) since Sun 2015-06-14 11:20:08 CDT; 2 weeks 1 days ago Main PID: 876 (code=exited, status=0/SUCCESS) CGroup: /system.slice/akmods-shutdown.service

On Tue, Jun 30, 2015 at 11:13 AM, Patrick O'Callaghan < pocallaghan(a)gmail.com > wrote: > I have both of those running as shown. > > To be clear: The dnf lock is detected after the akmod compile, > during > the rpm install phase. I don't see how that is related to system > shutdown or startup. It's not directly. Basically it gives you two more opportunities to build and install the driver. The one at system startup should always work if it's just a dnf/rpmdb lock issue.

Not sure whether to report this against dnf or Nvidia.

On Tue, 2015-06-30 at 20:35 +0800, Ed Greshko wrote: > On 06/30/15 20:19, Patrick O'Callaghan wrote: > > Not sure whether to report this against dnf or Nvidia. > > Don't know if the dnf folks care about it. But shouldn't the > question be between dnf and akmods? Isn't akmod produced by Nvidia?

In any case I would have expected the update not to complete until the module had finished recompiling.