From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.6) Gecko/20060808 Fedora/1.5.0.6-2.fc5 Firefox/1.5.0.6 pango-text Description of problem: On a machine with 224 Mags of memory and while installing in graphic mode, anaconda seemed to enter an infinite loop while installing glibc or glibc-common. There was nodisk activity (thus it was not that machinehad become very slow due to heavy swapping). Anconda just sat and a ps showed it was steadily eating CPU cycles After about half an hour (the machine was a 1.7Ghz P4) I aborted the installation. Retried, same. Retried in text mode and the glib package was installed in a few dozens of seconds. BTW I had installed FC6 on a 1G machine in graphic mode and from a CD Version-Release number of selected component (if applicable): anaconda-11.1.1.3-1 How reproducible: Always Steps to Reproduce: 1. In case you have more memory restrict yourself to 224M but use graphic mode 2. Install from an iso file (not sure what happens from a CD) 3. Go around the installation, accept the default for packages and anaconda will format partitions, prepare for installation, check dependencies and begin to instal thre small packages before it installs glibc. At this point it loops. Actual Results: Anaconda looped. Expected Results: Obvious Additional info: 2
I can reproduce this 100% reliably on an ancient P2 with 128M doing a text mode http install, PXE boot (the machine has no CD and can not boot from USB). It always stops installing at glibc-common (5% in). The shell console is live, ps shows the anaconda processes are not doing much, certainly there is no disk activity. The log windows do not show anything obvious error messages. The http logs on the server similarly show no problem, just no further activity after the glibc-common rpm is fetched. The obvious odd thing about this install is the low memory forces early activation of swap. The hardware is intact, such as it is--- I can run Damn Small Linux without problems.
I tried using a custom disk layout so I could vary the swap size. With 130 and 260M swap it hangs immediately on the first package (libgcc). With 66M it gets further(!), even past glibc-common, but eventually crashes in rpm. I will try 128M - delta next, and also a memory test.
128M - delta behaves the same as 66M swap. Memory passes all tests. I am however suspicious that there are bad blocks on the disk, which might be implicated in the rpm crash.
Maybe. Check dmesg (on tty3 or tty4...somewhere around there) or /tmp/anaconda.log.
Repartitioned and reformatted the disk under Damn Small Linux with maximum error checking, then did a custom install using the existing partitions. No crash in rpm this time, but back to the real bug where anaconda just gives up and sits there. The installation did get further though, stopping in fedora-logos/whatever its called. There were no interesting messages on the other consoles. Tried a couple more times, this time with NFS. Finally, one of the installs got far enough that on reboot anaconda recognized that fedora was present and offered to reinstall. This time with much fewer packages it got through without hanging. So, my observation is that the bug is independent of install method, but unpredictable as to where the hang will occur.
I don't know that there is much we can do here. The graphical environment is rather large and takes up a lot of memory, which is what you're running into there. yum and rpm aren't exactly light when it comes to memory usage, so a lot is being consumed by those two for dealing with the transaction set. Adding more swap may help some, but the randomness of the problems you're seeing is indicative of memory pressure during installation.
*** Bug 213549 has been marked as a duplicate of this bug. ***
Re #6, as stated in #1, I can reproduce the bug in text mode installs (indeed FC6 sensibly refuses to even contemplate graphic installs on my 128M box). Similarly, adding more swap does not help. The problem is still there at 512M swap. I can try up to 1G if you like. As to what can be done... if you are right that the problem is memory pressure, surely this can be detected? A simple `out of memory' error is a lot kinder than a mysterious hang. But further to that... 128M is too little, even when backed by abundant swap? Sad. Especially when this is the official minimum supported text mode configuration according to the FC6 release notes.
The explanation from Chris Lumens does not hold. Machine did not exhibit the symptoms of one who is swapping lika crazy. In fact there was zero disk activity. I also doubt that the explanation could be that the kernel had run into unsolvable poblem of memory limits and killed a process neede by the installer and this one started to loop like crazy. This is ever preceeded by furious swapping and I had none of this. Could it be that the killing took place before swap was activated? Alos very dubious 1) because when you don't have enough memory the installer acticates the swap much sooner and 2) because there is a slo furious disk activity (in fact worse) because the kernel who cannot copy data pages to swap tries to cope by discarding code pages and so it is forced to reread gain and again code pages. My hypotheris is that at one point the installer tres to activate swap and is "surprised" to find swap already active (because in machines who whart on memeory it is activated much soooner than usual).
Installation with less than 256MB is not supported. But that doesn't mean it's impossible. Just difficult. Regarding activating swap early on... we do this when we see you have a low memory situation. I have seen instances where we try to re-enable swap that has already been activated. That's probably something we can fix.
i have the same problem with a machine with 256M anaconda just run 100% of cpu. It occurs randomly during the installation of package. the same kickstart file with a machine with 512Mo does not have the problem.
Yeah, 256M of RAM is the bare edge on most architectures. Installation just takes more RAM these days.