Created attachment 323941 [details] kernel panic output Description of problem: While performing new install, kernel panic when it could not find init. command executed: /usr/bin/qemu-kvm -drive file=/a/m/sf/dev/i386/os/images/boot.iso,media=cdrom -drive file=/a/i/fda0 -localtime -usbdevice tablet -name fda0-17740 -net nic,vlan=7740,macaddr=55:55:55:01:18:40 -net user,vlan=7740,hostname=fda0-17740 -m 512 Version-Release number of selected component (if applicable): kernel-2.6.27.5-113.fc10.i686 How reproducible: persistent Additional info: attached copy of output
Eric, Can you add a -serial to your command line, edit your grub (or whatever) to get console=ttyS0 as well, and send that file to us? A recent enough kernel got the scheduler running earlier (probably your case, but not sure), so it is quite possible that any relevant messages are far beyond what you can see in the screen.
Created attachment 323974 [details] debug out output New complete command executed: /usr/bin/qemu-kvm -kernel /a/m/sf/dev/i386/os/isolinux/vmlinuz -initrd /a/m/sf/dev/i386/os/isolinux/initrd.img -append "ksdevice=52:54:00:01:18:40 ks=http://192.168.5.101/a/ks/fda0-17740 console=ttyS0,115200" -drive file=/a/i/fda0,boot=on -serial file:/a/q/z.debug -name fda0-17740 -net nic,vlan=7740,macaddr=52:54:00:01:18:40 -net tap,vlan=7740,ifname=fda0-17740,script=/a/q/tap.sh -m 512 attached is the complete debug output
I don't know exactly what does "ks" are, but you don't seem to be mounting any root device here.
Created attachment 324053 [details] kickstart file ks is the kickstart file (attached). I normally use kickstart file for new install, even under KVM, and never had problem with it. Here is a simplified commandline without the extraneous options for this test: /usr/bin/qemu-kvm -kernel /a/m/sf/dev/i386/os/isolinux/vmlinuz -initrd /a/m/sf/dev/i386/os/isolinux/initrd.img -append "console=ttyS0,115200" -drive file=/a/i/fda0,boot=on -serial file:/a/q/z/z.debug -m 512
Created attachment 324054 [details] debug outputs w/ the new simplified commandline
I just want to add that under x86_64 I was able to complete installation.
I've also experienced this same bug/symptom on a physical box (as opposed to eric's QEMU attempt) using the 11/18 closest-mirror/pub/fedora/development/i386/os/images/boot.iso and taking the default options.
Propose moving this bug to kernel Component rather than kvm.
mike, you need to show your full logs. The trees from the 18th I do believe had a broken anaconda due to glibc changes, so we'd want to get your results from the 19th's tree (today).
Jesse, Apologies. I had no logs other than the last three lines of panic. However, since then I've checked my nearest mirror and lo and behold an 11/19 boot.iso appeared. Bug fixed on my physical box. (Unless of course this really is a kvm bug.)
What is the kvm version and kernel version of the host? I am not able to reproduce this with kvm-74-5.fc10.x86_64 and kernel-2.6.27.5-101.fc10.x86_64 using the kernel and initrd from 20081119.
The latest build tree(11/20/08) I just download this morning resolved the problem. kvm-74-5.fc10.x86_64.rpm qemu-0.9.1-10.fc10.x86_64.rpm kernel-2.6.27.5-117.fc10.x86_64.rpm
Ok, this wasn't a bug in kvm, it was a compose tool issue.