Red Hat Bugzilla – Bug 213148
Last modified: 2007-11-30 17:11:47 EST
Description of problem:
With the default installation, anaconda will hang, at least for hours, at 0% cpu
usage. With a customized installation, anaconda will hang for hours at 96-100%
cpu usage. Nothing is installed.
Anaconda is pretty much worse than useless, and has been like this for years.
It is still like this in FC6.
This was an NFS install on an 800MHz PIII Dell Precision.
And that's presuming you remembered to "Click Next to begin Installation of
Fedora Core" after walking away from the tedious transaction test. What did you
expect someone to do, click "Start Over, I like to waste time"???!
I'd like to say what Anaconda was doing, but it provides no feedback, other than
"Preparing to install packages". Who knows in what sense it was "preparing",
hour after hour.
Version-Release number of selected component (if applicable):
So far, every time I've tried to use it.
Steps to Reproduce:
1. just try to install FC6
So far, nothing...
Who knows? Maybe this meets the design spec for "anaconda".
Anaconda was to not touch the partition table.
How long did you let it sit? How much memory do you have and what packages did
you select to install?
Also, do you see any error messages on tty1 or tty4? This has the symptoms of a
kernel panic as well, since those just silently appear on tty4 and we have no
way to do anything at that point so the UI never gets updates.
The "default" install was whatever three checkboxes first come up and no
customization. It sat for maybe half an hour.
The customized installation included parts from Fedora Extras. It sat for maybe
There was no kernel panic or error reported on tty4.
I also tried both an "upgrade" and an "install" over the existing FC5 files. I
let the "upgrade" hang for maybe half an hour before giving up.
I also was trying to avoid allowing a "reformat", not wanting my "/local/
directory wiped. Later, on a hard disk install attempt, I noticed that anaconda
is not smart enough to remove any conflicting files from FC$, and, after a very
long time, will simply generate a cryptic error message, and reboot the machine
- kind of like a "slap in the face".
I also did get one of the hard disk install attempts to run. It got about 90%
complete, "8 miniutes" remaining, before hanging. I killed it after about an
hour of "8 minutes". Of course, it had wiped my FC5 file system. Sorry, I was
too upset to write down tty4 - something about "moving ISO from 3 to 4".
Oh - There is 256MiB of RDRAM, and half a gig of swap space on the machine.
Ok, I ran it again, the hard drive install, wiping my existing filesystem. It
INFO : switching from iso 2 to 3 for ('readline-devel', 'i386', '0', '5.1', '1.1')
<6> SELinux: initialized (dev loop3, type iso9660), uses genfs_contexts
but this time it killed itself.
rpmdb: lock_downgrade: Lock is no longer valid
install exited abnormally [1/1]
You may safely reboot your system
How many times have I said that "reboot" is the "_mean_ thing to do"...
I finally got an install to complete. I selected a minimal default install -
just the "office and productivity" checkbox - and wiped the filesystem with format.
Could this have something to do with the amount of memory - about 3/4 GiB?
Most likely. We were seeing installation issues on systems with 256MB of memory
before the FC6 release. Installation is possible in certain instances, if you
modified the default package selection, that probably tipped you over the edge
and the yum backend fell over (needs a lot of memory to calculate dependencies,
This is something we are aware of and are working on as best as possible. We
would like to reduce the install-time memory requirement as much as possible,
but it sort of works against you when the other requirements are factored in.
One solution we've been suggesting to users that have 256MB of memory (or even
less, though installation may not even work in those cases) is to perform a
kickstart install. You won't need the memory to run the graphical installation
environment since the kickstart file will provide all of the answers to the
installer. Boot the installer in text mode with a kickstart file and it should
run faster for you.
I'm trying to upgrade a 400 MHz Pentium2 test machine with 512MB RAM from
FC5 to FC6 right now and I think I'm running into the same or
a similar problem. Please notice that I booted with "linux askmethod"
and chose the NFS installation method. The installer starts normally
until I choose "Upgrade and existing installtion". Then the installer
continues until I see the following output on tty2 (after switching):
18:24:27 INFO : moving (1) to step postselection
18:24:28 INFO : selected kernel package for kernel
On tty1 I can execute top and see that the anaconda process with pid 610
uses 90% cpu time.
pid is this:
/usr/bin/python /usr/bin/anaconda -m nfs://mnt/source/. --graph
(The /mnt/source mountpoint is mounted okay and I can access it
strace shows me that anaconda is reading from fd 30
which according to lsof is the local file /mnt/sysimage/var/lib/rpm/Packages.
Notice that anaconda is reading the "Packages" file from the beginning to
the end and then repeats the procedure all over again and again!
It's now 19:03:00. The anaconda process does now have a resident size (rss)
of >78000 and it is still looping on "Packages". I'm going to give up now.
BTW: I know that the behavior is repeatable because this is my second try.
I hope this information is useful for the debugging of this problem.
Okay, I admit: I've lied: I did *not* give up but let it running for
some more time and after some more minutes the following was written
19:12:33 INFO : adding fedora-release-notes for indexhtml, required by lynx
I.e. it took from 18:24 to 19:12 until I got another reaction from
the machine - but anaconda is still not finished!
In the following minutes there were some more (and similar) INFO lines.
Now it's 19:28 and the anaconda process has a resident size of >101000
and it still keeps running...
[... time passes ...]
Now *finally* at
19:35:05 INFO : moving (1) to step confirmupgrade
So let's recapitulate:
The postselection step alone ran for 1 hour 11 minutes on this machine!
FWIW, that's 400 x 1000000 x 60 x 71 = 1.704.000.000.000 clock
cycles! I know that my test machine is rather old and has only
512MB RAM but am I really the only one who thinks that this running
time is unacceptable slow?
BTW: I was 19:53 when finally the "Preparing transaction from installation
source.." step was finished, too, and the installation of new packages
actually started. That's another 18 minutes of waiting.
(In reply to comment #7)
> One solution we've been suggesting to users that have 256MB of memory (or even
> less, though installation may not even work in those cases) is to perform a
> kickstart install.
Another approach I wish you would consider - not as elegant as using kickstart,
but straightforward - modify the "upgrade" option to run the package selection
menu, and install in two stages. This might sound like a hack, but I can tell
you that it is preferable to repeated, time consuming, failed attempts. So,
install first a minimal system. Then go back and install the additional
packages. Of course, I wish there were some way to do this from the running
system, just installing additional packages from the install media. Trying to
resolve dependencies for _all_ the packages at once always seemed silly to me.
Doesn't the complexity go up at greater than "n", more like "n!"?
Another quick status update from the "high-performance upgrades"
After another 25 minutes of waiting I got this message:
20:16:17 INFO : Initial install time estimate = 480.732054288
I.e. the estimate is >8 hours! I really hope the estimate is wrong.
At least there is a progress bar...
(BTW: There is a Fast Ethernet network between both hosts and the
NIC is running at 100MBit/FD)
Created attachment 144778 [details]
Created attachment 144779 [details]
it seems I was running into a similiar problem.
First, I have tried a pxe/kickstart installation in text mode. After booting the
installation kernel, a blue screen an tty1 appears. There is no progress after
10 hours to the installation. A top on tty2 shows two running anaconda programms
(one forked by the other) and a memory usage of 96584K of 1 GByte in total.
Second I tried an interactive installation with X. The Xserver is started, by
without any window so far (two hours waiting). Similar result on tty2 with top.
anaconda.log ans syslog opf the first installation on comment 12 and 13 resp.
Any hints welcome.
A lot of work has gone in to making anaconda (and other components we depend on)
faster in rawhide, especially at depsolving. Closing this as fixed in rawhide.
Please try rawhide or a Fedora 7 test release. If the problem still persists,
reopen the bug. But if it's a new bug, please file a new report rather than
tacking it on to this issue.