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)