Bug 213756 - Anaconda loops when installing glibc
Anaconda loops when installing glibc
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: David Cantrell
: 213549 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2006-11-02 15:59 EST by Jean Francois Martinez
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

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

Attachments (Terms of Use)

  None (edit)
Description Jean Francois Martinez 2006-11-02 15:59:56 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20060808 Fedora/ Firefox/ 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):

How reproducible:

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:

Additional info:
Comment 1 Mike Pope 2007-01-28 18:59:21 EST
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.
Comment 2 Mike Pope 2007-01-29 18:01:19 EST
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.
Comment 3 Mike Pope 2007-01-30 19:15:42 EST
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.
Comment 4 David Cantrell 2007-01-31 11:15:27 EST
Maybe.  Check dmesg (on tty3 or tty4...somewhere around there) or /tmp/anaconda.log.
Comment 5 Mike Pope 2007-02-13 04:53:36 EST
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 
Comment 6 Chris Lumens 2007-02-22 16:07:05 EST
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.
Comment 7 Chris Lumens 2007-02-22 16:18:57 EST
*** Bug 213549 has been marked as a duplicate of this bug. ***
Comment 8 Mike Pope 2007-02-22 18:16:53 EST
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.
Comment 9 Jean Francois Martinez 2007-02-23 16:05:51 EST
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).
Comment 10 David Cantrell 2007-03-15 18:01:09 EDT
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.
Comment 11 Eric Doutreleau 2007-05-21 04:58:08 EDT
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.
Comment 12 David Cantrell 2007-08-14 17:31:18 EDT
Yeah, 256M of RAM is the bare edge on most architectures.  Installation just
takes more RAM these days.

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