Red Hat Bugzilla – Bug 213756
Anaconda loops when installing glibc
Last modified: 2007-11-30 17:11:47 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:220.127.116.11) Gecko/20060808 Fedora/18.104.22.168-2.fc5 Firefox/22.214.171.124 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):
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.
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
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.