Nils Philippsen wrote:
On Tue, 2007-02-20 at 13:50 +0100, Roberto Ragusa wrote:
So I renamed /mnt/sysconfig/sbin/ldconfig away and replaced with a copy of /bin/true. The installation speed went up a lot, I'd say it's 10 times faster now.
I suppose that running ldconfig continously is not useful, it could be done just once at the end of the upgrade.
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.
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.