Why akmod fails on F22 for nvidia (and possible other uses)

Barry Scott barry at barrys-emacs.org
Sun Aug 2 18:10:21 CEST 2015


On 30 Jul 2015, at 21:06, Radek Holy <rholy at redhat.com> wrote:
> 
> ----- Original Message -----
>> From: bugzilla at redhat.com
>> Subject: Why akmod fails on F22 for nvidia (and possible other uses)
>> 
>> I did some investigation as to why akmod will fail to install a
>> the nvidia dirver when a new kernel turns up.
>> 
>> 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
> 
> Can akmods.service simply wait for the RPM lock to be released? Sorry, if the question is stupid, I am not familiar with akmod system.

I am assuming that the normal running of a Fedora system it is odd to have updates
happening as part of a boot up. The exception to this rule is akmods that handles
the problem of updating kernel modules after a new kernel is installed.

If this assumption is reasonable, at least for now, then fixing dnf-makecache
to use cron and to be off by default will make the world a happy and reliable place
again.

If my assumptions are wrong and dnf folks manage to keep their dnf-makecache in the system
Then akmods would be forced to work with this in the system.

Barry

> -- 
> Radek Holý
> Associate Software Engineer
> Software Management Team
> Red Hat Czech
> 


More information about the rpmfusion-users mailing list