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.
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