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 2. 3. 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.
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 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".
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 ends with: tty3 INFO : switching from iso 2 to 3 for ('readline-devel', 'i386', '0', '5.1', '1.1') tty4 <6> SELinux: initialized (dev loop3, type iso9660), uses genfs_contexts but this time it killed itself. tty1 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, etc). 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 [*hang*] 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.
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.
(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" department: 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] anaconda.log
Created attachment 144779 [details] syslog
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.
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.