From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030206
Description of problem:
On my athlon desktop, I have the following kernels installed:
(these are the 3 latest kernels of each phoebe channel, that I installed so that
I could go back to them in case the new 2.48 kernel gets me in trouble)
today, I registered my desktop with RHN, and then the rhn-applet started
blinking the red sign saying there were updates available. It turned out that
the only update it claims to be available is kernel-2.4.20-2.48, alongside,
alongside with 2.4.20-2.48 as the `version installed'.
RHN does know that I have this kernel installed, because both up2date and the
web pages say my system is fully updated.
I used to have the 2.2 kernel in phoebe2, along with 2.24, so I know it used to
work before. There was a difference, though: these 3 kernels were present at
the time I register this phoebe3 box, whereas the -2.2 kernel was added to the
phoebe2 box post RHN registration. Not that it should matter...
Version-Release number of selected component (if applicable):
Steps to Reproduce:
2.Install kernels from phoebe2 and phoebe1
3.Register the machine with RHN
Actual Results: RHN applet goes blinking and says there's a kernel update from
what I have to what I have.
Expected Results: It shoudln't.
Hum, might be a cache coherency problem.
can you do an "ls -l ~/.rhn-applet.cache /var/lib/rpm/Packages"
What happens if you log in with a new user ?
What happens if you stop the applet, remove ~/.rhn-applet.cache and restart
the applet ?
Whatever the problem was, it was gone when I logged in today, even before I
removed the old kernels and ran up2date -p (just because yesterday I stressed
the kernel enough to figure I wouldn't need the old kernels any longer).
So I suppose one critical step to duplicate the problem is to be logged in, with
the rhn applet running, when you register the machine. If you register and then
log in, the problem likely doesn't happen. It may be that it also requires a
cache in the home directory from a Phoebe2 (or any other release) install, who
Anyway, problem is gone on my end, but it will probably bite anyone who does
like I did. Still, is any of the information you requested still useful at this
Hum, no. Since you apparently closed and restarted the session,
the timestamp on the ~/.rhn-applet.cache is likely to have changed...
I'm seeing the same thing. I've been logged into Gnome for days, and fully
up2dated. This morning, rhn-applet was blue. This evening when I got home, it
was red. When I clicked on it to see what errata was available, I was told that
the ethereal and ethereal-gnome errata (which were released this afternoon) were
available. I was also told that the kernel I have installed
(kernel-smp-2.4.20-9) was available.
Screenshot attached in a sec
Created attachment 91268 [details]
rhn-applet erroneously claiming kernel errata available
Also, here's the cache timestamps:
[kaboom@verdande kaboom]$ ls -l ~/.rhn-applet.cache /var/lib/rpm/Packages
-rw-rw-r-- 1 kaboom kaboom 236384 Apr 23 14:31
-rw-r--r-- 1 rpm rpm 34775040 Apr 20 22:43 /var/lib/rpm/Packages
(before I install the ethereal errata)
Hum, how did you update the kernel to kernel-smp-2.4.20-9,
did you use up2date or did you ran the rpm command manually ?
In the last case this can result in a mismatch between what
the RHN server think you have installed and what is actually
availble locally, usually running "up2date -p" fixes this
mismatch. Though this should not impact the applet I'm still
looking for reasons why this happens, and one of the specificities
of the kernel is that it's often not installed via up2date...
I used up2date
Same thing again. I up2dated to the 2.4.20-13.9 kernel a couple of days ago.
This morning, the crack-smoking rhn-applet is red, claiming that I need to
upgrade to the kernel I'm currently running.
Created attachment 91721 [details]
picture of broken up2date
If I now run up2date, it tells me my system is fully up2date (which is true)
The rhn-applet stays red, though.
Last night, rhn-applet was red, still claiming the kernel needed upgrading to
the installed kernel
When I ran up2date, it installed the gpg errata, and rhn-applet then went blue
This morning, rhn-applet is once again red, and once again claims that I need to
upgrade to kernel-smp-2.4.20-13.9, and that I have kernel-smp-2.4.20-13.9
I'm seeing this too. It was a completely clean new rh9 "everything" install and
I've only used up2date to keep it patched - and am normally very prompt about that.
I still have the 2.4.20-9 kernel installed as well as 2.4.20-13.9. I did however
manually rpm -e the old 2.4.20-8 kernel and kernel-source a good while ago to
save some drive space. That's the only non-standard thing I think I've done to it.
I only see the dodgy kernel update entry when there are other updates pending-
i.e. just now when it reported 3 cups rpms plus the kernel. Once up2date ran and
updated the 3 cups rpms, the red ! has gone away again.
Also I suggest that bug 88272 is probably a duplicate of this- with no extra
clues there unfortunately.
I see the same problem with rhn-applet-2.0.9-0.9.0.1 in RH9.
The only version of the kernel installed is kernel-2.4.20-18.9
which it suggests I upgrade to the same version. The problem
started when php updates was made available earlier today.
The problem was apparently gone after updating php.
The problem still exists with RH9 and all updates. It happened to me after a
full partition had caused check for updates to fail. The aplet was showing the
grey question marker. I left clicked to start up2date. Up2date failed with a
strange error message including information about no disk space available. After
some files had been deleted and up2date was closed, I could check for updates
again. This time the applet found that one update was available. I left clicked
again, and up2date showed the kernel needed to be updated to the same version. I
then closed up2date and let the applet check for updates again. This time
everything behaved normally.
The same problem happened on my machine with a system of Japanese language, too.
Up2date version is 3.1.23-2-1.i386.
Created attachment 94558 [details]
The picture of Rhn-applet
Renewal of the already updated kernel is not always urged. When renewal of
Openssh was notified, the kernel was described for nothing.
Created attachment 94576 [details]
The picture of Rhn-applet
This has been happening to me, too. Just now kernel-2.4.20-20.9 showed out of
date in the applet even though that's what I'm running. So I right clicked the
applet and picked "Check for updates" and it did the check then the icon switched
to the blue check meaning everything's up to date. .rhn-applet.cache and
/var/lib/rpm/Packages didn't change size or time after I did the manual check vs.
Wild guess: could it be a communication problem, where sometimes something wacky
happens when the applet talks to the rhn server and the unexpected error makes
the applet flag kernel as out-of-date. Is kernel first or last in the list
when the applet checks with the server?
*** Bug 88272 has been marked as a duplicate of this bug. ***
Red Hat apologizes that these issues have not been resolved yet. We do want to
make sure that no important bugs slip through the cracks.
Red Hat Linux 7.3 and Red Hat Linux 9 are no longer supported by Red Hat, Inc.
They are maintained by the Fedora Legacy project (http://www.fedoralegacy.org/)
for security updates only. If this is a security issue, please reassign to the
'Fedora Legacy' product in bugzilla. Please note that Legacy security update
support for these products will stop on December 31st, 2006.
If this is not a security issue, please check if this issue is still present
in a current Fedora Core release. If so, please change the product and version
to match, and check the box indicating that the requested information has been
If you are currently still running Red Hat Linux 7.3 or 9, please note that
Fedora Legacy security update support for these products will stop on December
31st, 2006. You are strongly advised to upgrade to a current Fedora Core release
or Red Hat Enterprise Linux or comparable. Some information on which option may
be right for you is available at http://www.redhat.com/rhel/migrate/redhatlinux/.
Any bug still open against Red Hat Linux 7.3 or 9 at the end of 2006 will be
closed 'CANTFIX'. Again, if this bug still exists in a current release, or is a
security issue, please change the product as necessary. We thank you for your
help, and apologize again that we haven't handled these issues to this point.