From Bugzilla Helper: User-Agent: Mozilla/4.76C-CCK-MCD Netscape [en] (X11; U; SunOS 5.8 sun4u) Description of problem: Due to iptables problems... It says I need an updated kernel (2.4.3-12) I updated using the up2date utility.. it automatically installed the new kernel and modified the /etc/lilo.conf (which I am very impressed with). but here-in lies the problem. It leave the old kernel installed for a backup. which is a good idea, but the RHN page for some reason doesnt see the new kernel. it only sees the old one. This is similar to BUG # 39884 .. but this is not generated by a user installing two versions of the RPM, the up2date utility did it. I have since removed the old kernel, and now it is happy.. but I thought I would report it just the same. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Install RH 7.1 (I always do a complete install, not sure if that matters) 2. run rhn_register 3. entitle the machine on RHN website. 4. run up2date, and update all packages.. including the kernel 5. run lilo ??? 6. reboot Actual Results: went back to RHN website.. and it still thought I needed the update. I ran up2date -p several times just to be sure. Expected Results: it would see I had the newer kernel installed and in use, and quit bugging me :) Additional info: rpm -q kernel rpm -e kernel-OLD.VERSION this seems to be a workaround, but shouldn't need to be done.
FWIW, I was seeing this under 7.2 as well; I was originally running kernel-2.4.9-7, got the new kernel-2.4.9-13, installed it (I do the "download only, issue RPM commands myself" thang), and ran up2date -p to update my package list with RHN. Rerunning up2date at that point showed that it wanted me to download kernel-2.4.9-13 again, even though it was already installed. At this point I was still running 2.4.9-7, so I rebooted into the new kernel -- no change. Just for the sake of completeness, I reran update -p -- no change. Finally, I did an rpm -e kernel-2.4.9-7 -- that removed kernel-2.4.9-13 from the list of packages to be downloaded. I was surprised that I didn't have to run up2date -p to have RHN notice the change in installed packages, but that's what happened...
I have been seeing the same behavior myself. Here is the output: [root@gemini 2.4.9-13]# up2date -l Retrieving list of all available packages... ######################################## Removing installed packages from list of updates... ######################################## Removing packages marked to skip from list... ######################################## Getting headers for available packages... ######################################## Removing packages with files marked to skip from list... ######################################## Name Version Rel -------------------------------------------------------------- kernel 2.4.9 13 ttfonts-ja 1.0 7 [root@gemini 2.4.9-13]# rpm -q kernel kernel-2.4.9-7 kernel-2.4.9-13 [root@gemini 2.4.9-13]# uname -a Linux gemini 2.4.9-13 #1 Tue Oct 30 20:11:04 EST 2001 i686 unknown [root@gemini 2.4.9-13]# up2date -p Updating package profile... [root@gemini 2.4.9-13]# up2date -l Retrieving list of all available packages... ######################################## [snipped, was same as above] Removing packages with files marked to skip from list... ######################################## Name Version Rel -------------------------------------------------------------- kernel 2.4.9 13 ttfonts-ja 1.0 7 [root@gemini 2.4.9-13]#
I could cut and paste results from my system, but they would appear identical to those posted by tomg Running kernel 2.4.9-13 and up2date still wants to install multiple copies. Have to rpm -e --allmatches kernel-2.4.9-13 to remove and then manually reinstall one copy only.
I can echo Ed's results--had both 2.4.9-7 & 2.4.9-13 and after I removed 2.4.9-7, I'm not seeing this error anymore.
This has been an open issue for quite some time, the problem being that (a) we keep duplicate kernels listed in the RPM database; (b) if we saw an old version of the kernel, we were forced to assume that you might be running it; and (c) we've yet to come up with a clever way of reconciling (a) and (b). Any insights? Can we solve this issue via messaging?
belive this is closed "well enough" with the checking stuff and the current website.