2:17 p.m.
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
4:34 p.m.
An interesting bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1187111
M.
2015-07-24 16:17 GMT+02:00 Barry Scott <barry(a)barrys-emacs.org>:
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
9:13 a.m.
I have posted my analysis on to that bug.
Barry
On 25 Jul 2015, at 17:34, Massi Ergosum
<massi.ergosum(a)gmail.com> wrote:
An interesting bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1187111
M.
2015-07-24 16:17 GMT+02:00 Barry Scott <barry(a)barrys-emacs.org>:
> 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
>
1:07 p.m.
Am 30.07.2015 um 15:02 schrieb Barry Scott:
The update to the kernel worked smoothly with dnf-makecache disabled
that happens when developers enable such braindead things as default and
ignore complaints - nobody on this planet needs the dnf-cache refreshed
all the time for a million reasons
three of them:
* when the system checks in the background for updates it don't matter
* in the worst case it would have found updates and don't because
the cache was refreshed shortly before new updates where pushed
* it is a waste of banedwidth and ressources *everywhere*
on the users sides as well as on the mirrors
2:20 p.m.
Updated software via GUI.
new kernel 4.1.5-200.fc22.x86_64
Usual song and dance.
#akmod --force worked as previously.
regards
On 24 July 2015 at 15:17, Barry Scott <barry(a)barrys-emacs.org> wrote:
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
--
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk
2:25 p.m.
On 08/20/15 22:20, Dave Pawson wrote:
Updated software via GUI.
new kernel 4.1.5-200.fc22.x86_64
Usual song and dance.
#akmod --force worked as previously.
Strange. I no longer have to do that..... Yes, the rpm fails to get installed due to a
lock by dnf. However, in my case, the akmods-shutdown.service builds and installs the rpm
during reboot.
2:29 p.m.
On Thu, Aug 20, 2015 at 9:25 AM, Ed Greshko <ed.greshko(a)greshko.com> wrote:
On 08/20/15 22:20, Dave Pawson wrote:
> Updated software via GUI.
> new kernel 4.1.5-200.fc22.x86_64
>
> Usual song and dance.
> #akmod --force worked as previously.
Strange. I no longer have to do that..... Yes, the rpm fails to get
installed due to a lock by dnf. However, in my case, the
akmods-shutdown.service builds and installs the rpm during reboot.
Thanks for confirming that the shutdown script is actually useful now! :)
Thanks,
Richard
2:50 p.m.
Note I used the GUI for the update,
not dnf from the cmd line?
Would that make a difference?
Of note, I've had no problems for a week or two?
regards
On 20 August 2015 at 15:25, Ed Greshko <ed.greshko(a)greshko.com> wrote:
On 08/20/15 22:20, Dave Pawson wrote:
> Updated software via GUI.
> new kernel 4.1.5-200.fc22.x86_64
>
> Usual song and dance.
> #akmod --force worked as previously.
Strange. I no longer have to do that..... Yes, the rpm fails to get installed due to a
lock by dnf. However, in my case, the akmods-shutdown.service builds and installs the rpm
during reboot.
--
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk
2:27 p.m.
Am 20.08.2015 um 16:20 schrieb Dave Pawson:
Updated software via GUI.
new kernel 4.1.5-200.fc22.x86_64
Usual song and dance.
#akmod --force worked as previously.
and you are sure the timers are not running?
"disable" is bulls** if you really want something not have started
* enable: start units unconditional
* disable: start units on triggers/demand
* mask: never start soemthing
systemctl mask dnf-makecache.service
systemctl mask dnf-makecache.timer
http://stackoverflow.com/questions/30720786/cannot-disable-systemd-service
On 24 July 2015 at 15:17, Barry Scott <barry(a)barrys-emacs.org>
wrote:
> 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
1:29 p.m.
On Thursday 20 August 2015 16:27:15 Reindl Harald wrote:
Am 20.08.2015 um 16:20 schrieb Dave Pawson:
> Updated software via GUI.
> new kernel 4.1.5-200.fc22.x86_64
>
> Usual song and dance.
> #akmod --force worked as previously.
and you are sure the timers are not running?
"disable" is bulls** if you really want something not have started
* enable: start units unconditional
* disable: start units on triggers/demand
* mask: never start soemthing
systemctl mask dnf-makecache.service
systemctl mask dnf-makecache.timer
http://stackoverflow.com/questions/30720786/cannot-disable-systemd-service
I have not hit any problem with using disable in practice. But Its nice to
know about mask, thanks for the info.
Barry
> On 24 July 2015 at 15:17, Barry Scott <barry(a)barrys-emacs.org> wrote:
>> 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
1:36 p.m.
Am 24.08.2015 um 15:29 schrieb Barry Scott:
On Thursday 20 August 2015 16:27:15 Reindl Harald wrote:
> Am 20.08.2015 um 16:20 schrieb Dave Pawson:
>> Updated software via GUI.
>> new kernel 4.1.5-200.fc22.x86_64
>>
>> Usual song and dance.
>> #akmod --force worked as previously.
>
> and you are sure the timers are not running?
>
> "disable" is bulls** if you really want something not have started
>
> * enable: start units unconditional
> * disable: start units on triggers/demand
> * mask: never start soemthing
>
> systemctl mask dnf-makecache.service
> systemctl mask dnf-makecache.timer
>
> http://stackoverflow.com/questions/30720786/cannot-disable-systemd-service
I have not hit any problem with using disable in practice. But Its nice to
know about mask, thanks for the info
well, then try to disable "udisks", "upower" or
"colord".........
"udisks.service" even don't have a install-section to enable or disable
it and i can't say how much i hate all that "on-demand" crap
well, you need some rsyslog-rules to stop the system whining about the
masked services everytime something would attempt to start them
"upower" (which is completly useless on a workstation) on the machine of
my co-developer started 2 days ago to turn off the monitor directly
after login via KDM into his ordianry KDE session
"systemctl stop upower.service; systemctl mask upower.service" and the
problem is solved
2:28 p.m.
On Thu, Aug 20, 2015 at 9:20 AM, Dave Pawson <dave.pawson(a)gmail.com> wrote:
Updated software via GUI.
new kernel 4.1.5-200.fc22.x86_64
Usual song and dance.
#akmod --force worked as previously.
I could use a few more details. Did you look at the log? Did it build but
just fail to install? Are both the startup and shutdown services enabled?
What about just running the startup service again?
Thanks,
Richard
3407
days inactive
3438
days old
rpmfusion-users@lists.rpmfusion.org
13 comments
6 participants
participants (6)
-
Barry Scott -
Dave Pawson -
Ed Greshko -
Massi Ergosum -
Reindl Harald -
Richard Shaw