Bug 85911

Summary: up2date -k option does not work
Product: Red Hat Enterprise Linux 2.1 Reporter: Nick Strugnell <nstrug>
Component: up2dateAssignee: Clifford Perry <cperry>
Status: CLOSED WONTFIX QA Contact: Max Spevack <mspevack>
Severity: medium Docs Contact:
Priority: medium    
Version: 2.1CC: k.georgiou, pcfe
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: 2012-06-20 13:18:13 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: 120092    

Description Nick Strugnell 2003-03-10 18:42:19 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:
The -k option should force up2date to check for RPMs in a local dir before
starting to download them from RHN. This works on 7.2, 7.3 and 8.0 but not on AS2.1

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


How reproducible:
Always

Steps to Reproduce:
1.register an AS2.1 host to RHN
2.download AS2.1 updates to /tmp
3.up2date -k /tmp -u
    

Actual Results:  up2date downloaded RPMs rather than copying them from /tmp

Expected Results:  up2date should have copied RPMs from /tmp to
/var/spool/up2date and installed them immediately

Additional info:

Comment 1 Patrick C. F. Ernzer 2003-05-22 11:22:59 UTC
I can confirm this erroneous behaviour. Seen on SystemIDs 1002961687 and 1002962093.

had an aborted download on the first machine I updated, did the following:

copied /var/spool/up2date/*rpm to /tmp/banana (on both machines, so that I had
one with the same errata in /var/spool/up2date and one with the errata only in
/tmp/banana.

saw the following:

up2date -u would download the errata again, even though one machine had them
available in the spool director

all of the following would also download the errata again (as in the first
package would come in at one 50k/sec and I would the abort to thest the next
command.) tested all of the to exclude problemon CLI option parsing:

up2date -f -k /tmp/banana/ -u
up2date -fu -k /tmp/banana
up2date -fu -k /tmp/banana/
up2date -f -k /tmp/banana/ -u
up2date -f -k/tmp/banana/ -u
up2date -f -k/tmp/banana -u
up2date -k/tmp/banana -u
up2date -k/tmp/banana/ -u

FWIW, both machines use an http proxy to access the internet.

Can we please fix this ASAP as it is very annoying when doing an installation of
a cluster at a site that has limited bandwidth? (upped prio, left severity at
normal, feel free to adjust if necessary)

PCFE
BTW: I'm still at this site tomorrow but will not read e-mail, if you want me to
run tests, extract the mobile number of the user ID 'pernzer' from LDAP and call
me. I'm at the customer site between 10:00 and 17:00 CEST today and tomorrow.

Comment 2 Patrick C. F. Ernzer 2003-05-22 11:26:27 UTC
BTW, this is with up2date-2.7.61-7.x.2


Comment 3 Patrick C. F. Ernzer 2003-05-22 12:53:02 UTC
OK, now I'm confused, after errata were applied, I had symlinks in
/var/spool/up2date to /tmp/banana as I would expect.

But why then was transfer rate so low?!?

dropping prio again.

Comment 4 Didier 2004-07-22 14:06:49 UTC
Bug confirmed with RHEL3 AS, up2date-4.2.16-1.

Comment 5 Adrian Likins 2005-01-14 21:04:10 UTC
fixed in 4.4.8

(symlink was getting set correctly, but package wasnt
loaded. Bad assumption retained though multirepo support
that broke it)

Comment 6 Andrew Overholt 2005-03-22 18:37:39 UTC
Any chance of this getting fixed in up2date-4.2.57-2?

Comment 9 Jiri Pallich 2012-06-20 13:18:13 UTC
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. 
Please See https://access.redhat.com/support/policy/updates/errata/

If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.