Bug 111032 - up2date hangs when re-fetching from apt repo
Summary: up2date hangs when re-fetching from apt repo
Alias: None
Product: Fedora
Classification: Fedora
Component: up2date   
(Show other bugs)
Version: rawhide
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Bret McMillan
QA Contact: Fanny Augustin
Depends On:
Blocks: 124619
TreeView+ depends on / blocked
Reported: 2003-11-26 15:37 UTC by Matthew Saltzman
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-10-29 13:40:12 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Matthew Saltzman 2003-11-26 15:37:49 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016

Description of problem:
After using up2date to install an RPM fetched from an apt repo and
removing the RPM, attempts to re-install the RPM from the same repo
hang (CPU near 100%) after message "Fetching RPM headers..."  Ctrl-C
doesn't kill the process.  Ctrl-z followed by kill doesn't kill the
process, kill -9 is necessary.

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

How reproducible:

Steps to Reproduce:
1. Add "apt macromedia http://ruslug.rutgers.edu/macromedia/apt
fedora/1 macromedia" to /etc/sysconfig/rhn/sources.
2. up2date --nosig flash-plugin
3. rpm -e flash-plugin
4. up2date --nosig flash-plugin

Actual Results:  Infininte loop.

Expected Results:  flash-plugin RPM should be downloaded and installed.

Additional info:

After first (successful) install:

[root@yankee mjs]# ls /var/spool/up2date/*macro*

If I delete those files, the next install attempt works.

The flash-plugin RPM seems to require the --nosig option to up2date
(another bug?)  If I don't include this option, the install aborts. 
After that failure:

[root@yankee mjs]# ls /var/spool/up2date/*macro*

Note the link-* file, not present after successful install.  After the
aborted install without --nosig, the next atempt to install succeeds.

Comment 1 Adrian Likins 2003-11-26 18:49:35 UTC
hmm, looks like its deleting the headers after installing the
package when it shouldnt be. 

I'll special case it for apt

the --nosig is required because the packages are not GPG signed (or
signed by a key not on rpms keyring). 

Comment 2 Matthew Saltzman 2003-11-26 19:31:04 UTC
Yes, I figured out the --nosig issue.  I didn't have the fedora.us key

It does work with yum, though.

Comment 3 Alexandre Oliva 2004-07-17 20:41:02 UTC
The procedure above still fails on FC3test1 (up2date-4.3.19-1.1), but
in a slightly different way: instead of hanging indefinitely, up2date
eventually fails saying it couldn't contact the server, but it didn't
even *try* to contact the server.  The problem appears to be that the
hdr file for flash-plugin was removed after the initial install, and
the apt back-end doesn't re-extract the hdr from the apt headers file.
 strace shows it just stats the various package directories for the
flash-plugin*.hdr file and then prints the error.

Matthew, I see you filed bug #111041 as well, which looks to me like a
different symptom for the same bug.  Should we dup it, mark it as
depend, or just leave it alone?

Comment 4 Matthew Saltzman 2004-07-17 21:03:10 UTC
IIRC, I really did think these were two separate bugs.  The other one
had to do with resolving dependencies, possibly in a repository that
appeared earlier in the list, and this one had to do with improper
handling of the files in /var/spool/up2date.  You'd probably know
better than I, though.  If you think it's the same bug, then linking
them is fine with me, whichever you think is best.  (As the user, my
main objective is to see them both resolved 8^).

(It's not really relevant, but the FC2 flash-plugin RPM has a broken
GPG sig, so I ended up installing it via synaptic.)

Comment 5 Alexandre Oliva 2005-01-28 14:56:19 UTC
This is still relevant in rawhide, and it's actually more serious that
I'd first thought.  Here goes a complete description with a recipe to
duplicate the problem:

1. install a package using up2date from an apt repository.  At the
end, up2date removes both the .rpm and the .hdr from /var/spool/up2date

2. install with up2date any other package that requires dep
resolution.  At this point, up2date will fetch all headers from all
repositories, but *not* those from apt repositories.  As a result, it
won't have headers for the package already installed, and will
eventually fail dep resolution.  Or does it does for me.  

Wiping out the contents of /var/spool/up2date actually fixes the
problem, but one shouldn't have to do this every time dep resolution
is needed, right? ;-)

Comment 6 Alexandre Oliva 2005-01-28 18:17:16 UTC
Err...  Just for correctness, I haven't actually observed the problem
on rawhide, but rather on boxes that were running FC3.  I was confused
because I happened to install rawhide yesterday, when I also added apt
repo to sources of all my boxes, and today problems showed up on all
the FC3 ones.  I still haven't updated the rawhide boxes, and now I've
switched from apt to yum for the selected repo, so I'm sure I won't
observe the problem on rawhide, for now.  Oh well...

Comment 7 John Thacker 2006-10-29 13:40:12 UTC
Note that FC2 is no longer supported even by Fedora Legacy.  Also, up2date has
been replaced by pirut and pup since FC5.  FC3 and FC4 are supported by Fedora
Legacy for security issues only.  If this still occurs on FC3 or FC4 and is a
security issue, please reopen and assign to that version and Fedora Legacy.  If
it occurs on RHEL 3 or 4, please reassign or refile against that product.

The codebase for pirut and pup is quite different, so existing bugs do not
apply, but please continue testing them on the still supported versions of
Fedora Core and file bugs as necessary.

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