I just updated the kernel to kernel-4.0.6-300.fc22.x86_64 and rebooted. The system came up in VGA mode, presumably because kmod-nvidia had not recompiled. Is there a way to force this, or do I have to wait for an update to akmod-nvidia?
For the moment I removed akmod-nvidia and rebooted with Nouveau. This seems rather inelegant. I thought the akmod thing was supposed to take care of these dependencies, or am I missing something?
poc
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.
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.
poc
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 06/30/15 20:04, Ed Greshko wrote:
I haven't tracked down the cause as of yet.
Well the cause seems to be this....
Install 1 Package
Total size: 3.7 M Installed size: 15 M Downloading Packages: Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction RPMDB already locked by 20262 The application with PID 20262 is: dnf Memory : 131 M RSS (699 MB VSZ) Started: Sun Jun 28 17:59:38 2015 - 26:23 ago State : Sleeping 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/
Just don't know the cure. :-)
On Tue, 2015-06-30 at 20:04 +0800, Ed Greshko wrote:
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.
This is what I find in the log: Running transaction RPMDB already locked by 22298 The application with PID 22298 is: dnf Memory : 124 M RSS (686 MB VSZ) Started: Tue Jun 30 09:57:29 2015 - 03:30 ago State : Sleeping 2015/06/30 10:00:59 akmods: Could not install newly built RPMs. You can find them and the logfile 2015/06/30 10:00:59 akmods: 346.72-2.1-for-4.0.6-300.fc22.x86_64.failed.log in /var/cache/akmods/nvidia/
So the problem is not with compilation, it's with dnf locking itself out.
Running '/usr/sbin/akmods --force' solved it.
Not sure whether to report this against dnf or Nvidia.
poc
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 :-).
On Tue, Jun 30, 2015 at 7:25 AM, Tom Horsley horsley1953@gmail.com wrote:
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 :-).
Sorry guys, I've been out of town for work and other $FAMILY and $DAYJOB issues so I'm going to take a look. There's a couple of open bugs with akmods but I'm not 100% sure that the fixes mentioned address this particular issue so any help investigating and reporting success/failure is appreciated.
Thanks, Richard
On Tue, 2015-06-30 at 07:37 -0500, Richard Shaw wrote:
On Tue, Jun 30, 2015 at 7:25 AM, Tom Horsley horsley1953@gmail.com wrote:
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 :-).
Sorry guys, I've been out of town for work and other $FAMILY and $DAYJOB issues so I'm going to take a look. There's a couple of open bugs with akmods but I'm not 100% sure that the fixes mentioned address this particular issue so any help investigating and reporting success/failure is appreciated.
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.
poc
On Tue, Jun 30, 2015 at 7:50 AM, Patrick O'Callaghan 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?
Thanks, Richard
On 06/30/15 22:21, Richard Shaw wrote:
On Tue, Jun 30, 2015 at 7:50 AM, Patrick O'Callaghan <pocallaghan@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@greshko.com wrote:
On 06/30/15 22:21, Richard Shaw wrote:
On Tue, Jun 30, 2015 at 7:50 AM, Patrick O'Callaghan <
pocallaghan@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
Thanks, Richard
On 06/30/15 22:30, Richard Shaw wrote:
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
I see....
Well, first I must admit that on both of my systems I notice the failure before I reboot and I correct the issue. So, I don't know if having those enabled will fix the issue. But just for completeness...
[root@acer ~]# systemctl status akmods ● akmods.service - Builds and install new kmods from akmod packages Loaded: loaded (/usr/lib/systemd/system/akmods.service; enabled; vendor preset: disabled) Active: active (exited) since Tue 2015-06-30 09:08:56 CST; 13h ago Process: 754 ExecStart=/usr/sbin/akmods --from-init (code=exited, status=0/SUCCESS) Main PID: 754 (code=exited, status=0/SUCCESS) CGroup: /system.slice/akmods.service
Jun 30 09:08:46 acer.greshko.com systemd[1]: Starting Builds and install new.... Jun 30 09:08:56 acer.greshko.com akmods[754]: Checking kmods exist for 4.0.6...] Jun 30 09:08:56 acer.greshko.com systemd[1]: Started Builds and install new ....
[root@acer ~]# 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; vendor preset: disabled) Active: active (exited) since Tue 2015-06-30 09:08:47 CST; 14h ago Process: 774 ExecStart=/bin/true (code=exited, status=0/SUCCESS) Main PID: 774 (code=exited, status=0/SUCCESS) CGroup: /system.slice/akmods-shutdown.service
Jun 30 09:08:46 acer.greshko.com systemd[1]: Starting Builds and install new.... Jun 30 09:08:47 acer.greshko.com systemd[1]: Started Builds and install new ....
I gather I should test at the next kernel update if this does "fix" the issue.
On Tue, 2015-06-30 at 09:30 -0500, Richard Shaw wrote:
On Tue, Jun 30, 2015 at 9:28 AM, Ed Greshko ed.greshko@greshko.com wrote:
On 06/30/15 22:21, Richard Shaw wrote:
On Tue, Jun 30, 2015 at 7:50 AM, Patrick O'Callaghan <
pocallaghan@gmail.com mailto:pocallaghan@gmail.com> wrote:
My only "fix" (really a workaround) was to run the processmanually, 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
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.
poc
On Tue, Jun 30, 2015 at 11:13 AM, Patrick O'Callaghan <pocallaghan@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.
Thanks, Richard
On Tue, 2015-06-30 at 11:18 -0500, Richard Shaw wrote:
On Tue, Jun 30, 2015 at 11:13 AM, Patrick O'Callaghan < pocallaghan@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.
I see. In that case, it didn't work. I do have the services you mentioned and the problem still arose, unless of course the problem was a lock file being left around when it should have been removed. That would imply a problem with the ordering of events at shutdown or startup.
poc
On Tue, 30 Jun 2015 07:37:59 -0500 Richard Shaw wrote:
On Tue, Jun 30, 2015 at 7:25 AM, Tom Horsley horsley1953@gmail.com wrote:
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 :-).
Sorry guys, I've been out of town for work and other $FAMILY and $DAYJOB issues so I'm going to take a look. There's a couple of open bugs with akmods but I'm not 100% sure that the fixes mentioned address this particular issue so any help investigating and reporting success/failure is appreciated.
Here's a clue. I just booted my f22 partition and ran dnf update, which did update the kernel and caused akmods to build a new nvidia driver. It worked fine for me, it installed the nvidia driver with no problem, so perhaps it is a timing issue and depends on how long various update activities take.
There is also stoopid packagekitd which seems to run at the most inconvenient possible time to interfere with manual updates. I noticed it started showing up in "top" right after I did the dnf update.
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?
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?
poc
On Tue, Jun 30, 2015 at 7:48 AM, Patrick O'Callaghan pocallaghan@gmail.com wrote:
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?
Nope, it was written by one of the RPM Fusion founders Thorsten Leemhuis.
Thanks, Richard
On Tue, 2015-06-30 at 07:56 -0500, Richard Shaw wrote:
On Tue, Jun 30, 2015 at 7:48 AM, Patrick O'Callaghan < pocallaghan@gmail.com> wrote:
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?
Nope, it was written by one of the RPM Fusion founders Thorsten Leemhuis.
OK.
poc
On Tue, 2015-06-30 at 08:04 -0400, Tom Horsley wrote:
On Tue, 30 Jun 2015 12:47:24 +0100 Patrick O'Callaghan wrote:
In any case I would have expected the update not to complete until the module had finished recompiling.
Yea, I expected that too up till I found I had no video after typing reboot right after the update :-).
IOW you had the same problem I had. I would regard that as a bug rather than a feature :-)
poc
-
Ed Greshko -
Patrick O'Callaghan -
Richard Shaw -
Tom Horsley