will not generated an module for kernel but works well under 4.0.6
On Mon, 13 Jul 2015 17:27:46 +0800 Jean Jacques chaoyzj@gmail.com wrote:
will not generated an module for kernel but works well under 4.0.6
Have you check the rpmfusion mailing listslist for any other users reporting problems\solutions.
___ Regards Frank Murphy
not yet.
2015-07-13 18:01 GMT+08:00 Frank Murphy frankly3d@gmail.com:
On Mon, 13 Jul 2015 17:27:46 +0800 Jean Jacques chaoyzj@gmail.com wrote:
will not generated an module for kernel but works well under 4.0.6
Have you check the rpmfusion mailing listslist for any other users reporting problems\solutions.
Regards Frank Murphy -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
On 07/13/15 17:27, Jean Jacques wrote:
will not generated an module for kernel but works well under 4.0.6
I see you got your answer on the rpmfusion list.
When you have a problem with akmods you can check /var/cache/akmods/akmods.log for information about what when wrong.
On Mon, 2015-07-13 at 18:38 +0800, Ed Greshko wrote:
On 07/13/15 17:27, Jean Jacques wrote:
will not generated an module for kernel but works well under 4.0.6
I see you got your answer on the rpmfusion list.
When you have a problem with akmods you can check /var/cache/akmods/akmods.log for information about what when wrong.
Same thing happened to me. I fixed it by checking the log and rerunning the modulebuild script manually.
This was discussed on several recent threads (search for nvidia in the Subject) and is fast becoming a FAQ. The basic issue is that the akmod install script compiles the source module against the new kernel, creating a new rpm. It then tries to install the rpm, but the rpm database is already locked by a different process (presumably the dnf run that called the script in the first place, though I haven't verified this). The rpm install fails but the user isn't told directly, and when he reboots there is no nvidia module available for the new kernel. I suspect that this happens to those of us who run dnf directly from the Shell. I understand that the GUI tool under Gnome reboots into a special image before actually doing the installation, which therefore avoids the problem, but I don't use Gnome or GUI installation tools so this is pure conjecture.
poc
On 07/13/15 20:43, Patrick O'Callaghan wrote:
On Mon, 2015-07-13 at 18:38 +0800, Ed Greshko wrote:
On 07/13/15 17:27, Jean Jacques wrote:
will not generated an module for kernel but works well under 4.0.6
I see you got your answer on the rpmfusion list.
When you have a problem with akmods you can check /var/cache/akmods/akmods.log for information about what when wrong.
Same thing happened to me. I fixed it by checking the log and rerunning the modulebuild script manually.
Just to add to this.... Check to see if you have both of these enabled.
[egreshko@meimei ~]$ systemctl is-enabled akmods enabled [egreshko@meimei ~]$ systemctl is-enabled akmods-shutdown.service enabled
I just tested and found that if the modules aren't built/installed during the "dnf update" process they will get built/installed properly during the reboot.
Some have reported that one or both of these services weren't enabled and this probably resulted in their failure.
On Wed, 2015-07-15 at 20:13 +0800, Ed Greshko wrote:
On 07/13/15 20:43, Patrick O'Callaghan wrote:
On Mon, 2015-07-13 at 18:38 +0800, Ed Greshko wrote:
On 07/13/15 17:27, Jean Jacques wrote:
will not generated an module for kernel but works well under 4.0.6
I see you got your answer on the rpmfusion list.
When you have a problem with akmods you can check /var/cache/akmods/akmods.log for information about what when wrong.
Same thing happened to me. I fixed it by checking the log and rerunning the modulebuild script manually.
Just to add to this.... Check to see if you have both of these enabled.
[egreshko@meimei ~]$ systemctl is-enabled akmods enabled [egreshko@meimei ~]$ systemctl is-enabled akmods-shutdown.service enabled
I just tested and found that if the modules aren't built/installed during the "dnf update" process they will get built/installed properly during the reboot.
Some have reported that one or both of these services weren't enabled and this probably resulted in their failure.
I have them both enabled, so there must be something else.
poc
I see the same problem and did some investigation.
The problem is that dnf-makecache.service runs at the same time as akmods.service. DNF locks the RPM data base which prevents akmods from installing the RPM's it built.
Here is a extract from 346.72-2.1-for-4.0.8-300.fc22.x86_64.failed.log
Running transaction RPMDB already locked by 2285 The application with PID 2285 is: dnf Memory : 116 M RSS (677 MB VSZ) Started: Sat Jul 18 12:09:56 2015 - 06:20 ago State : Sleeping 2015/07/18 12:16:16 akmods: Could not install newly built RPMs. You can find them and the logfile 2015/07/18 12:16:16 akmods: 346.72-2.1-for-4.0.8-300.fc22.x86_64.failed.log in /var/cache/akmods/nvidia/
Looking in the journal shows dnf-makecache running at the time that akmods.service need RPMDB access.
I ended up working around the issue with:
systemctl disable dnf-makecache.service systemctl disable dnf-makecache.timer
I'm not sure what the right systemd unit change will be to have a reliable start up. How do you prevent dnf-makecache from running until after akmods.service has run given that started off a timer?
At the next kernel release I'll know if this is successful.
Barry
On Wed 15 Jul 2015 13:38:47 Patrick O'Callaghan wrote:
On Wed, 2015-07-15 at 20:13 +0800, Ed Greshko wrote:
On 07/13/15 20:43, Patrick O'Callaghan wrote:
On Mon, 2015-07-13 at 18:38 +0800, Ed Greshko wrote:
On 07/13/15 17:27, Jean Jacques wrote:
will not generated an module for kernel but works well under 4.0.6
I see you got your answer on the rpmfusion list.
When you have a problem with akmods you can check /var/cache/akmods/akmods.log for information about what when wrong.
Same thing happened to me. I fixed it by checking the log and rerunning the modulebuild script manually.
Just to add to this.... Check to see if you have both of these enabled.
[egreshko@meimei ~]$ systemctl is-enabled akmods enabled [egreshko@meimei ~]$ systemctl is-enabled akmods-shutdown.service enabled
I just tested and found that if the modules aren't built/installed during the "dnf update" process they will get built/installed properly during the reboot.
Some have reported that one or both of these services weren't enabled and this probably resulted in their failure.
I have them both enabled, so there must be something else.
poc
-
Barry Scott -
Ed Greshko -
Frank Murphy -
Jean Jacques -
Patrick O'Callaghan