Bug 85763

Summary: no valid GPG signature
Product: Red Hat Enterprise Linux 4 Reporter: Leif Svensson <llam01>
Component: up2dateAssignee: Adrian Likins <alikins>
Status: CLOSED CURRENTRELEASE QA Contact: Red Hat Satellite QA List <satqe-list>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0CC: jay, laurence, rhn-bugs
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-09-02 19:09:01 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Leif Svensson 2003-03-07 09:58:57 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows 98; H010818)

Description of problem:
I'am running the swedish version RHL 8.0 and i get this message when trying to 
update with up2date "kdebase 3.0.3-14 does not have a valid GPG signature. It 
has been tampered with or corrupted." 
I choose to stop updating and try again but with the same result.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.Start up2date
2.select kdbase (and other files as well)
3.start 
    

Actual Results:  i get this message when trying to update with up2date "kdebase 
3.0.3-14 does not have a valid GPG signature. It has been tampered with or 
corrupted." 


Expected Results:  kdebase is installed

Additional info:

Only tried twice, it takes some time before this message appear and the 
download stops.

Comment 1 Jay Smith 2003-03-12 22:22:29 UTC
I am running English RH 8.  I used up2date in January and early February and
successfully did two rounds of kernel updates.  Then starting in late February
or early March, I tried to download the 2.4.18-26.8.0.i686 set of kernel rpms
using up2date. 

Using up2date, I was successfull in getting smaller rpm's, but not the kernel
files.  After about 10 tries, I finally got "core". However, NONE of the others
-- after at least another 15 or so tries.  The process gets to between 40 and
70% and then appears to die and I get a "GPG" error such as the first reporter
mentioned.  

I am using up2date version 3.0.7

I have also tried downloading the rpm files directly via the link on the rhn
page, but again, the process dies (I am using Mozilla 1.2 [Mozilla/5.0 (X11; U;
Linux i686; en-US; rv:1.2) Gecko/20021202] download manager and it can't
continue or restart the download.

After a WEEK of failures, thinking that the problem was "entitlement related", I
paid my $60 for basic subscription.  NO CHANGE.  It still won't download the big
kernel files.  I then discovered that the $60 buys NO SUPPORT. (So what is the
$60 for? Has RedHat started hiring people from Microsoft?)

I have not noticed any other problems with our network or connection to the
Internet. Our ping times to our friendly local ISP are as fast as they ever get
(we are on a 56 kb modem).  Our ISP says that the are not aware of having made
any changes to their network in the last month.

When the process dies, our connection to the net is still up, our ping times are
still great, etc.  

PLEASE HELP!

Jay  phone 1-800-447-8267  9-9 EST USA.


Comment 2 Bret McMillan 2003-03-12 23:01:44 UTC
What is the output of:

rpm -q gpg-pubkey

on your system?  I was able to run "up2date kdebase' with no trouble whatsoever...

Comment 3 Jay Smith 2003-03-13 00:38:37 UTC
Bret,

The output of "rpm -q gpg-pubkey" is

   gpg-pubkey-db42a60e-37ea5438

I assumed that the GPG error message was because the download process died
before the download completed, thus of course the file is "corrupted".

Is there some chance that changes were made to the RHN servers some time in
February that would cause problems for people downloading the large files over
slow (56 kb modem in my case) connections?

Thanks.

Jay

Comment 4 Bret McMillan 2003-03-13 13:51:35 UTC
Jay,

It looks like you *do* have the valid Red Hat GPG key imported into rpm, which
is good.

I suppose it's possible your download process died... when did this happen?

Have you tried again recently?

Comment 5 Jay Smith 2003-03-13 14:25:39 UTC
Bret,

The problem has been continuous since around February 26th or so. I have tried
dozens of times using up2date.  The most recent attempts were on 12 March.

Then on 11 March (I think) I purchased the "Basic service" in an attempt to
solve the problem, but there was no change.  The most recent attempts were on 12
March.

We also set the up2date "retries" level from 5 up to 15, but that did not help
either.

Then on 12 March I started trying via direct download from the rhn download
page, using Mozilla 1.2 -- in my various tries Mozilla's download manager said
that I got to about 70% +/- (which was better than using up2date which only got
to between 40% and 60%).  However, the download manager simply says "failed" and
does not give the ability to restart/continue the download (I don't know if your
servers don't allow restarting/continuing or if the download manager does not
support it).  Using the download manager, I *guess* it is downloading it as any
other file, thus it does not try to check the GPG stuff. This further supports
that the problem is the download process dieing, not a GPG problem.

Please remember that in January and early February I *was* able to use up2date
(on the "Demo service") to get two rounds of kernel downloads -- and I had no
problem at all as long as I was able to get in the in first place.  This
suggests to me that either something about my system has changed, the ISP, the
internet connection, or your servers have changed.  My ISP has said they have
made no changes.  I am not aware of any significant changes on our system other
than the up2date updates.  My ping times to my ISP are as fast as they get, with
zero or extremely few lost packets.

I *am* able to use up2date to get small files.  It is the big kernel files which
are failing.

Jay

Comment 6 Bret McMillan 2003-03-13 14:48:58 UTC
The fact that mozilla is having problems downloading large files as well is very
suspicious.  Are you having trouble downloading large files from other servers?
 Try snagging a kernel-sized file from one of the mirrors... 

Comment 7 Jay Smith 2003-03-13 17:29:44 UTC
Bret,

Sorry to be stupid, but can you tell me where I can find a list of the RH
mirrors? I will be happy to test, but I need to know where to go.

BTW, I am located only about 40-50 miles from RH headquarters, thus if rhn is
being served from the Triangle, I am about as few hops away as one could hope for.

Jay

Comment 8 Bret McMillan 2003-03-13 18:12:55 UTC
https://www.redhat.com/download/mirror.html

Comment 9 Jay Smith 2003-03-14 00:32:04 UTC
Bret,

Thanks for the URL. I picked a U.S. mirror site at random and first try I was
able to download kernel-debug.  I used a Windows download manager (getright) to
do it.

I then tried up2date again and tried to get kernel-smp, but it failed at about
50%. Same story.

I then tried the download manager to get to RHN page, but could not get it in
that way. Perhaps you can only get to the RHN download pages using a BROWSER
because you have to log in, etc., etc.  If there is a way to use FTP or a
download manager to get into the RHN download site, let me know -- maybe there
is an FAQ on it?  I have not found one.

At this point... I am able to manually get kernel rpms from mirror sites, but
not from RHN.  That means manual installs, etc., etc.  What a pain!

May I suggest that a RetHat staffer try to use up2date over a 56 kb modem and
see if they can get kernel files. 

Jay


Comment 10 Jay Smith 2003-03-14 14:41:55 UTC
Bret,

a) I have been successful in using an FTP mirror site to get the kernel files.
There was not a single problem that I could determine.  This leads me to think
that the problem has something to do with up2date or RHN.

b) When trying to use up2date (and it was failing), I noticed that the process
used virtually every available bit of bandwidth on our 56 kb modem.  During the
MANY HOURS of repeated attempts, we were unable to use our browsers to do
anything on the net; it took forever for email to go out; incoming email was
dramatically reduced, etc.  I do not recall this being so severe back in January
and early February when I used up2date to get the last two rounds of kernel
downloads.  It would be very helpful if the up2date process had some throttling
built in (maybe configurable) that would allow only x% of the available
bandwidth to be used.

c) Following on "b", maybe the failure of the up2date download process involved
other demands on the bandwidth (for example, incoming email which is something
that we cannot control).  This did not hurt the downloads from the mirror site
(and in fact I was able to do a little browsing during the downloads from the
mirror).

Jay

Comment 11 Jay Smith 2003-03-18 19:10:21 UTC
The problem continues.  Today I used up2date to get the gnome and sendmail updates.

One file (samba-client-2.2.7-4.8.0.i386.rpm), probably the largest, took three
tries to get it.  The same error as previously reported was shown when the
process failed.  The third try worked.

The difference between the first two tries and the third is that nobody was
SENDING email during that time (lunch time).  However, emails were coming in.

I repeat that I suspect the up2date process is too sensitive to slowdowns, such
as would occur when email is coming/going or there is browsing activity, on a
SMALL PIPE (56 kb modem).

Jay

Comment 12 Laurence Orchard 2003-05-10 00:43:59 UTC
I have tried using up2date to download the latest kernel and patched apps, but
have difficulty with a number of them with 'GPG signature invalid or corrupted'.
Some of the apps will update, but some will not. In particular ethereal and
gnome-etherreal failed again today, together with the kernel and glibc debug
updates. As per the previous comments I am presuming that there is some sort of
bandwidth problems, I am using a 56k modem. The error messages appear part way
through the download, whereas I assume that if it was a 'real' signature problem
the error would not show until the download was complete.