Even though up2date tells me there are updates available, rhn-applet
never does, and the following is always in the Critical Information tab:
The applet has been unable to access the following information sources
in its last attempts: fedora-core-1 @
http://fedora.redhat.com/releases/fedora-core-1, updates-released @
This happens on two FC1 systems. The problem is specific to these two
channels; the other yum channels I added *do* work.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Right-click on RHN applet.
2. Select Check for updates
Actual Results: No updates available, error in Critical Information tab
Expected Results: 6 updates available
This may have something to do with the URLs being redirects to
locations on download.fedora.redhat.com. Changing the URLs in
/etc/sysconfig/rhn/sources to the targets of the redirections makes
The same problem (wrong URLs) is in yum via yum.conf. I suggest you
put a symlink in the web site as it is the quickest and most
transparent way to fix a bug who is crucial for Fedora's reputation
(before the reviewers have evaluated Fedora).
There was a similar problem with redhat-config-packages who was still
looking /mnt/cdrom/RedHat/RPMS when the right place is
/mnt/cdrom/Fedora/RPMS: a production realease is NOT the place to go
changing paths who could acffect important tools: there has been 3
(three test releases), those changes whould have gone in one of them
Now the redirecting URLs have been completely removed, causing up2date
to fail as well.
If up2date is going to be changed to use the
download.fedora.redhat.com URLs, that creates an awful chicken-and-egg
problem: most users won't know that the update exists, and won't be
able to receive the update if they do! It's clearly impossible to get
everyone to download an update manually, so the only real solution is
to fix the original URLs without redirects.
Confirming... same problem here. Ethereal says:
--- begin ---
GET /updates/released/fedora-core-1/headers/header.info HTTP/1.1
HTTP/1.1 302 Found
Date: Fri, 19 Dec 2003 09:27:20 GMT
Content-Type: text/html; charset=iso-8859-1
Via: HTTP/1.1 bruink (Traffic-Server/5.2.1-58896 [cMsSf ])
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
The document has moved <A
--- end ---
I agree with Anders Kaseorg on the only real solution.
This has been fixed in teh latest versions of the applet.
Upgrade ! Up2date support redirections, the upgrade should work.
Daniel, this doesn't solve the chicken-and-egg problem described above
by Anders Kaseorg. Can you comment on Anders Kaseorg's message please?
Well I think I did !
up2date handles redirection. so running up2date will upgrade
the rhn applet.
W.r.t. changing the web site, I don't know who can do this.
Here's the problem:
1. Joe User downloads and installs Fedora Core 1 on his shiny new desktop.
2. Joe logs in, and the old rhn-applet starts.
3. rhn-applet accesses the fedora.redhat.com updates URL.
4. rhn-applet gets redirected to download.fedora.redhat.com.
5. Because of this bug, rhn-applet gets confused, gives up, and
displays a blue checkmark with a "no updates available" tooltip.
6. Joe thinks he doesn't need to run up2date because he thinks there
are no updates available!
7. So rhn-applet never gets updated, and neither does anything else.
8. Joe runs into a critical bug in some other package, gets really mad
that Red Hat "doesn't" release an update, writes nasty reviews of
Fedora Core flaming Red Hat, and goes out to buy Windows XP.
You see, the update is worthless if users don't know it exists.
Therefore, it is critical for Fedora's reputation that the website be
changed to accomodate the old, buggy rhn-applet, for as long as Fedora
Core 1 is in use.
I understand your problem. I cannot fix it. It's not a rhn-applet
problem. It's not the initial bug reported against rhn-applet.
It's useless to reopen a rhn-applet bug for something which is a
web site update request.
Daniel, Anders Kaseorg meant to report a problem, not just the bug
causing the problem. If you want to keep the scope of this bug report
to the bugfix itself, then I think you should split Anders Kaseorg's
problem report into two (or more) bug reports before closing this bug
There is no component for the web site. It's not even a pure web
site problem. The data are on a different machine !
I'm checking if that can be fixed in some way, but it's not
related to rhn_applet, so closing the bug is fine !