Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 108191
Summary: | up2date --nosig tracebacks | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Chris Ricker <chris.ricker> | ||||||
Component: | up2date | Assignee: | Adrian Likins <alikins> | ||||||
Status: | CLOSED WONTFIX | QA Contact: | Fanny Augustin <fmoquete> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | rawhide | CC: | barryn, mattdm, m.a.young, mkanat, nobody+pnasrat | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2007-04-10 16:46:43 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: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 100643 | ||||||||
Attachments: |
|
Description
Chris Ricker
2003-10-28 14:32:41 UTC
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. whats rpm -q gpg-pubkey is the gui up2date problem also with --nosig? 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. Hey cool, it's a heisenbug When I ran the same command again (nothing changed), it worked. 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 >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.
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 Created attachment 95577 [details]
strace of failing up2date
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.... Created attachment 95578 [details]
fubar'ed rpm
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? 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.... 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]$ 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. 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 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. 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. I would expect just a "Server-side error" message, personally, as an end user. -M 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... ??? 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 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. 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. 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 :( "issue still persists" kicking back to alikins up2date is no more. |