Bug 108191 - up2date --nosig tracebacks
up2date --nosig tracebacks
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: up2date (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Adrian Likins
Fanny Augustin
:
Depends On:
Blocks: CambridgeBlocker
  Show dependency treegraph
 
Reported: 2003-10-28 09:32 EST by Chris Ricker
Modified: 2007-11-30 17:10 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-04-10 12:46:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
strace of failing up2date (30.72 KB, text/plain)
2003-10-29 09:59 EST, Chris Ricker
no flags Details
fubar'ed rpm (5.76 KB, application/octet-stream)
2003-10-29 10:04 EST, Chris Ricker
no flags Details

  None (edit)
Description Chris Ricker 2003-10-28 09:32:41 EST
This is with up2date-4.1.11-3

[kaboom@skuld kaboom]$ sudo up2date --nox -u --nosig
<snip>
xemacs-21.4.14-3.i386.rpm:  ########################## Done.                   
xemacs-info-21.4.14-3.i386. ########################## Done.                   
xscreensaver-4.14-1.i386.rp ########################## Done.                   
Traceback (most recent call last):
  File "/usr/sbin/up2date", line 1187, in ?
    sys.exit(main() or 0)
  File "/usr/sbin/up2date", line 765, in main
    fullUpdate, dryRun=options.dry_run))
  File "/usr/sbin/up2date", line 1050, in batchRun
    batch.run()
  File "up2dateBatch.py", line 82, in run
  File "up2dateBatch.py", line 153, in __installPackages
  File "up2date.py", line 604, in installPackages
  File "up2date.py", line 173, in getRealHeader
rpm.error: public key not trusted
[kaboom@skuld kaboom]$
Comment 1 Michael Young 2003-10-28 09:42:14 EST
I am seeing something similar via the GUI (with 4.1.12-1)
Traceback (most recent call last):
  File "/usr/share/rhn/up2date_client/gui.py", line 2070, in doInstallation
    kernelsToInstall = up2date.installPackages(self.selectedPkgList,
self.rpmCallback)
  File "/usr/share/rhn/up2date_client/up2date.py", line 604, in installPackages
    hdr = getRealHeader(pkg)
  File "/usr/share/rhn/up2date_client/up2date.py", line 173, in getRealHeader
    hdr = _ts.hdrFromFdno(fd)
rpm.error: public key not trusted

But rerunning up2date sometimes works.
Comment 2 Adrian Likins 2003-10-28 12:24:01 EST
whats 

rpm -q gpg-pubkey

is the gui up2date  problem also with --nosig?
Comment 3 Michael Young 2003-10-28 12:34:14 EST
I have
rpm -q gpg-pubkey
gpg-pubkey-897da07a-3c979a7f
gpg-pubkey-e418e3aa-3f439953
gpg-pubkey-db42a60e-37ea5438
My system is now up2date, so I can't do any testing at the moment.
Comment 4 Chris Ricker 2003-10-28 12:41:43 EST
Hey cool, it's a heisenbug

When I ran the same command again (nothing changed), it worked.
Comment 5 Max Kanat-Alexander 2003-10-28 16:32:58 EST
It's sort of far-fetched, but I thought that I ought to point out that these
sort of "heisenbugs" (good word) tend to happen to me when prelink is in the
middle of working.

That's probably not the case for this bug, but just in case it is, I thought I'd
point it out. If I run into the bug myself, I'll try to debug.

-M
Comment 6 Adrian Likins 2003-10-28 20:43:17 EST
>When I ran the same command again (nothing changed), it worked.

hmm, well. It is crypto, so cosmic rays and flipped bits and
other hardware wackiness could be the cause. 

But seeing it in suddenly start happening would seem
to rule that out (I'm assusing this is new behaviour?)

If anyone sees it again, can they grab a copy of the
file it fails on and put it up somewhere?

rpm version too, since its librpm bubbling up that
it failed the key check.
Comment 7 Chris Ricker 2003-10-29 09:43:41 EST
I'm not sure what you mean by the file it's failing on. Here's todays attempt:

Testing package set / solving RPM inter-dependencies...
########################################
FreeWnn-libs-1.11-39.i386.r ########################## Done.                   
anaconda-help-9.2-1.noarch. ########################## Done.                   
bash-2.05b-31.i386.rpm:     ########################## Done.                   
evolution-1.4.5-7.i386.rpm: ########################## Done.                   
evolution-devel-1.4.5-7.i38 ########################## Done.                   
fedora-release-1-1.i386.rpm ########################## Done.                   
gzip-1.3.3-11.i386.rpm:     ########################## Done.                   
initscripts-7.42-1.i386.rpm ########################## Done.                   
kdebase-3.1.4-6.i386.rpm:   ########################## Done.                   
kdebase-devel-3.1.4-6.i386. ########################## Done.                   
kernel-2.4.22-1.2111.nptl.a ########################## Done.                   
kernel-doc-2.4.22-1.2111.np ########################## Done.                   
kernel-source-2.4.22-1.2111 ########################## Done.                   
libgnomeprint22-2.4.0-1.i38 ########################## Done.                   
libgnomeprint22-devel-2.4.0 ########################## Done.                   
libgnomeprintui22-2.4.0-1.i ########################## Done.                   
libgnomeprintui22-devel-2.4 ########################## Done.                   
libtool-1.5-8.i386.rpm:     ########################## Done.                   
libtool-libs-1.5-8.i386.rpm ########################## Done.                   
mc-4.6.0-6.i386.rpm:        ########################## Done.                   
metacity-2.6.3-1.i386.rpm:  ########################## Done.                   
nautilus-2.4.0-7.i386.rpm:  ########################## Done.                   
ntp-4.2.0-2.i386.rpm:       ########################## Done.                   
prelink-0.3.0-13.i386.rpm:  ########################## Done.                   
redhat-artwork-0.87-1.i386. ########################## Done.                   
redhat-config-network-1.3.1 ########################## Done.                   
redhat-config-network-tui-1 ########################## Done.                   
rpmdb-fedora-0.95-0.2003102 ########################## Done.                   
sendmail-8.12.10-1.1.1.i386 ########################## Done.                   
sendmail-cf-8.12.10-1.1.1.i ########################## Done.                   
Traceback (most recent call last):
  File "/usr/sbin/up2date", line 1187, in ?
    sys.exit(main() or 0)
  File "/usr/sbin/up2date", line 765, in main
    fullUpdate, dryRun=options.dry_run))
  File "/usr/sbin/up2date", line 1050, in batchRun
    batch.run()
  File "up2dateBatch.py", line 82, in run
  File "up2dateBatch.py", line 153, in __installPackages
  File "up2date.py", line 604, in installPackages
  File "up2date.py", line 173, in getRealHeader
rpm.error: public key not trusted
[kaboom@skuld kaboom]$ 

sendmail-cf is the final package. It looks like it's dying at the point when it
transitions from downloading to installing, not while it's installing any
specific package

This is with

up2date-4.1.12-1
rpm-4.2.1-0.30
Comment 8 Chris Ricker 2003-10-29 09:59:38 EST
Created attachment 95577 [details]
strace of failing up2date
Comment 9 Chris Ricker 2003-10-29 10:02:41 EST
I just attached an strace of the failure. It was 33 megs, so I've only attached
the part from halfway through the next-to-last download (of rpmdb-fedora) on
through the crash

At least from the strace, it looks like anaconda-help-9.2-1.noarch.rpm is the
problem, though I can't see why....
Comment 10 Chris Ricker 2003-10-29 10:04:44 EST
Created attachment 95578 [details]
fubar'ed rpm
Comment 11 Chris Ricker 2003-10-29 10:05:27 EST
Hmm, I just looked at the anaconda-help rpm (attached). If you look at it,
you'll see why it's failing ;-)

I wonder how that got pulled down by up2date?
Comment 12 Chris Ricker 2003-10-29 10:08:18 EST
If I delete /var/spool/up2date/anaconda-help* and try again, it pulls down the
HTML doc again, so it looks like its a server-side missing file problem....
Comment 13 Chris Ricker 2003-10-29 10:11:54 EST
Hmm, it's universal to noarch packages:

[kaboom@skuld /var/spool/up2date]$ file *.noarch.rpm
anaconda-help-9.2-1.noarch.rpm:                ASCII English text, with very
long lines
redhat-config-network-1.3.10-1.noarch.rpm:     ASCII English text, with very
long lines
redhat-config-network-tui-1.3.10-1.noarch.rpm: ASCII English text, with very
long lines
[kaboom@skuld /var/spool/up2date]$ 
Comment 14 Paul Nasrat 2003-10-29 11:44:19 EST
This is due to the way http://ftp.redhat.com redirects to 404 page it uses a 302
but never sets a 404 header so the page gets snarfed.  There is another bug
where I noted this in.
Comment 15 Paul Nasrat 2003-10-29 11:48:18 EST
Other bug closed so adding appropriate text here:

In addition this seems to be due to to http://ftp.redhat.com using a 302 to
direct to the error page and there not being a 404 in the HTTP header:

To reproduce lynx --mime_header
http://ftp.redhat.com/pub/redhat/linux/foo/foo-0.1-1.src.rpm | head

Other mirrors get an I/O Error as expected 
Comment 16 Adrian Likins 2003-10-29 16:49:43 EST
yup

server is redirecting with a 302 to a page that just happens to
say "404" while returning a 200 error code.

aka, as far as up2date is concerned, it redirected it to a perfectly
valid page, not a 404. 

server setup is busted. 

working on better handling this error case.
Comment 17 Adrian Likins 2003-10-29 17:15:43 EST
theoretically better error handling should be in 4.1.15

It wont traceback, but your basically deed in the water
same as with a 404. Except slightly later. Not exactly
sure what else to do, since the resource we want isnt
available.
Comment 18 Max Kanat-Alexander 2003-10-29 18:41:22 EST
I would expect just a "Server-side error" message, personally, as an end user.

-M
Comment 19 raxet 2003-11-05 09:11:20 EST
same here... todays rawhide push 

 up2date --nosig
Traceback (most recent call last):
  File "/usr/share/rhn/up2date_client/gui.py", line 2070, in
doInstallation
    kernelsToInstall = up2date.installPackages(self.selectedPkgList,
self.rpmCallback)
  File "/usr/share/rhn/up2date_client/up2date.py", line 613, in
installPackages
    hdr = getRealHeader(pkg)
  File "/usr/share/rhn/up2date_client/up2date.py", line 173, in
getRealHeader
    hdr = _ts.hdrFromFdno(fd)
rpm.error: public key not trusted

Second time around it works... ???
Comment 20 Paul Nasrat 2003-11-10 10:11:23 EST
Can anyone confirm if this is still happening. I can't replicate here
by manually munging the local header xml conversion to point a package
url at a non-existent place
I now get:

An HTTP error occurred

triage->close
Comment 21 Michael Young 2003-11-10 10:42:42 EST
I don't think your test is valid (see comment #16). Also I think I saw
it in the up2date version that was supposed to fix it, but it probably
not going to reoccur until we start getting updates.
Comment 22 Paul Nasrat 2003-11-10 10:48:26 EST
My test points the target rpm at a nonexistent file, so simulates the
update.  It downloads the 404 page but then handles it.

Edit /var/spool/up2date/fedora-core-1.<timestamp> edit a package url
that you don't have installed, and try to up2date it. If you want you
could set up a locally broken yum repo to test I guess, however I
thing my test should simulate the behaviour.
Comment 23 Paul Nasrat 2003-11-10 11:16:20 EST
Michael is correct my test was originally against
download.fedora.redhat.com != ftp.redhat.com, I tried same test
against a rawhide setup against ftp.redhat.com with 4.1.16-1 and issue
still persists (untrusted gpg signature message).

Editing the local file is a good way to test though - apologies for
triager->crack :(

Comment 24 Todd Warner 2004-08-26 21:59:43 EDT
"issue still persists" kicking back to alikins
Comment 25 Matthew Miller 2007-04-10 12:46:43 EDT
up2date is no more.

Note You need to log in before you can comment on or make changes to this bug.