Can you attach the traceback?

For that "Rawhide anaconda just appers to hang" I can not. I do not know how to
force anaconda dump a stack trace while it is running. I know no python. I tried
sending it various signals, but was not successful forcing it to dump a
trackback. I'd appreciate if you could give me an advice how to do that?

Also, most likely I was wrong thinking that anaconda is stuck due to lack of
hard drive. The solid state disk drive was not visible due to libata/kernel bug,
but anaconda loops on that machine even with the fix for that bug.

If you are also interested in Fedora 8 traceback, I will post that one once I'm
home.

When you get the IndexError message, you should be seeing a traceback dialog
that allows you to save the traceback either to a floppy drive or to a remote
system via scp.  If you are able to transfer that information off, please do so
and attach it to this bug.

As for anaconda just hanging, there's not really anything to do there to get a
traceback.  You can look at tty3 to see what the last messages are doing, or you
can put strace on a USB drive and use that to see what it's hung up on.

What is the current status of the bug you are seeing now?

F8:

Hm, I do not know why did I think that there was an IndexError exception. All I
see is "Running anaconda..." and right away "install terminated abnormally".
Last thing in log on tty3 is "running anaconda script /usr/bin/anaconda".
Needless to say, shutdown scripts are run, shell on tty2 terminates and I can no
longer inspect the state of system.

After seeing anaconda run in qemu without a hard drive attached I am finally
confident that my problem is not due to lack of hard drive in the machine.

I have heard today that it might be possible to start anaconda with debug option
and/or break into debugger at the very beginning and then step through. I will
probably try that unless there's something smarter to do, but I am very foreign
to python and anaconda code.

Finally, I can bring the machine to the lab and provide KVM and serial line
access to it at any time. Or I will kindly ask msivak to assist :)

Rawhide:

I think I found some clue. When I begin to step through these lines:

    import signal, traceback, string, isys, iutil, time

Here I have ~3M of physical RAM (and no swap at this stage) free (from 128M).
I wait nearly a minute for all those to load...

    from exception import handleException

Things are getting hoooorribly slow. Waiting more than 20 minutes, less than 2M
free.

I could not get past here. No need to either. Is 128M just too little to install
with, even for text mode?

Also, I notice that kernel eats 60M for page cache and I could not force it to
reclaim any of it, though the only storage device the machine has is a 32M solid
state flash drive and it is not in use. vm.pagecache no longer exists and kernel
does not reclaim any of the memory even if I try to allocate blocks of memory
bigger than the apparent 'free' size (dd if=/dev/zero bs=10240k count=1
of=/dev/null).

Confirmed, when I added extra swap space on USB flash drive, installation proceeds.

Jeremy fixed the import troubles here earlier, so this should be fixed in the
next build of anaconda.

Sorry, got my commits confused.  This one is not closed quite yet.

F8: Soo, for I made an updates.img with static i386 busybox and found out that I
can not really exec anything due to "Illegal instruction". That machine can only
run i586 code (it has a VIA Samuel 2 processor, which advertises itself as i686,
but for some reason can not run our i686 binaries), so I suspect the problem was
that stuff in stage2 is compiled for i686? I guess this was a known problem as
it is fixed in Rawhide?

(In reply to comment #5)

> Also, I notice that kernel eats 60M for page cache and I could not force it to
> reclaim any of it, though the only storage device the machine has is a 32M solid
> state flash drive and it is not in use. vm.pagecache no longer exists and kernel
> does not reclaim any of the memory even if I try to allocate blocks of memory
> bigger than the apparent 'free' size (dd if=/dev/zero bs=10240k count=1
> of=/dev/null).

Actually, I did not know that ram disk actually counts as page cache.
It is the ram disk that eats such big amount of memory.

I should compare sizes of anaconda's runtime image and stage2 image to F7 ones,
which run there without any problems. I just wonder if development snapshots are
bigger than releases due to some debugging data/tools present?

The kernel has debug turned on so they'll be bigger, and we're changing a bunch
of things with how the stage stuff gets moved around.

Is this still a problem for rawhide?  It sounds like the machine is pretty darn
small, and may not really fit our minimum system requirements.  At least not
enough to block the release for this.  I'm going to move this over to Target for
now.

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping