Bug 170272
Summary: | cannot update already installed packages with up2date | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 4 | Reporter: | Andreas Bock <info.redhat> | ||||||||
Component: | up2date | Assignee: | Bryan Kearney <bkearney> | ||||||||
Status: | CLOSED WORKSFORME | QA Contact: | Beth Nackashi <bnackash> | ||||||||
Severity: | medium | Docs Contact: | |||||||||
Priority: | medium | ||||||||||
Version: | 4.0 | CC: | cperry, marco, peter.wainwright | ||||||||
Target Milestone: | --- | ||||||||||
Target Release: | --- | ||||||||||
Hardware: | x86_64 | ||||||||||
OS: | Linux | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2006-11-20 22:24:23 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: | 191074, 191079 | ||||||||||
Attachments: |
|
Description
Andreas Bock
2005-10-10 13:14:30 UTC
Created attachment 119773 [details]
Output of "up2date -u"
Which packages is it trying to update, even though they are already uptodate? Please provide the output from this command, if you could. Created attachment 119793 [details]
solving the problem
Please look at my 1st attachment! But I solved the problem! Every package marked as already installed was installed twice! Removing the older instance solved the problem. Please, can anyone tell me, why does up2date install packages twice? Houston, we have a new problem :-/ After installation of packages started we se the following: Installing... 1:udev ########################################### [100%] 2:mkinitrd ########################################### [100%] 3:initscripts ########################################### [100%] 4:openssh ########################################### [100%] 5:glibc-kernheaders ########################################### [100%] 6:glibc-headers ########################################### [100%] 7:glibc-devel ########################################### [100%] 8:gcc ########################################### [100%] 9:vixie-cron ########################################### [100%] 10:gcc-c++ ########################################### [100%] 11:gcc-g77 ########################################### [100%] 12:openssh-server ########################################### [100%] 13:system-config-printer ########################################### [100%] 14:xinetd ########################################### [100%] 15:sudo ########################################### [100%] 16:slocate ########################################### [100%] 17:pdksh ########################################### [100%] and nothing else! Running top in a second windows shows: top - 09:33:04 up 21:52, 2 users, load average: 4.02, 3.52, 2.27 Tasks: 90 total, 4 running, 86 sleeping, 0 stopped, 0 zombie Cpu(s): 0.0% us, 25.0% sy, 0.0% ni, 74.9% id, 0.1% wa, 0.0% hi, 0.0% si Mem: 15966556k total, 1479704k used, 14486852k free, 116676k buffers Swap: 4080456k total, 0k used, 4080456k free, 1163628k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 13837 root 18 0 54416 1224 588 R 99.9 0.0 17:07.40 useradd 14763 root 16 0 5284 908 688 R 0.3 0.0 0:00.24 top Someone in another bug stopped ypbind to solve the problem. Trying so was to late, I am also unable to "kill" or "kill -9" the useradd process. Maybe this is the reason why anything went wrong. Let me tell you, it's a 4 CPU Sun V40z. Please excuse my german accent :-/ on a 2nd identical maschine I stoped ypbind befor using "up2date -u": ... 16:sudo ########################################### [100%] 17:slocate ########################################### [100%] 18:pdksh ########################################### [100%] 19:nscd ########################################### [100%] 20:nfs-utils ########################################### [100%] ... and the process ended successfull. Maybe the postinstall script of pdksh or nscd tries to add a new user. Some times ago I was able to automaticaly update my systems every night. I think it would'nt be a good idea to stop this and update them manualy. Or maybe i should stop ypbind every time befor running up2date. Apologies for not noticing the attachment. As far as updating twice, it's hard to be sure from the output given, but that may relate to multilib packages, since this is an x86_64 machine. x86_64 is one of the archs which has i386 packages in addition to those which go with the architecture, so that may have been what was going on. Not positive, however. For the later problem you ran into, this appears to be the same problem as that reported in bug 170087, which is being investigated. I have also found that up2date often attempts to install already installed packages and fails. And, in at least one case, I have managed to track down why. Consider this output (attached). Trying to update cpp alone fails because cpp requires a matching gcc version. The dependency solver then considers the dependency gcc->cpp. cpp is already marked for installation, so (__dependencies) it tries to add gcc. It also marks for installation anything that obsoletes gcc - namely compat-libgcc-296. There are two problems with this. FIRST (non-fatal) that compat-libgcc-296 only obsoletes gcc 2.96, it should not be considered here (gcc 3.4.3). SECOND (and this is the killer), compat-libgcc-296 is up-to-date, so when it is added to the transaction set, it causes the "already installed" error. Frankly the more I look at the internals of up2date the hairier it seems. Peter Wainwright Created attachment 123710 [details]
Output of up2date -vv cpp
Blocking rhnupr4u4 and rhnupr3u8 to track the progress of the release Moving bugs to the CanFix List This bug did not make the code freeze and it will not be fiixed during this release cycle. Re-aligning bug to the next release This bug did not make the code freeze. It will not be fixed in this releasee Reea ligning to the next one. I'm unable to reproduce this on RHEL 4 x86_86 with up2date-4.4.69-23 |