I came to work today and glanced at the yum logs. When it installs a new kernel, but it cannot find the module RPMs for it, then it goes ahead and installs the new kernel, and removes the module RPMs for the older version of the kernel. I think this is really bad yum behavior. It is the second machine on which I've seen it do this.
Mar 17 05:15:59 Updated: numactl.x86_64 0.9.8-5.fc8 Mar 17 05:16:00 Updated: shared-mime-info.x86_64 0.23-1.fc8 Mar 17 05:16:01 Updated: kexec-tools.x86_64 1.102pre-7.fc8 Mar 17 05:16:02 Updated: gdb.x86_64 6.6-45.fc8 Mar 17 05:16:05 Updated: selinux-policy.noarch 3.0.8-93.fc8 Mar 17 05:16:18 Updated: selinux-policy-targeted.noarch 3.0.8-93.fc8 Mar 17 05:16:37 Installed: kernel.x86_64 2.6.24.3-34.fc8 Mar 17 05:16:44 Installed: kernel-devel.x86_64 2.6.24.3-34.fc8 Mar 17 05:16:46 Updated: kernel-headers.x86_64 2.6.24.3-34.fc8 Mar 17 05:16:53 Installed: kernel-debug-devel.x86_64 2.6.24.3-34.fc8 Mar 17 05:16:53 Erased: kmod-nvidia-2.6.23.15-137.fc8 Mar 17 05:16:57 Erased: xorg-x11-drv-nvidia-libs Mar 17 05:17:13 Erased: kmod-nvidia Mar 17 05:17:14 Erased: kmod-nvidia-2.6.24.3-12.fc8 Mar 17 05:17:24 Erased: xorg-x11-drv-nvidia
The kernel, that is STILL RUNNING, is
# uname -r 2.6.23.15-137.fc8
And yum has not removed that kernel (whew!)
# rpm -q kernel kernel-2.6.23.15-137.fc8 kernel-2.6.24.3-34.fc8
But you will see in the above output that the kmod-nvidia was for 2.6.23.15-137.fc8 was removed.
It must be that livna's kmod RPMS were not available when the yum process updated the kernel. Now they are, I can install manually:
# yum install kmod-nvidia Loading "fastestmirror" plugin Loading mirror speeds from cached hostfile * kde: kdeforge.unl.edu * livna: mirrors.tummy.com * fedora: mirror.nuvio.com * kde-all: kdeforge.unl.edu * adobe-linux-i386: linuxdownload.adobe.com * updates: mirror.nuvio.com Setting up Install Process Parsing package install arguments Resolving Dependencies --> Running transaction check ---> Package kmod-nvidia.x86_64 0:169.12-3.lvn8 set to be updated --> Processing Dependency: kmod-nvidia-2.6.24.3-34.fc8 = 169.12-3.lvn8 for package: kmod-nvidia --> Running transaction check ---> Package kmod-nvidia-2.6.24.3-34.fc8.x86_64 0:169.12-3.lvn8 set to be updated --> Processing Dependency: nvidia-kmod-common >= 169.12 for package: kmod-nvidia-2.6.24.3-34.fc8 --> Running transaction check ---> Package xorg-x11-drv-nvidia.x86_64 0:169.12-1.lvn8 set to be updated filelists.xml.gz 100% |=========================| 477 kB 00:00
But I certainly don't want yum removing the older ones.
I can't believe I'm the only one seeing this, but nobody else is yelling about it, so I must be the only one. That makes me think I've got something configured incorrectly. I can report in bugzilla, but won't do that until I'm sure it is not some bonehead mistake I've made. At least I'm consistent. It is happening on all the PCs I administer...
Paul Johnson wrote:
I came to work today and glanced at the yum logs. When it installs a ... I can't believe I'm the only one seeing this, but nobody else is yelling about it, so I must be the only one. That makes me think I've got something configured incorrectly. I can report in bugzilla, but won't do that until I'm sure it is not some bonehead mistake I've made. At least I'm consistent. It is happening on all the PCs I administer...
Re the Nvidia drivers, no you're not making any mistake, this is a problem with the livna nvidia packaging, the problem is they update the version numbers and the kernel module barfs when it sees a different version number (I think) so they remove the old module.
I just reverted to doing the nvidia install manually you need to unpack the Nvidia-blah.run using the -x flag, change to that unpacked NVIDIA directory and run nvidia-installer -K to just install a new kernel module.
Having said that the livna packages are certainly easy and a good thing, just not if you have a new kernel with bugs (like the 2.6.24 kernels)
Cheers, Peter.
On Wed, 2008-03-19 at 09:02 +1100, Peter McNeil wrote:
Paul Johnson wrote:
I came to work today and glanced at the yum logs. When it installs a ... I can't believe I'm the only one seeing this, but nobody else is yelling about it, so I must be the only one. That makes me think I've got something configured incorrectly. I can report in bugzilla, but won't do that until I'm sure it is not some bonehead mistake I've made. At least I'm consistent. It is happening on all the PCs I administer...
Re the Nvidia drivers, no you're not making any mistake, this is a problem with the livna nvidia packaging, the problem is they update the version numbers and the kernel module barfs when it sees a different version number (I think) so they remove the old module.
I just reverted to doing the nvidia install manually you need to unpack the Nvidia-blah.run using the -x flag, change to that unpacked NVIDIA directory and run nvidia-installer -K to just install a new kernel module.
Having said that the livna packages are certainly easy and a good thing, just not if you have a new kernel with bugs (like the 2.6.24 kernels)
I believe the problem here was that the nVidia module version was updated from something like 169.4 to 169.12. Because no 169.12 was built for the old kernel, the old nVidia module was erased. The kernel version numbers are part of the kmod RPM name, not its version.
You can build the new nVidia driver RPMs for the old kernel yourself from the Livna SRPM. Instructions are in the recent archives of this mailing list.
Cheers, Peter.
Peter McNeil wrote:
Paul Johnson wrote:
I came to work today and glanced at the yum logs. When it installs a ... I can't believe I'm the only one seeing this, but nobody else is yelling about it, so I must be the only one. That makes me think I've got something configured incorrectly. I can report in bugzilla, but won't do that until I'm sure it is not some bonehead mistake I've made. At least I'm consistent. It is happening on all the PCs I administer...
Re the Nvidia drivers, no you're not making any mistake, this is a problem with the livna nvidia packaging, the problem is they update the version numbers and the kernel module barfs when it sees a different version number (I think) so they remove the old module.
I just reverted to doing the nvidia install manually you need to unpack the Nvidia-blah.run using the -x flag, change to that unpacked NVIDIA directory and run nvidia-installer -K to just install a new kernel module.
Having said that the livna packages are certainly easy and a good thing, just not if you have a new kernel with bugs (like the 2.6.24 kernels)
Cheers, Peter.
For Nvidia, I use the freshrpms version as it uses dkms and will re-create the module on reboot. No waiting or re-installing due to livna being seconds behind the release of the new kernel. :)
On Wed, Mar 19, 2008 at 11:58 AM, Robin Laing Robin.Laing@drdc-rddc.gc.ca wrote:
Cheers, Peter.
For Nvidia, I use the freshrpms version as it uses dkms and will re-create the module on reboot. No waiting or re-installing due to livna being seconds behind the release of the new kernel. :)
-- Robin Laing
Aside from the "what the hell have they done now" reaction, I guess I'll have to go look into it.
I do have other modules and I don't want yum to remove them.
I've filed a bug report on this,
https://bugzilla.redhat.com/show_bug.cgi?id=438181
One user already responded that
yum-fedorakmod
Is supposed to prevent. I'll try, but I'm not optimistic because not all modules follow the "Fedora Extras packaging standards" described in that package's information. For example, I have been using for a very long time a kernel module called openafs-kernel. I know it can be repackaged as kmod-openafs, but doing so would break about 20 machines. So I don't want to.