On Fri, 2006-10-27 at 11:13 -0700, John Reiser wrote: As usual, I ride the edge and am yum updating all my machines. First I tried my laptop which is a 700mhz PIII. I installed the new fedora-release package, did a "yum update glibc\*" then "yum update yum \* rpm\*", so that its running the FC6 yum/rpm, before going for a full "yum update". It pegs the CPU for a long long time after "Reading repository metadata in from local files". Its not noticeably accessing the disk, or using a large amount of RAM. The system time is at 30%, yum takes the rest. The fan in my laptop is horribly worn out, something pegging the CPU for more than a minute or so causes it to overheat and turn off. I have been unable to complete a "yum update". I one sat and kept smacking the fan so it would keep spinning, yum went for a good 20 minutes before I got bored and distracted and let it overheat. (Sudden power failures during an RPM transaction is GREAT for your package database...) Updating a subset of packages at a time is much faster, "yum update xorg\*", "yum update lib\*", but it still takes 10sec-1min in the CPU crunching state depending on how many packages are involved. I'm trying it right now on my Athlon 64 3000+ desktop. I installed the release file, did a "yum update glibc\*", then went for a "yum update", so this time its with the FC5 yum. It didn't spend more than a few seconds after reading the metadata before it went to "Resolving Dependencies", spewing out lines of "Package xxxxxx set to be updated". (and eventually failing due to some weird dependency problem) So now I just did a "yum update rpm\* yum\*", "yum clean all", then tried "yum update". Its doing the same thing, pegging the CPU, 20% system time, yum eating the rest. It took almost exactly 5 minutes to get from "Reading repository metadata in from local files" to "Resolving Dependencies". I'd say yes, there's something going horribly wrong in the FC6 yum.

On Friday 27 October 2006 13:17, dragoran wrote: How many packages did you have on each box? An upgrade is always going to be slower than an install. Twice the actions. -- Jesse Keating Release Engineer: Fedora

On Saturday 28 October 2006 02:35, dragoran wrote: I didn't say it would be twice as slow, I said there are 2x the actions, plus a lot more processing in the actual LOOKING for updates. -- Jesse Keating Release Engineer: Fedora

On Tue, 2007-02-20 at 13:50 +0100, Roberto Ragusa wrote: Not quite I think. Other (later-run) scripts might use those libraries so ldconfig has to be be run before them so they can work. Perhaps those calls could be clustered into one, but I don't know whether this can be done without changes to RPM. Nils -- Nils Philippsen / Red Hat / nphilipp(a)redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011

Chuck Anderson wrote: should be possible (using inotify and only add the new created files to the cache) but for this we need a ld daemon (dunno if its possible to update only a part of the cache) /sbin/ldconfig can check if the daemon is running and if yes just do nothing, else work as it used to be (like it did before). (still works when daemon is not running). this would also speed up yum updates too. about yum: afaik currently yum works like this get metadata for repo A get metadata for repo B ... parse metadata for repo A parse metadata fro repo B ... why waiting so long until parsing metadata of repo B ? why not do it after download while downloading b? so yum can just create a thread for each repo to do the download + parse for each repo in a thread and do this for many repos in parrallel. this should speed up yum init (dunno by how much and dunno if it benifits from smp systems or not but it should) but why only doing this for repo parsing? why not for getting package headers (there are not that big so bandwith should not be the bottleneck, but waiting for nothing is it) I don't have any code (and so no benchmarks) but I think this ideas could speed up the install/update of packages alot (not only a few %).

Nils Philippsen wrote: Good point. Anyway, the installation completed and I don't see evident problems. The complete process was quite interesting: 1) launched update from FC4 to FC6; after a few hours anaconda apparently locked: from what I saw, the system was out of memory (512MiB, the swap partition already present on the disk was not autoactivated) 2) started the update process again (from FC6 to FC6, according to anaconda), activated the swap partition manually 3) at about 25% of (slow) progress, renamed the ldconfig exe away 4) at the end of the upgrade, renamed ldconfig back and, maybe, chrooted and ran ldconfig (I don't remember if I did that or not) 5) rebooted the system At that point the system appeared perfectly working, but any attempt to start X or reconfigure X (including using system-config-display) failed, even if the xorg.conf file was apparently ok. I investigated around and discovered "rpm -qa" was giving many duplicate entries; I was going to blame the first aborted update, but soon realized it was all good, just ppc+ppc64 versions. Assuming the problems with X could have been related to failed upgrading scripts (according to your hint), I just launched a full "yum update", hoping that the missing scripts would be run successfully somewhere in those 1.1GB of updates. The X problem persisted, but the issue was really trivial: no xorg-x11-drv* package had been installed! After the installation of xorg-x11-drivers everything appears ok on the system, the KDE desktop runs perfectly. So, at the end of all this, I can say that the ldconfig trick, while certainly dirty, didn't result as dangerous as you thought. Maybe the first aborted installation (with normal ldconfig) did help, by correctly upgrading the fundamental parts of the system (glibc,...) and so avoiding script failures later (when ldconfig was off). I still hope some way to speedup the FC update process will come out, as it is becoming more and more annoying with new versions. (and the FC6->FC7 upgrade will include extras...) Best regards. -- Roberto Ragusa mail at robertoragusa.it