Bug 213148 - anaconda hangs
anaconda hangs
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Anaconda Maintenance Team
Depends On:
  Show dependency treegraph
Reported: 2006-10-30 18:07 EST by james
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-03-15 17:55:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
anaconda.log (30.01 KB, text/plain)
2007-01-04 04:37 EST, Peter Leinen
no flags Details
syslog (21.05 KB, text/plain)
2007-01-04 04:37 EST, Peter Leinen
no flags Details

  None (edit)
Description james 2006-10-30 18:07:48 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):
FC6 installer

How reproducible:
So far, every time I've tried to use it.

Steps to Reproduce:
1. just try to install FC6
Actual results:
So far, nothing...

Expected results:
Who knows?  Maybe this meets the design spec for "anaconda".

Additional info:
Anaconda was to not touch the partition table.
Comment 1 Jeremy Katz 2006-10-30 18:13:14 EST
How long did you let it sit?  How much memory do you have and what packages did
you select to install?
Comment 2 Chris Lumens 2006-10-31 09:59:28 EST
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.
Comment 3 james 2006-10-31 16:23:00 EST
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
two hours.

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".
Comment 4 james 2006-10-31 16:25:49 EST
Oh - There is 256MiB of RDRAM, and half a gig of swap space on the machine.
Comment 5 james 2006-10-31 20:11:04 EST
Ok, I ran it again, the hard drive install, wiping my existing filesystem.  It
ends with:

 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"...
Comment 6 james 2006-11-01 00:13:54 EST
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?
Comment 7 David Cantrell 2006-11-01 11:26:55 EST
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.
Comment 8 Karsten Weiss 2006-11-01 14:11:05 EST
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
without problems)

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.
Comment 9 Karsten Weiss 2006-11-01 14:56:36 EST
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
on tty2:

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.
Comment 10 james 2006-11-01 15:02:07 EST
(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!"?
Comment 11 Karsten Weiss 2006-11-01 15:44:28 EST
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)
Comment 12 Peter Leinen 2007-01-04 04:37:09 EST
Created attachment 144778 [details]
Comment 13 Peter Leinen 2007-01-04 04:37:41 EST
Created attachment 144779 [details]
Comment 14 Peter Leinen 2007-01-04 04:44:37 EST
Hi all,

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.
Comment 15 David Cantrell 2007-03-15 17:55:47 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.