10:51 p.m.
I am using the standard nvidia kmod on f17. I was surprised today, when
doing yum update, that I got a new kernel installed without the
corresponding nvidia kmod.
I thought this was fixed long ago? Shouldn't the deps be setup to prevent
this from happening?
I know how to rescue my system, but many users might not.
11:13 p.m.
On Sun, Nov 11, 2012 at 5:51 PM, Neal Becker <ndbecker2(a)gmail.com> wrote:
I am using the standard nvidia kmod on f17. I was surprised today,
when
doing yum update, that I got a new kernel installed without the
corresponding nvidia kmod.
I thought this was fixed long ago? Shouldn't the deps be setup to prevent
this from happening?
I know how to rescue my system, but many users might not.
I supported a Fedora user who was legally blind, and she knew enough to
boot into an older kernel if it was available, but other than that this is
not something she could handle without additional help.
Her system was multi-boot and one partition was Ubuntu 12.04 and it did not
require a new nvidia package every time the kernel was updated. Ubuntu
uses dkms to build the new nvidia module when a new kernel is installed.
So why does Fedora require a new nvidia package with every kernel?
Chuck
2:57 a.m.
Ubuntu uses dkms to build the new nvidia module when a new kernel
is
installed. So why does Fedora require a new nvidia package with every
kernel?
In short: Fedora ships nouveau.
nVidia ships an ugly and invasive setup.
RPMFusion repackages the later as (a)kmod-nvidia.
Akmod is similar to DKMS, it builds kmod-nvidia.
http://rpmfusion.org/Howto/nVidia#Akmods
I used akmod myself no later than Friday, while I needed to "back test"
a few previous kernels as I was investigating a kernel issue. Running
`akmod --kernels` did build and install kmod packages flawlessly every
time. It just rocks :)
As a bonus, akmod also registers itself as a service, so it autobuilds
the missing kmod at boot-time as required.
But this part did fail here, for at least two of my kernels: the akmod
boot service *was* registered but it didn't function, so X was started
and crash immediately with a missing module error message (in
Xorg.0.log, not on screen). On display, the system appeared to be just
hung, still showing the page of "[OK]" messages as in boot.log, while
none of the ttys were accessible. Ctrl+Alt+Sup did react, thou.
Rebooting into runlevel 3, then just running `akmod`, did work
immediately, and solved the issue. I didn't investigate any further.
11:16 p.m.
I have given up on nVidia kmod drivers. I had the same issues and finally
switched back to using the neuveau drivers which work just fine for my needs.
On 11/11/2012 05:51 PM, Neal Becker wrote:
I am using the standard nvidia kmod on f17. I was surprised today,
when doing
yum update, that I got a new kernel installed without the corresponding nvidia
kmod.
I thought this was fixed long ago? Shouldn't the deps be setup to prevent
this from happening?
I know how to rescue my system, but many users might not.
--
*********************************************************
David P. Both, RHCE
Millennium Technology Consulting LLC
919-389-8678
dboth(a)millennium-technology.com
www.millennium-technology.com
www.databook.bz - Home of the DataBook for Linux
DataBook is a Registered Trademark of David Both
3:30 a.m.
finally switched back to using the neuveau drivers which work just
fine
for my needs.
And finally, me too : nouveau was always entirely unusable and very
unstable on this hardware (the "legendary" overheating 8600M GT, see
nvidiadefect.com && wikipedia), up to and including 3.4.7 kernel at least.
With 3.6.6-1 (or earlier), all these nouveau bugs affecting this card
seem to be fixed now, video and opengl look great, xrandr works, system
is even significantly cooler *and* more reactive than with nvidia
driver, which was already "just fine for my needs"... 5-10º and 20%, how
can ? Day 2, counting ;-)
2:45 a.m.
I am using the standard nvidia kmod on f17. I was surprised today,
when
doing yum update, that I got a new kernel installed without the
corresponding nvidia kmod.
If you cannot use the akmod package but need the kmod one, and also need
to accept package updates from fedora without reviewing them first,
then, maybe you could exclude kernel* until review ?
I thought this was fixed long ago?
I don't think "this" is a piece of software, and each time I noticed
kmod was *yet* in stable, hence inviting me to exclude *nvidia* or
retrieve kernel from UPT, to the opposite I felt pretty thankful to
"Leigh, Nicolas & Co. Inc." for being so quick :)
(and mirrors might be at play too)
Shouldn't the deps be setup to prevent this from happening?
Is it achievable with deps ? Could a distinct, concurrent kernel being
installed from fedora, which does *not* depend on kmod from rpmfusion,
require a given version of kmod if and only if kmod is installed ?
Isn't akmod meant to solve this -- otherwise scripting yum ?
I know how to rescue my system, but many users might not.
Yes still, very popular request for help on IRC :s
3:28 a.m.
On Dom, 2012-11-11 at 17:51 -0500, Neal Becker wrote:
I am using the standard nvidia kmod on f17. I was surprised today,
when doing yum update, that I got a new kernel installed without the
corresponding nvidia kmod.
you should install kmod-nvidia (the meta package)
repoquery -qi kmod-nvidia
Description :
This is a meta-package without payload which sole purpose is to require
the
nvidia kernel module(s) for the newest kernel.
to make sure you get it together with a new kernel.
--
Sérgio M. B.
7:45 a.m.
2012/11/11 Neal Becker <ndbecker2(a)gmail.com>:
I am using the standard nvidia kmod on f17. I was surprised today,
when
doing yum update, that I got a new kernel installed without the
corresponding nvidia kmod.
Actually the kmod was pushed "before" the new
kernel by misstake.
So this should have been the opposite.
There are several problems that might be fixed:
- The rpmfusion mirror your've used might not be updated in time
- Mirrormanager doesn't remove outdated mirrors from the list.
- Your rpmfusion yum metadata cache doesn't get renewed at the same
time as the fedora one.
Anyway we cannot be sure to have the kernel and kmod push at the exact
same time, we can only try to reduce the time, when both appears.
I thought this was fixed long ago? Shouldn't the deps be setup
to prevent
this from happening?
Then this could be fixed at the rpm/yum level, by a
specialized yum plugins.
One way I was thinking was to fetch the matching kmod from
rpmfusion-*-updates-testing instead.
Others suggested to disable the new kernel update to stay on the
previous kernel.
But this problem is discussed from time to time, then nothing stays.
So someone really need to sort out some specification about describing
the problem and how to solve it. This could start from the rpmfusion
wiki.
I know how to rescue my system, but many users might not.
Users
could be advertised to use akmod- instead. But this is unlikely
to solve thing in a secure boot environnement if we manage to sign the
kernel modules.
The shortest plan for nvidia, could be to make a validation test, and
to be abble to disable nvidia when the module isn't present.
Nicolas (kwizart)
8:44 a.m.
Hi,
while we're on the subject, would it be possible to keep older versions
of xorg-x11-nvidia* packages available, too, for a while atleast after the
update so that we get a time to test the new ones and, most importantly,
get a chance to downgrade if we they don't work properly.
The kmod packages apparently are kept for a while, but without
xorg-x11-nvidia* packages, yum downgrade just won't work.
This was an issue with 304.51 upgrading to 304.60 because
brightness controls broke for some laptops, mine included,
and I had to remake the 304.51 src.rpm manually, not a problem for
me, but I suspect it might be for some.
Of course users could try not not to clean them from their caches,
but I'm pointing this out because the kmods are kept and it makes it seem
like a job half done which keeping the xorg-x11-nvidia packages would
complete.
And for the record, the 304.64 won't fix that problem either.
So I'm sticking with the 304.51.
(this is essentially rpmfusion bugzilla entry #2446 but there
seems to be little action there)
cheers,
Tommi Kyntola
On 11/12/12 09:45, Nicolas Chauvet wrote:
2012/11/11 Neal Becker <ndbecker2(a)gmail.com>:
> I am using the standard nvidia kmod on f17. I was surprised today, when
> doing yum update, that I got a new kernel installed without the
> corresponding nvidia kmod.
Actually the kmod was pushed "before" the new kernel by misstake.
So this should have been the opposite.
There are several problems that might be fixed:
- The rpmfusion mirror your've used might not be updated in time
- Mirrormanager doesn't remove outdated mirrors from the list.
- Your rpmfusion yum metadata cache doesn't get renewed at the same
time as the fedora one.
Anyway we cannot be sure to have the kernel and kmod push at the exact
same time, we can only try to reduce the time, when both appears.
> I thought this was fixed long ago? Shouldn't the deps be setup to prevent
> this from happening?
Then this could be fixed at the rpm/yum level, by a specialized yum plugins.
One way I was thinking was to fetch the matching kmod from
rpmfusion-*-updates-testing instead.
Others suggested to disable the new kernel update to stay on the
previous kernel.
But this problem is discussed from time to time, then nothing stays.
So someone really need to sort out some specification about describing
the problem and how to solve it. This could start from the rpmfusion
wiki.
> I know how to rescue my system, but many users might not.
Users could be advertised to use akmod- instead. But this is unlikely
to solve thing in a secure boot environnement if we manage to sign the
kernel modules.
The shortest plan for nvidia, could be to make a validation test, and
to be abble to disable nvidia when the module isn't present.
Nicolas (kwizart)
4182
days inactive
4183
days old
rpmfusion-users@lists.rpmfusion.org
8 comments
7 participants
participants (7)
-
Chuck Peters -
David Both -
Neal Becker -
Nicolas Chauvet -
Sérgio Basto -
Tommi Kyntola -
Xavier Hourcade