10:21 a.m.
Twice now after a kernel update from Fedora,
I've not been able to reboot to a GUI.
Some time (usually days) later I update
and hey presto I'm back in business.
Eduard Huguet answered in another thread,
todays date re nvidia drivers.
I have a GEForce GTX 750 card
and akmod-nvidia (346.72) installed.
I'm wondering if something is 'late' to the party
when the kernel is updated.
Any suggestions please?
regards
--
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk
10:53 a.m.
On 07/06/15 18:21, Dave Pawson wrote:
Twice now after a kernel update from Fedora,
I've not been able to reboot to a GUI.
Some time (usually days) later I update
and hey presto I'm back in business.
Eduard Huguet answered in another thread,
todays date re nvidia drivers.
I have a GEForce GTX 750 card
and akmod-nvidia (346.72) installed.
I'm wondering if something is 'late' to the party
when the kernel is updated.
Any suggestions please?
regards
Running F22/KDE with GeForce GTX 660 and the nVidia drivers from RPMfusion (akmod).
The problem I see when updating kernels via dnf. dnf has the RPM database locked so the
rpm's can't be installed during the update. Supposedly, that should be taken care
of during the reboot but it hasn't worked for me. So, I just manually do it as
suggested in the akmods.log prior to reboot.
11:01 a.m.
On 6 July 2015 at 11:53, Ed Greshko <ed.greshko(a)greshko.com> wrote:
Running F22/KDE with GeForce GTX 660 and the nVidia drivers from
RPMfusion (akmod).
The problem I see when updating kernels via dnf. dnf has the RPM database locked so the
rpm's can't be installed during the update. Supposedly, that should be taken care
of during the reboot but it hasn't worked for me. So, I just manually do it as
suggested in the akmods.log prior to reboot.
Sounds good Ed - sorry to sound so ignorant.
"As suggested in akmods.log"...
no such file found on my F22 install?
What does 'manually do it' mean please?
TiA
--
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk
11:59 a.m.
On 07/06/15 19:01, Dave Pawson wrote:
On 6 July 2015 at 11:53, Ed Greshko <ed.greshko(a)greshko.com>
wrote:
> Running F22/KDE with GeForce GTX 660 and the nVidia drivers from RPMfusion (akmod).
>
> The problem I see when updating kernels via dnf. dnf has the RPM database locked so
the rpm's can't be installed during the update. Supposedly, that should be taken
care of during the reboot but it hasn't worked for me. So, I just manually do it as
suggested in the akmods.log prior to reboot.
Sounds good Ed - sorry to sound so ignorant.
"As suggested in akmods.log"...
no such file found on my F22 install?
What does 'manually do it' mean please?
The log is in /var/cache/akmods/ called akmods.log
The "failure" looks like this....
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.
And the last line shows you the command to run before you reboot.
12:10 p.m.
Thanks Ed.
That's quite a long list... In which order please - top of file down
or last upwards? All have the same timestamp?
2015/07/02 06:53:36 akmods: Building RPM using the command
'/bin/akmodsbuild --target x86_64 --kernels 4.0.6-300.fc22.x86_64
/usr/src/akmods/nvidia-kmod.latest'
2015/07/02 06:53:50 akmodsbuild: * Rebuilding
/usr/src/akmods/nvidia-kmod.latest for kernel(s)
4.0.6-300.fc22.x86_64: warning: user mockbuild does not exist - using
root
2015/07/02 06:53:50 akmodsbuild: warning: group mockbuild does not
exist - using root
2015/07/02 06:53:50 akmodsbuild: warning: user mockbuild does not
exist - using root
2015/07/02 06:53:50 akmodsbuild: warning: group mockbuild does not
exist - using root
2015/07/02 06:53:50 akmodsbuild: warning: user mockbuild does not
exist - using root
2015/07/02 06:53:50 akmodsbuild: warning: group mockbuild does not
exist - using root
2015/07/02 06:53:50 akmodsbuild: Installing /usr/src/akmods/nvidia-kmod.latest
2015/07/02 06:53:50 akmodsbuild: Building target platforms: x86_64
2015/07/02 06:53:50 akmodsbuild: Building for target x86_64
2015/07/02 06:53:50 akmodsbuild: Executing(%prep): /bin/sh -e
/var/tmp/rpm-tmp.v7umVj
2015/07/02 06:53:50 akmodsbuild: + umask 022
2015/07/02 06:53:50 akmodsbuild: + cd /tmp/akmodsbuild.wv915hso//BUILD
2015/07/02 06:53:50 akmodsbuild: + kmodtool --target x86_64 --repo
rpmfusion --kmodname nvidia-kmod --filterfile
/tmp/akmodsbuild.wv915hso/SOURCES/nvidia-kmodtool-excludekernel-filterfile
--obsolete-name nvidia-newest --obsolete-version 346.72 --for-kernels
4.0.6-300.fc22.x86_64
2015/07/02 06:53:50 akmodsbuild: %package -n
kmod-nvidia-4.0.6-300.fc22.x86_64
2015/07/02 06:53:50 akmodsbuild: Summary: nvidia kernel
module(s) for 4.0.6-300.fc22.x86_64
2015/07/02 06:53:50 akmodsbuild: Group: System Environment/Kernel
2015/07/02 06:53:50 akmodsbuild: Provides:
kernel-modules-for-kernel = 4.0.6-300.fc22.x86_64
2015/07/02 06:53:50 akmodsbuild: Provides: nvidia-kmod =
%{?epoch:%{epoch}:}%{version}-%{release}
2015/07/02 06:53:50 akmodsbuild: Requires: nvidia-kmod-common
= %{?epoch:%{epoch}:}%{version}
2015/07/02 06:53:50 akmodsbuild:
Requires(post): /usr/sbin/depmod
2015/07/02 06:53:50 akmodsbuild: Requires(postun): /usr/sbin/depmod
2015/07/02 06:53:50 akmodsbuild: Provides:
kmod-nvidia-newest-4.0.6-300.fc22.x86_64 = 346.72
2015/07/02 06:53:50 akmodsbuild: Obsoletes:
kmod-nvidia-newest-4.0.6-300.fc22.x86_64 < 346.72
2015/07/02 06:53:50 akmodsbuild: Requires: kernel-uname-r =
4.0.6-300.fc22.x86_64
2015/07/02 06:53:50 akmodsbuild: BuildRequires: kernel-devel-uname-r
= 4.0.6-300.fc22.x86_64
2015/07/02 06:53:50 akmodsbuild: %post -n
kmod-nvidia-4.0.6-300.fc22.x86_64
2015/07/02 06:53:50 akmodsbuild: /usr/sbin/depmod -aeF
/boot/System.map-4.0.6-300.fc22.x86_64 4.0.6-300.fc22.x86_64 >
/dev/null || :
2015/07/02 06:53:50 akmodsbuild: %postun -n
kmod-nvidia-4.0.6-300.fc22.x86_64
2015/07/02 06:53:50 akmodsbuild: /usr/sbin/depmod -aF
/boot/System.map-4.0.6-300.fc22.x86_64 4.0.6-300.fc22.x86_64 &>
/dev/null || :
2015/07/02 06:53:50 akmodsbuild:
2015/07/02 06:53:50 akmodsbuild: %description -n
kmod-nvidia-4.0.6-300.fc22.x86_64
2015/07/02 06:53:50 akmodsbuild: This package provides the nvidia
kernel modules built for the Linux
2015/07/02 06:53:50 akmodsbuild: kernel 4.0.6-300.fc22.x86_64 for the
%{_target_cpu} family of processors.
2015/07/02 06:53:50 akmodsbuild: %files -n
kmod-nvidia-4.0.6-300.fc22.x86_64
2015/07/02 06:53:50 akmodsbuild: %defattr(644,root,root,755)
2015/07/02 06:53:50 akmodsbuild: %dir
/usr/lib/modules/4.0.6-300.fc22.x86_64/extra
2015/07/02 06:53:50 akmodsbuild:
/usr/lib/modules/4.0.6-300.fc22.x86_64/extra/nvidia/
2015/07/02 06:53:50 akmodsbuild:
2015/07/02 06:53:50 akmodsbuild:
2015/07/02 06:53:50 akmodsbuild:
2015/07/02 06:53:50 akmodsbuild: %global kmodinstdir_prefix /usr/lib/modules/
2015/07/02 06:53:50 akmodsbuild: %global kmodinstdir_postfix /extra/nvidia/
2015/07/02 06:53:50 akmodsbuild: %global kernel_versions
4.0.6-300.fc22.x86_64___%{_usrsrc}/kernels/4.0.6-300.fc22.x86_64
2015/07/02 06:53:50 akmodsbuild:
2015/07/02 06:53:50 akmodsbuild: + cd /tmp/akmodsbuild.wv915hso/BUILD
2015/07/02 06:53:50 akmodsbuild: + rm -rf nvidia-kmod-346.72
2015/07/02 06:53:50 akmodsbuild: + /usr/bin/mkdir -p nvidia-kmod-346.72
2015/07/02 06:53:50 akmodsbuild: + cd nvidia-kmod-346.72
2015/07/02 06:53:50 akmodsbuild: + /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
2015/07/02 06:53:50 akmodsbuild: + tar --use-compress-program xz -xf
/usr/share/nvidia-kmod-346.72/nvidia-kmod-346.72-x86_64.tar.xz
2015/07/02 06:53:50 akmodsbuild: + echo 'Patch #0 (nv-linux-arm.patch):'
2015/07/02 06:53:50 akmodsbuild: Patch #0 (nv-linux-arm.patch):
2015/07/02 06:53:50 akmodsbuild: + /usr/bin/cat
/tmp/akmodsbuild.wv915hso/SOURCES/nv-linux-arm.patch
2015/07/02 06:53:50 akmodsbuild: + /usr/bin/patch -p1 --fuzz=0
2015/07/02 06:53:50 akmodsbuild: patching file kernel/nv-linux.h
2015/07/02 06:53:50 akmodsbuild: Hunk #1 succeeded at 241 (offset 1 line).
2015/07/02 06:53:50 akmodsbuild: + for kernel_version in
4.0.6-300.fc22.x86_64___/usr/src/kernels/4.0.6-300.fc22.x86_64
2015/07/02 06:53:50 akmodsbuild: + cp -a kernel
_kmod_build_4.0.6-300.fc22.x86_64
2015/07/02 06:53:50 akmodsbuild: + exit 0
2015/07/02 06:53:50 akmodsbuild: Executing(%build): /bin/sh -e
/var/tmp/rpm-tmp.t2o0ZA
2015/07/02 06:53:50 akmodsbuild: + umask 022
2015/07/02 06:53:50 akmodsbuild: + cd /tmp/akmodsbuild.wv915hso//BUILD
2015/07/02 06:53:50 akmodsbuild: + cd nvidia-kmod-346.72
2015/07/02 06:53:50 akmodsbuild: + for kernel_version in
4.0.6-300.fc22.x86_64___/usr/src/kernels/4.0.6-300.fc22.x86_64
2015/07/02 06:53:50 akmodsbuild: + pushd _kmod_build_4.0.6-300.fc22.x86_64/
2015/07/02 06:53:50 akmodsbuild:
/tmp/akmodsbuild.wv915hso/BUILD/nvidia-kmod-346.72/_kmod_build_4.0.6-300.fc22.x86_64
/tmp/akmodsbuild.wv915hso/BUILD/nvidia-kmod-346.72
2015/07/02 06:53:50 akmodsbuild: + make -j4
KERNEL_UNAME=4.0.6-300.fc22.x86_64
SYSSRC=/usr/src/kernels/4.0.6-300.fc22.x86_64 IGNORE_CC_MISMATCH=1
IGNORE_XEN_PRESENCE=1 IGNORE_PREEMPT_RT_PRESENCE=1 module
which is preceded by
2015/07/02 06:53:50 akmodsbuild: NVIDIA: calling KBUILD...
which I'm guessing is the kick off command.
Execute all these?
regards
On 6 July 2015 at 12:59, Ed Greshko <ed.greshko(a)greshko.com> wrote:
On 07/06/15 19:01, Dave Pawson wrote:
> On 6 July 2015 at 11:53, Ed Greshko <ed.greshko(a)greshko.com> wrote:
>
>> Running F22/KDE with GeForce GTX 660 and the nVidia drivers from RPMfusion
(akmod).
>>
>> The problem I see when updating kernels via dnf. dnf has the RPM database locked
so the rpm's can't be installed during the update. Supposedly, that should be
taken care of during the reboot but it hasn't worked for me. So, I just manually do
it as suggested in the akmods.log prior to reboot.
> Sounds good Ed - sorry to sound so ignorant.
> "As suggested in akmods.log"...
> no such file found on my F22 install?
>
> What does 'manually do it' mean please?
The log is in /var/cache/akmods/ called akmods.log
The "failure" looks like this....
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.
And the last line shows you the command to run before you reboot.
--
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk
12:24 p.m.
On 07/06/15 20:10, Dave Pawson wrote:
Thanks Ed.
That's quite a long list... In which order please - top of file down
or last upwards? All have the same timestamp?
<snip>
which I'm guessing is the kick off command.
Execute all these?
I do not believe the lines you quoted are from /var/cache/akmods/akmods.log
I believe they are from
/var/cache/akmods/nvidia-something/something.failed.log
The last line in /var/cache/akmods/akmods.log (at least mine) reads...
2015/06/28 18:26:01 akmods: '/usr/sbin/akmods --force' as root.
So, the command to run before reboot is...
/usr/sbin/akmods --force
12:48 p.m.
On 6 July 2015 at 13:24, Ed Greshko <ed.greshko(a)greshko.com> wrote:
I do not believe the lines you quoted are from
/var/cache/akmods/akmods.log
I believe they are from
/var/cache/akmods/nvidia-something/something.failed.log
Yes, not looking properly - again.
The last line in /var/cache/akmods/akmods.log (at least mine) reads...
2015/06/28 18:26:01 akmods: '/usr/sbin/akmods --force' as root.
So, the command to run before reboot is...
/usr/sbin/akmods --force
2015/07/06 13:00:05 akmods: Hint: Some kmods were ignored or failed to
build or install.
2015/07/06 13:00:05 akmods: You can try to rebuild and install them by
by calling
2015/07/06 13:00:05 akmods: '/usr/sbin/akmods --force' as root.
Quite right.
One to remember!
Much appreciated Ed.
Thanks.
Dave P
--
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk
1 p.m.
Success.. with a tiny proviso.
I tried it running Gnome in a command line. No error message shown, just nothing
happened. (I should have known / guessed)
Rebooted, failed, ^-ALT-F3 to get a CLI. Log in as root
Ran the command /usr/sbin/akmods --force
and akmods built.
# reboot
and I'm in business again.
Thank you.
Dave
On 6 July 2015 at 13:48, Dave Pawson <dave.pawson(a)gmail.com> wrote:
On 6 July 2015 at 13:24, Ed Greshko <ed.greshko(a)greshko.com>
wrote:
> I do not believe the lines you quoted are from /var/cache/akmods/akmods.log
>
> I believe they are from
>
> /var/cache/akmods/nvidia-something/something.failed.log
Yes, not looking properly - again.
>
> The last line in /var/cache/akmods/akmods.log (at least mine) reads...
>
> 2015/06/28 18:26:01 akmods: '/usr/sbin/akmods --force' as root.
>
> So, the command to run before reboot is...
>
> /usr/sbin/akmods --force
2015/07/06 13:00:05 akmods: Hint: Some kmods were ignored or failed to
build or install.
2015/07/06 13:00:05 akmods: You can try to rebuild and install them by
by calling
2015/07/06 13:00:05 akmods: '/usr/sbin/akmods --force' as root.
Quite right.
One to remember!
Much appreciated Ed.
Thanks.
Dave P
--
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk
--
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk
1:07 p.m.
On Mon, Jul 6, 2015 at 8:00 AM, Dave Pawson <dave.pawson(a)gmail.com> wrote:
Success.. with a tiny proviso.
I tried it running Gnome in a command line. No error message shown, just
nothing
happened. (I should have known / guessed)
Rebooted, failed, ^-ALT-F3 to get a CLI. Log in as root
Ran the command /usr/sbin/akmods --force
and akmods built.
# reboot
and I'm in business again.
There is a reason that they failed to rebuild right after kernel update but
it's likely to be the same problem others have experienced, dnf not
releasing it's lock on the rpm database soon enough.
They are not enabled by default (there's a special list of services allowed
to be enabled by default, and akmods isn't on it) but there are two systemd
services you can enable that help in this specific situation.
You can try as root (or sudo):
$ systemctl enable akmods.service
and/or
$ systemctl enable akmods-shutdown.service
The first attempts another rebuild during the boot cycle and the other on
shutdown. Of course if there's a different problem, for instance something
changed in the kernel that the binary drivers haven't accounted for, then
obviously it won't help there.
I'd like to find a way to notify the user on failure but haven't found a
simple way to do that.
Thanks,
Richard
1:26 p.m.
What is curious is that this hasn't been happening until (some version
of) recently?
My hardware setup has been stable for a year or so, so I'm guessing somethign
has changed in Fedora build which has caused this.
I could submit a bug to Fedora - but I'd appreciate phrasing since I'm nowhere
near knowledgable, if that would help?
regards
On 6 July 2015 at 14:07, Richard Shaw <hobbes1069(a)gmail.com> wrote:
On Mon, Jul 6, 2015 at 8:00 AM, Dave Pawson
<dave.pawson(a)gmail.com> wrote:
>
> Success.. with a tiny proviso.
> I tried it running Gnome in a command line. No error message shown, just
> nothing
> happened. (I should have known / guessed)
> Rebooted, failed, ^-ALT-F3 to get a CLI. Log in as root
> Ran the command /usr/sbin/akmods --force
> and akmods built.
> # reboot
> and I'm in business again.
There is a reason that they failed to rebuild right after kernel update but
it's likely to be the same problem others have experienced, dnf not
releasing it's lock on the rpm database soon enough.
They are not enabled by default (there's a special list of services allowed
to be enabled by default, and akmods isn't on it) but there are two systemd
services you can enable that help in this specific situation.
You can try as root (or sudo):
$ systemctl enable akmods.service
and/or
$ systemctl enable akmods-shutdown.service
The first attempts another rebuild during the boot cycle and the other on
shutdown. Of course if there's a different problem, for instance something
changed in the kernel that the binary drivers haven't accounted for, then
obviously it won't help there.
I'd like to find a way to notify the user on failure but haven't found a
simple way to do that.
Thanks,
Richard
--
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk
1:34 p.m.
On Mon, Jul 6, 2015 at 8:26 AM, Dave Pawson <dave.pawson(a)gmail.com> wrote:
What is curious is that this hasn't been happening until (some
version
of) recently?
My hardware setup has been stable for a year or so, so I'm guessing
somethign
has changed in Fedora build which has caused this.
I could submit a bug to Fedora - but I'd appreciate phrasing since I'm
nowhere
near knowledgable, if that would help?\
Unlikely...
This is only a hunch so I would appreciate verification but:
I had the services enabled by default using the post install scripts in the
RPM but systemd was updated to only honor the special list as far as I can
tell. I didn't change the scripts in the package but noticed on a fresh
install that they were not enabled!
Thanks,
Richard
1:37 p.m.
If you want me to do any testing, perhaps skype / irc? and I'll try cmds
on my system?
regards
On 6 July 2015 at 14:34, Richard Shaw <hobbes1069(a)gmail.com> wrote:
On Mon, Jul 6, 2015 at 8:26 AM, Dave Pawson
<dave.pawson(a)gmail.com> wrote:
>
> What is curious is that this hasn't been happening until (some version
> of) recently?
> My hardware setup has been stable for a year or so, so I'm guessing
> somethign
> has changed in Fedora build which has caused this.
>
> I could submit a bug to Fedora - but I'd appreciate phrasing since I'm
> nowhere
> near knowledgable, if that would help?\
Unlikely...
This is only a hunch so I would appreciate verification but:
I had the services enabled by default using the post install scripts in the
RPM but systemd was updated to only honor the special list as far as I can
tell. I didn't change the scripts in the package but noticed on a fresh
install that they were not enabled!
Thanks,
Richard
--
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk
6:08 p.m.
On Mon, Jul 6, 2015 at 8:37 AM, Dave Pawson <dave.pawson(a)gmail.com> wrote:
If you want me to do any testing, perhaps skype / irc? and I'll
try cmds
on my system?
Maybe, I'm pretty tied up for the next couple of days but I may try doing a
fresh install in a virtualmachine and test things out.
Thanks,
Richard
8:25 p.m.
Updated Fedora 22 again tonight.
Exactly the same issue.
repeated Richards advice - again cleared the problem.
regards
On 6 July 2015 at 19:08, Richard Shaw <hobbes1069(a)gmail.com> wrote:
On Mon, Jul 6, 2015 at 8:37 AM, Dave Pawson
<dave.pawson(a)gmail.com> wrote:
>
> If you want me to do any testing, perhaps skype / irc? and I'll try cmds
> on my system?
Maybe, I'm pretty tied up for the next couple of days but I may try doing a
fresh install in a virtualmachine and test things out.
Thanks,
Richard
--
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk
9:59 p.m.
On 07/12/15 04:25, Dave Pawson wrote:
Updated Fedora 22 again tonight.
Exactly the same issue.
repeated Richards advice - again cleared the problem.
FWIW, I am a KDE user and normally update via dnf. However I just tested and if I update
via apper, invoked from systray, the rpms get built and installed without extra work. One
thing to remember, the rebuild/install process happens after apper completes and tells you
your system is up-to-date. So, you need to wait a bit before rebooting to the new
kernel.
5:04 a.m.
Worth knowing.
Apper = KDE interface for PackageKit.
I'll try the GUI interface next time (I'm on Gnome)
Thanks Ed.
On 11 July 2015 at 22:59, Ed Greshko <ed.greshko(a)greshko.com> wrote:
On 07/12/15 04:25, Dave Pawson wrote:
> Updated Fedora 22 again tonight.
> Exactly the same issue.
> repeated Richards advice - again cleared the problem.
FWIW, I am a KDE user and normally update via dnf. However I just tested and if I update
via apper, invoked from systray, the rpms get built and installed without extra work. One
thing to remember, the rebuild/install process happens after apper completes and tells you
your system is up-to-date. So, you need to wait a bit before rebooting to the new kernel.
--
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk
12:16 p.m.
On 06/07/15 14:07, Richard Shaw wrote:
On Mon, Jul 6, 2015 at 8:00 AM, Dave Pawson
<dave.pawson(a)gmail.com
<mailto:dave.pawson@gmail.com>> wrote:
Success.. with a tiny proviso.
I tried it running Gnome in a command line. No error message shown,
just nothing
happened. (I should have known / guessed)
Rebooted, failed, ^-ALT-F3 to get a CLI. Log in as root
Ran the command /usr/sbin/akmods --force
and akmods built.
# reboot
and I'm in business again.
There is a reason that they failed to rebuild right after kernel update
but it's likely to be the same problem others have experienced, dnf not
releasing it's lock on the rpm database soon enough.
They are not enabled by default (there's a special list of services
allowed to be enabled by default, and akmods isn't on it) but there are
two systemd services you can enable that help in this specific situation.
You can try as root (or sudo):
$ systemctl enable akmods.service
and/or
$ systemctl enable akmods-shutdown.service
The first attempts another rebuild during the boot cycle and the other
on shutdown. Of course if there's a different problem, for instance
something changed in the kernel that the binary drivers haven't
accounted for, then obviously it won't help there.
Richard
Excuse me if this was documented elsewhere in this thread, but I didn't
see it explicitly.
I'm seeing the no installed kmod issue after a kernel upgrade and reboot
too. I have those akmods services enabled but they detect that the build
during the nightly update failed (due to the transaction lock issue) and
don't bother to try again. (in my case I use yum-deprecated for the
nightly updates).
2015/07/16 10:43:04 akmods: Checking kmods exist for 4.0.7-300.fc22.x86_64
2015/07/16 10:43:08 akmods: Ignoring nvidia-340xx-kmod as it failed earlier
2015/07/16 10:43:08 akmods: Hint: Some kmods were ignored or failed to
build or install.
2015/07/16 10:43:08 akmods: You can try to rebuild and install them by
by calling
2015/07/16 10:43:08 akmods: '/usr/sbin/akmods --force' as root.
I didn't see a fix for this in your note about the new akmods package
you have in testing or in other recent threads, but I might have
overlooked something.
A dirty workaround for me would be to make the akmods.service file run
/usr/sbin/akmods --force as the ExecStart line, but I have seen reports
on google that you can't easily pass parameters to the ExecStart command
like that.
Can you advise please on the best (automatic) work around.
Thanks
Roderick
12:54 p.m.
On Thu, Jul 16, 2015 at 7:16 AM, Roderick Johnstone <rmj(a)ast.cam.ac.uk>
wrote:
Richard
Excuse me if this was documented elsewhere in this thread, but I didn't
see it explicitly.
I'm seeing the no installed kmod issue after a kernel upgrade and reboot
too. I have those akmods services enabled but they detect that the build
during the nightly update failed (due to the transaction lock issue) and
don't bother to try again. (in my case I use yum-deprecated for the nightly
updates).
Yes, we're talking about two different failure modes. Enabling the services
only helps if the failure was purely due to a simple failure during the
kernel post transaction execution (the behind the scenes run right after a
kernel update).
2015/07/16 10:43:04 akmods: Checking kmods exist for 4.0.7-300.fc22.x86_64
2015/07/16 10:43:08 akmods: Ignoring nvidia-340xx-kmod as it failed
earlier
2015/07/16 10:43:08 akmods: Hint: Some kmods were ignored or failed to
build or install.
2015/07/16 10:43:08 akmods: You can try to rebuild and install them by by
calling
2015/07/16 10:43:08 akmods: '/usr/sbin/akmods --force' as root.
I didn't see a fix for this in your note about the new akmods package you
have in testing or in other recent threads, but I might have overlooked
something.
I'm hoping that since the new akmods script will detect dnf vs. yum that
that will fix a lot of the problems people are having.
A dirty workaround for me would be to make the akmods.service file
run
/usr/sbin/akmods --force as the ExecStart line, but I have seen reports on
google that you can't easily pass parameters to the ExecStart command like
that.
No, options are pretty standard in ExecStart, what you might be thinking of
are other bash commands. Systemd starts executables directly, not within a
"shell" so other things you might expect to work on the command line could
fail but passing options is fine.
Ok, I thought that the --from-init option would also do a force but it
doesn't look like it does. I may add that to ExecStart, the only downside
being that if it's failing for the "right" reason (kernel incompatibility
which happens every now and then) then it will keep trying to build the
module every boot...
Thanks,
Richard
1:20 p.m.
On 16/07/15 13:54, Richard Shaw wrote:
On Thu, Jul 16, 2015 at 7:16 AM, Roderick Johnstone
<rmj(a)ast.cam.ac.uk
<mailto:rmj@ast.cam.ac.uk>> wrote:
I didn't see a fix for this in your note about the new
akmods
package you have in testing or in other recent threads, but I might
have overlooked something.
I'm hoping that since the new akmods script will detect dnf vs. yum that
that will fix a lot of the problems people are having.
Thanks. I'll try your new package when it hits the testing repos.
A dirty workaround for me would be to make the akmods.service file
run /usr/sbin/akmods --force as the ExecStart line, but I have seen
reports on google that you can't easily pass parameters to the
ExecStart command like that.
No, options are pretty standard in ExecStart, what you might be thinking
of are other bash commands. Systemd starts executables directly, not
within a "shell" so other things you might expect to work on the command
line could fail but passing options is fine.
Thanks for the explanation. Having re-read the page I found I see that I
misunderstood what it said.
Roderick
5:57 p.m.
On 16/07/15 14:20, Roderick Johnstone wrote:
On 16/07/15 13:54, Richard Shaw wrote:
> On Thu, Jul 16, 2015 at 7:16 AM, Roderick Johnstone <rmj(a)ast.cam.ac.uk
> <mailto:rmj@ast.cam.ac.uk>> wrote:
> I didn't see a fix for this in your note about the new akmods
> package you have in testing or in other recent threads, but I might
> have overlooked something.
>
>
> I'm hoping that since the new akmods script will detect dnf vs. yum that
> that will fix a lot of the problems people are having.
Thanks. I'll try your new package when it hits the testing repos.
>
> A dirty workaround for me would be to make the akmods.service file
> run /usr/sbin/akmods --force as the ExecStart line, but I have seen
> reports on google that you can't easily pass parameters to the
> ExecStart command like that.
>
>
> No, options are pretty standard in ExecStart, what you might be thinking
> of are other bash commands. Systemd starts executables directly, not
> within a "shell" so other things you might expect to work on the command
> line could fail but passing options is fine.
Thanks for the explanation. Having re-read the page I found I see that I
misunderstood what it said.
Roderick
So, having copied the akmods.service file to /etc/systemd/system (as
Harald Reindl suggested) and added --force it is now building and
installing the kmod on reboot.
(Actually I also removed --from-init which I realise now was probably a
mistake but probably not causing the problems I'm seeing here.)
However, the kernel module is not loaded and so the graphical display
does not start until either I reboot again or change run levels and run
modprobe nvidia.
Any idea whats going on here?
Thanks.
Roderick
8:46 p.m.
On Wed, Jul 22, 2015 at 12:57 PM, Roderick Johnstone <rmj(a)ast.cam.ac.uk>
wrote:
So, having copied the akmods.service file to /etc/systemd/system (as
Harald Reindl suggested) and added --force it is now building and
installing the kmod on reboot.
(Actually I also removed --from-init which I realise now was probably a
mistake but probably not causing the problems I'm seeing here.)
However, the kernel module is not loaded and so the graphical display does
not start until either I reboot again or change run levels and run modprobe
nvidia.
Any idea whats going on here?
Hard to say... It's supposed to run prior to the display manager so I'm not
sure why a reboot at that point would be necessary.
One thing I just noticed is there doesn't seem to be a
display-manager.service symlink anymore, when gdm.service is enabled, an
systemd unit alias to display-manager.service is created... I would think
that would still work but it doesn't seem to be in your case.
I wonder if I should change the requirement to "Before=graphical.target"?
Thanks,
Richard
7:59 a.m.
On 22/07/15 21:46, Richard Shaw wrote:
On Wed, Jul 22, 2015 at 12:57 PM, Roderick Johnstone
<rmj(a)ast.cam.ac.uk
<mailto:rmj@ast.cam.ac.uk>> wrote:
So, having copied the akmods.service file to /etc/systemd/system (as
Harald Reindl suggested) and added --force it is now building and
installing the kmod on reboot.
(Actually I also removed --from-init which I realise now was
probably a mistake but probably not causing the problems I'm seeing
here.)
However, the kernel module is not loaded and so the graphical
display does not start until either I reboot again or change run
levels and run modprobe nvidia.
Any idea whats going on here?
Hard to say... It's supposed to run prior to the display manager so I'm
not sure why a reboot at that point would be necessary.
One thing I just noticed is there doesn't seem to be a
display-manager.service symlink anymore, when gdm.service is enabled, an
systemd unit alias to display-manager.service is created... I would
think that would still work but it doesn't seem to be in your case.
I'm actually using sddm so gdm.service is disabled for me and
sddm.service is enabled.
I do have a sym link:
/etc/systemd/system/display-manager.service ->
/usr/lib/systemd/system/sddm.service
so I'm not sure why its not working as expected.
I wonder if I should change the requirement to "Before=graphical.target"?
I can certainly test that and report back if you like.
Roderick
Thanks,
Richard
10:37 a.m.
On 23/07/15 08:59, Roderick Johnstone wrote:
On 22/07/15 21:46, Richard Shaw wrote:
> On Wed, Jul 22, 2015 at 12:57 PM, Roderick Johnstone <rmj(a)ast.cam.ac.uk
> <mailto:rmj@ast.cam.ac.uk>> wrote:
>
> So, having copied the akmods.service file to /etc/systemd/system (as
> Harald Reindl suggested) and added --force it is now building and
> installing the kmod on reboot.
>
> (Actually I also removed --from-init which I realise now was
> probably a mistake but probably not causing the problems I'm seeing
> here.)
>
> However, the kernel module is not loaded and so the graphical
> display does not start until either I reboot again or change run
> levels and run modprobe nvidia.
>
> Any idea whats going on here?
>
>
> Hard to say... It's supposed to run prior to the display manager so I'm
> not sure why a reboot at that point would be necessary.
>
> One thing I just noticed is there doesn't seem to be a
> display-manager.service symlink anymore, when gdm.service is enabled, an
> systemd unit alias to display-manager.service is created... I would
> think that would still work but it doesn't seem to be in your case.
I'm actually using sddm so gdm.service is disabled for me and
sddm.service is enabled.
I do have a sym link:
/etc/systemd/system/display-manager.service ->
/usr/lib/systemd/system/sddm.service
so I'm not sure why its not working as expected.
>
> I wonder if I should change the requirement to "Before=graphical.target"?
I can certainly test that and report back if you like.
Richard
I tested this and it didn't work. The kmod is installed successfully but
sddm does not start.
Do you know how the kernel module is supposed to get loaded?
Roderick
12:57 p.m.
On Thu, Jul 23, 2015 at 5:37 AM, Roderick Johnstone <rmj(a)ast.cam.ac.uk>
wrote:
I tested this and it didn't work. The kmod is installed successfully but
sddm does not start.
Do you know how the kernel module is supposed to get loaded?
I'm guessing that the kernel tries at boot but the module doesn't get built
and installed until after the kernel is loaded so the module just isn't
there in time.
The more I think about it the more useless the startup script seems to be,
the shutdown one should catch this situation and then the module should be
available on reboot... I need to think about this some more.
Do you also have the shutdown service enabled?
Thanks,
Richard
1:22 p.m.
On 23/07/15 13:57, Richard Shaw wrote:
On Thu, Jul 23, 2015 at 5:37 AM, Roderick Johnstone
<rmj(a)ast.cam.ac.uk
<mailto:rmj@ast.cam.ac.uk>> wrote:
I tested this and it didn't work. The kmod is installed successfully
but sddm does not start.
Do you know how the kernel module is supposed to get loaded?
I'm guessing that the kernel tries at boot but the module doesn't get
built and installed until after the kernel is loaded so the module just
isn't there in time.
The more I think about it the more useless the startup script seems to
be, the shutdown one should catch this situation and then the module
should be available on reboot... I need to think about this some more.
Do you also have the shutdown service enabled?
No, I don't.
So then I guess it would need to rebuild the kmod for all installed
kernels, not just the currently running one as it can't know which
kernel you might want to boot, although the latest would probably be a
good guess.
Roderick
Thanks,
Richard
2:36 p.m.
On Thu, Jul 23, 2015 at 8:22 AM, Roderick Johnstone <rmj(a)ast.cam.ac.uk>
wrote:
Do you also have the shutdown service enabled?
>
No, I don't.
So then I guess it would need to rebuild the kmod for all installed
kernels, not just the currently running one as it can't know which kernel
you might want to boot, although the latest would probably be a good guess.
Well the answer to your first statement is no then yes then no :)
For some reason I setup the shutdown service to run akmods directly instead
of calling a script which would "collect" the installed kernels, so no, it
would only try to build for the current kernel via "uname -r".
Then yes, because I just changed the service file to run a script which
would grab all of the installed kernels and pass them to akmods.
Then no, because it can only build kernel modules for kernels that have the
appropriate kernel-devel package installed, but currently unlike the kernel
itself, only one kernel-devel package is typically installed at one time. :)
Could you follow all that?
So basically once I build new packages, the shutdown script will attempt to
build modules for every kernel-devel package installed, whether it be the
latest or not (though it typically should be).
Ok, now that that's covered I have a crazy idea... For systemd service type
"oneshot" which the akmod service is, you can have multiple ExecStart=
directives. Why couldn't we have two, something like:
[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/sbin/akmods --from-init
ExecStart=-/usr/sbin/modprobe nvidia
Anything know why that wouldn't work? That should fix the problem with
building modules on startup.
Thanks,
Richard
3:58 p.m.
On 23/07/15 15:36, Richard Shaw wrote:
On Thu, Jul 23, 2015 at 8:22 AM, Roderick Johnstone
<rmj(a)ast.cam.ac.uk
<mailto:rmj@ast.cam.ac.uk>> wrote:
Do you also have the shutdown service enabled?
No, I don't.
So then I guess it would need to rebuild the kmod for all installed
kernels, not just the currently running one as it can't know which
kernel you might want to boot, although the latest would probably be
a good guess.
Well the answer to your first statement is no then yes then no :)
For some reason I setup the shutdown service to run akmods directly
instead of calling a script which would "collect" the installed kernels,
so no, it would only try to build for the current kernel via "uname -r".
Then yes, because I just changed the service file to run a script which
would grab all of the installed kernels and pass them to akmods.
Then no, because it can only build kernel modules for kernels that have
the appropriate kernel-devel package installed, but currently unlike the
kernel itself, only one kernel-devel package is typically installed at
one time. :)
Could you follow all that?
All except the last, which I can follow but doesn't seem to accord with
my systems.
Given that you need to install kernel-devel to build the kmod the first
time I would have expected it to be upgraded with each kernel.
Oh, but wait, kernels get installed, not upgraded, so I see your point
except that on my systems I do seem to have kernel-devel for each kernel
thats installed and I only installed kernel-devel once. Maybe though
this is a yum/dnf behaviour change - I use yum-deprecated rather than
dnf for nightly updates.
So basically once I build new packages, the shutdown script will attempt
to build modules for every kernel-devel package installed, whether it be
the latest or not (though it typically should be).
That sounds good.
Ok, now that that's covered I have a crazy idea... For systemd service
type "oneshot" which the akmod service is, you can have multiple
ExecStart= directives. Why couldn't we have two, something like:
[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/sbin/akmods --from-init
ExecStart=-/usr/sbin/modprobe nvidia
Anything know why that wouldn't work? That should fix the problem with
building modules on startup.
That might be ok but I don't know enough about systemd to know if the
two ExecStart lines are run synchronously. Maybe you need the --force as
well on the akmods line?
Later...I just tested it and it worked!
Great idea.
Thanks.
Roderick
4:07 p.m.
On Thu, Jul 23, 2015 at 10:58 AM, Roderick Johnstone <rmj(a)ast.cam.ac.uk>
wrote:
On 23/07/15 15:36, Richard Shaw wrote:
> Oh, but wait, kernels get installed, not upgraded, so I see your point
> except that on my systems I do seem to have kernel-devel for each kernel
> thats installed and I only installed kernel-devel once. Maybe though this
> is a yum/dnf behaviour change - I use yum-deprecated rather than dnf for
> nightly updates.
>
That's likely the issue. I thought the same as well but noticed I only have
one kernel-devel package installed (and it wasn't even the latest one!) dnf
still needs some polishing for sure!
Ok, now that that's covered I have a crazy idea... For systemd
service
>
type "oneshot" which the akmod service is, you can have multiple
> ExecStart= directives. Why couldn't we have two, something like:
>
> [Service]
> Type=oneshot
> RemainAfterExit=true
> ExecStart=/usr/sbin/akmods --from-init
> ExecStart=-/usr/sbin/modprobe nvidia
>
> Anything know why that wouldn't work? That should fix the problem with
> building modules on startup.
>
That might be ok but I don't know enough about systemd to know if the two
ExecStart lines are run synchronously. Maybe you need the --force as well
on the akmods line?
No, with oneshot+multiple ExecStart's they are run in order, the first one
must exit (and exit cleanly) before the next one is executed.
I'm not sure if you noticed that I moved the "-" at the beginning. This
tells systemd to treat it like it succeeds even if it fails (non-zero
exit). Since there's no point in running modpobe if akmods failed i moved
it to the modprobe line.
I don't want to use --force in case there's a real problem with building
the rpms, but I altered the akmods script (I hope correctly) to not treat
failure to install a permanent failure so it should try again the next time
akmods is run.
Later...I just tested it and it worked!
Good to hear! Anyone want to try a testing package? I don't want to build
an official package yet because we still don't have bodhi for updates so
there's no way to stop it from being pushed to stable without a direct
email to a human.
Thanks,
Richard
4:23 p.m.
I'm not sure if you noticed that I moved the "-" at the beginning. This
tells systemd to treat it like it succeeds even if it fails (non-zero
exit). Since there's no point in running modpobe if akmods failed i
moved it to the modprobe line.
I noticed that the modprobe line had a '-', and was wondering what it
did, and I failed to see that you had removed the '-' from the akmods line!
Later...I just tested it and it worked!
Good to hear! Anyone want to try a testing package? I don't want to
build an official package yet because we still don't have bodhi for
updates so there's no way to stop it from being pushed to stable without
a direct email to a human.
Yes, I'm happy to try a testing package.
Roderick
5:15 p.m.
On 23/07/15 17:07, Richard Shaw wrote:
On Thu, Jul 23, 2015 at 10:58 AM, Roderick Johnstone
<rmj(a)ast.cam.ac.uk
<mailto:rmj@ast.cam.ac.uk>> wrote:
On 23/07/15 15:36, Richard Shaw wrote:
Oh, but wait, kernels get installed, not upgraded, so I see your
point except that on my systems I do seem to have kernel-devel
for each kernel thats installed and I only installed
kernel-devel once. Maybe though this is a yum/dnf behaviour
change - I use yum-deprecated rather than dnf for nightly updates.
That's likely the issue. I thought the same as well but noticed I only
have one kernel-devel package installed (and it wasn't even the latest
one!) dnf still needs some polishing for sure!
There seems to be some relevant discussion at:
https://bugzilla.redhat.com/show_bug.cgi?id=1062997
and related bugs.
Roderick
12:56 p.m.
Am 16.07.2015 um 14:16 schrieb Roderick Johnstone:
2015/07/16 10:43:04 akmods: Checking kmods exist for
4.0.7-300.fc22.x86_64
2015/07/16 10:43:08 akmods: Ignoring nvidia-340xx-kmod as it failed earlier
2015/07/16 10:43:08 akmods: Hint: Some kmods were ignored or failed to
build or install.
2015/07/16 10:43:08 akmods: You can try to rebuild and install them by
by calling
2015/07/16 10:43:08 akmods: '/usr/sbin/akmods --force' as root.
I didn't see a fix for this in your note about the new akmods package
you have in testing or in other recent threads, but I might have
overlooked something.
there is likely a akmods folders in /var/lib/ as for any other software
with runtime data, the information about the previous fail is there
so just purge that folder - due package install on a virgin setup it's
empty by definition
A dirty workaround for me would be to make the akmods.service file
run
/usr/sbin/akmods --force as the ExecStart line, but I have seen reports
on google that you can't easily pass parameters to the ExecStart command
like that
nonsense - most services are using params and it's no problem disable a
service, clone it's unit in /etc/systemd/system/, modify it there and
enable the service again so it don't get overwritten by updates
12:13 p.m.
ps - that last file dump is from
/var/cache/akmods/nvidia/346.72-2.1-for-4.0.6-300.fc22.x86_64.failed.log
which suggests it failed as you say.
regards
On 6 July 2015 at 12:59, Ed Greshko <ed.greshko(a)greshko.com> wrote:
On 07/06/15 19:01, Dave Pawson wrote:
> On 6 July 2015 at 11:53, Ed Greshko <ed.greshko(a)greshko.com> wrote:
>
>> Running F22/KDE with GeForce GTX 660 and the nVidia drivers from RPMfusion
(akmod).
>>
>> The problem I see when updating kernels via dnf. dnf has the RPM database locked
so the rpm's can't be installed during the update. Supposedly, that should be
taken care of during the reboot but it hasn't worked for me. So, I just manually do
it as suggested in the akmods.log prior to reboot.
> Sounds good Ed - sorry to sound so ignorant.
> "As suggested in akmods.log"...
> no such file found on my F22 install?
>
> What does 'manually do it' mean please?
The log is in /var/cache/akmods/ called akmods.log
The "failure" looks like this....
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.
And the last line shows you the command to run before you reboot.
--
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk
12:44 p.m.
On 07/06/15 20:13, Dave Pawson wrote:
ps - that last file dump is from
/var/cache/akmods/nvidia/346.72-2.1-for-4.0.6-300.fc22.x86_64.failed.log
which suggests it failed as you say.
Yes, that is the file that I refereed to in my previous message as
/var/cache/akmods/nvidia-something/something.failed.log
(FWIW, my *failed* logs are in /var/cache/akmods/nvidia-304xx since i use the 304xx
driver)
The log file I'm talking about is
/var/cache/akmods/akmods.log
3193
days inactive
3210
days old
rpmfusion-users@lists.rpmfusion.org
32 comments
5 participants
participants (5)
-
Dave Pawson -
Ed Greshko -
Reindl Harald -
Richard Shaw -
Roderick Johnstone