This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 395791 - Anaconda crashes or loops early after startup
Anaconda crashes or loops early after startup
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: F9Target
  Show dependency treegraph
 
Reported: 2007-11-22 11:10 EST by Lubomir Kundrak
Modified: 2008-05-19 17:39 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-19 17:39:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Lubomir Kundrak 2007-11-22 11:10:39 EST
Description of problem:

Anaconda in Fedora 8 crashes with an (IndexError?) exception (Fedora 7's does
not) when no hard drives are found. Rawhide anaconda just appers to hang. This
is definitely a problem that prevents installing on diskless machines.

Though my one is not diskless, its bootable flash drive is not detected due to a
kernel bug. Please note that certain BIOSes are able to boot from iSCSI and gPXE
project also offers that feature, so installing on a diskless machine makes
perfect sense.

Version-Release number of selected component (if applicable):

anaconda-11.4.0.1-1

Steps to Reproduce:
1. Run it in qemu with /dev/null as a hard drive.
Comment 1 Jeremy Katz 2007-11-26 11:38:43 EST
Can you attach the traceback?
Comment 2 Lubomir Kundrak 2007-11-26 12:38:10 EST
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.
Comment 3 Chris Lumens 2007-11-27 16:46:49 EST
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?
Comment 4 Lubomir Kundrak 2007-11-28 14:53:48 EST
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 :)
Comment 5 Lubomir Kundrak 2007-11-28 19:11:29 EST
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).
Comment 6 Lubomir Kundrak 2007-11-28 19:37:08 EST
Confirmed, when I added extra swap space on USB flash drive, installation proceeds.
Comment 7 Chris Lumens 2007-11-29 10:15:58 EST
Jeremy fixed the import troubles here earlier, so this should be fixed in the
next build of anaconda.
Comment 8 Chris Lumens 2007-11-29 10:32:19 EST
Sorry, got my commits confused.  This one is not closed quite yet.
Comment 9 Lubomir Kundrak 2007-11-29 14:04:34 EST
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?
Comment 10 Lubomir Kundrak 2007-11-29 17:15:11 EST
(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?
Comment 11 Jesse Keating 2008-03-31 17:10:49 EDT
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.
Comment 12 Bug Zapper 2008-05-13 23:58:52 EDT
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

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