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.
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
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
I still hope some way to speedup the FC update process will
come out, as it is becoming more and more annoying with new
(and the FC6->FC7 upgrade will include extras...)
Roberto Ragusa mail at robertoragusa.it