Created attachment 520925 [details] Files containing the screenshot and the ks file. Description of problem: /sbin/loader is segfaulting when I attempt to use a kickstart file (attached) to install the system. This is reproduced using the Easy Install feature of Workstation 8.0 How reproducible: 100% Steps to Reproduce: 1. Create a new VM with fedora 16 a1 as the guest 2. Boot the VM Actual results: SIGSEGV Expected results: Automatic installation. Additional info: The kickstart file along with a screen shot of the back trace is attached to the bug.
Hi Andrew, I am unable to reproduce this. Please try switching to tty2 after the crash and scp /tmp/anaconda.log to another computer. Then please attach this file to the bug report.
Ales, Did you try using Workstation 8.0 (or perhaps Workstation 7.x)? The Easy Install feature there creates a smaller ISO with the kernel, initrd, kickstart file and a couple of other files to avoid having to remaster the entire ISO. I am wondering if that has anything to do with this issue. Today is a holiday in the states. I will try and grab the log if possible tomorrow, but IIRC I was unable to switch VTs after the SEGV.
What is Workstation 8.0?
VMware Workstation. You should be able to reproduce the problem using VMware Player application as it also incorporates Easy Install.
I'm afraid I don't have VMWare software available. If you just tell me the exact ISO (release and architecture) you used I can try to decrypt from the traceback where exactly the sigsegv happened.
Created attachment 521729 [details] The anaconda log file.
Sure. Below is the ISO information, including an MD5 sum: ed3a0da651c7687a52b38f74af9d5ec4 ./Fedora-16-Alpha-x86_64-DVD.iso IIRC I got it from http://download.fedoraproject.org/pub/fedora/linux/releases/test/16-Alpha/Fedora/x86_64/iso/Fedora-16-Alpha-x86_64-DVD.iso I have also attached the Anaconda log file you requested. Based on the backtrace it appears that a bad address is being passed into the strdup function.
(In reply to comment #7) > Sure. Below is the ISO information, including an MD5 sum: > > ed3a0da651c7687a52b38f74af9d5ec4 ./Fedora-16-Alpha-x86_64-DVD.iso > > IIRC I got it from > http://download.fedoraproject.org/pub/fedora/linux/releases/test/16-Alpha/Fedora/x86_64/iso/Fedora-16-Alpha-x86_64-DVD.iso > > I have also attached the Anaconda log file you requested. Based on the > backtrace it appears that a bad address is being passed into the strdup > function. That would point to anaconda version 16.14.6 but I've still had no luck decoding the traceback: eu-addr2line -e loader 0x414caa ??:0 0x41532d ??:0 0x40a6af ??:0 0x40b6c9 ??:0
Andrew, can you please attach the screenshot of the segv again, from the f16 alpha dvd that had the ed3a0da651c7687a52b38f74af9d5ec4 (that is the same one I'm trying to match the traceback addresses against). If the matching fails again I'm afraid I won't be able to help you.
Also one thing you can try is using the "devel" parameter on the command line to have coredump created when the sigsegv happens. Then please attach the core file to this bug.
Created attachment 522995 [details] Screen shot of the SEGV in the loader
Created attachment 522998 [details] Loader core file. Cores for all!
Ales, I have re-uploaded the screen shot and core file per your request.
(In reply to comment #12) > Created attachment 522998 [details] > Loader core file. > > Cores for all! Thanks for the core that could help somewhat, though maybe we'll have to repeat the exercise with a post-beta compose since I just found today there are no debug symbols in the alpha build (sorry). I'd like to reproduce your setup here: I noticed you used a kickstart from the cdrom --- how did you put the file in there, i.e. did you remake the iso with the file in?
(In reply to comment #14) > I'd like to reproduce your setup here: I noticed you used a kickstart from the > cdrom --- how did you put the file in there, i.e. did you remake the iso with > the file in? Yes... the ISO is a custom made ISO. Essentially we copy your kernel, initrd, an isolinux.cfg file, an el torito boot image, the kickstart file and a few other files to the ISO image. Then we use genisoimage to create the whole thing. Here is the call: mkisofs -o /path/to/output -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table /path/to/iso/contents
Posted patch that should help us to a more useful tracebacks in the future: https://www.redhat.com/archives/anaconda-devel-list/2011-September/msg00157.html
(In reply to comment #15) > (In reply to comment #14) > > I'd like to reproduce your setup here: I noticed you used a kickstart from the > > cdrom --- how did you put the file in there, i.e. did you remake the iso with > > the file in? > > Yes... the ISO is a custom made ISO. Essentially we copy your kernel, initrd, > an isolinux.cfg file, an el torito boot image, the kickstart file and a few > other files to the ISO image. Then we use genisoimage to create the whole > thing. Here is the call: > > mkisofs -o /path/to/output -b isolinux/isolinux.bin -c isolinux/boot.cat > -no-emul-boot -boot-load-size 4 -boot-info-table /path/to/iso/contents ok this is not very typical and could be the reason why we haven't seen this yet. I'll try to create a similar .iso and boot it here. We'll attack this problem from several fronts.
proposing as a blocker, we at least need to get the debug symbol problems fixed.
Re-enabling anaconda-debuginfo package, on f16-branch 061bb77abbdea39fcebb88e010ef31a75e9805ce on master 1703c7bc5efa98cd40f4b410d1649111f6a1a662.
Also I just reproduced this on KVM so this is not VMware specific.
Fix posted: https://www.redhat.com/archives/anaconda-devel-list/2011-September/msg00174.html Will push after review and when this is an accepted NTH.
Discussed at 2011-09-30 NTH review meeting. Accepted as NTH - it's an anaconda crash, and we're pretty much automatic +1 nth to any anaconda crash, especially this early.
Fixed on the f16-branch: de985d07c4fa04440f6cc166fab969352aa3fde1 Fixed on master: 136f8196de270a349500ef9aad3e00801dd641ff
Excellent. Is there a nightly I can easily grab and test with? A quick googling shows http://dl.fedoraproject.org/pub/alt/nightly-composes/ but these are from the 30th. Also they are live images :P. Thanks.
(In reply to comment #24) > Excellent. Is there a nightly I can easily grab and test with? A quick > googling shows http://dl.fedoraproject.org/pub/alt/nightly-composes/ but these > are from the 30th. Also they are live images :P. Thanks. There *should* be a post-beta compose appearing here sometime: http://serverbeach1.fedoraproject.org/pub/alt/stage/ Make sure to wait for one with anaconda-16.21-1.
Nothing's going to show up there until Final TC1, which won't be for a bit (week or two, I didn't check yet). I think pub/fedora/linux/development/16 on the mirrors might get updated installer images semi-regularly, I'm not entirely sure.
*** Bug 744341 has been marked as a duplicate of this bug. ***
We're well past anaconda 16.21 so this should be fixed now. Please re-open if F16 doesn't work (you can pull any of the Final TCs or RCs to test). -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers