Bug 84757

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 ?

Daniel

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
knows?

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
point?

Hum, no. Since you apparently closed and restarted the session,
the timestamp on the ~/.rhn-applet.cache is likely to have changed...

Daniel

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
/home/kaboom/.rhn-applet.cache
-rw-r--r--    1 rpm      rpm      34775040 Apr 20 22:43 /var/lib/rpm/Packages
[kaboom@verdande kaboom]$

(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...

Daniel

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.

Latest developments:

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
already installed....

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.
before.
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
provided.

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.