Description of problem: Recently my CentOS 5 VM image started failing to boot. I can press a key to get to the selector of which of the installed kernels should be booted. But which ever I choose nothing more happens after this. My other images of Fedora Rawhide and Debina Testing continue to boot fine. Considering the possibility that the image somehow got broken, I tried to create a new one using the CentOS 5.9 netinstall iso image. This does not work either. The boot starts, but after you press enter on the first screen where you select the type of installation you want to do, the screen goes blank with a blinking underline cursor at the top left, but nothing happens after this. Version-Release number of selected component (if applicable): qemu-system-x86-1.2.2-11.fc18.x86_64 libvirt-0.10.2.5-1.fc18.x86_64 How reproducible: Always Steps to Reproduce: Try to create a CentOS 5.9 guest on a Fedora 18 host Actual results: Installation stalls Expected results: Working installation
I experience the same and I suspect a (host) kernel bug. If I boot 3.9.2-200.fc18.x86_64 on the VM host it doesn't work but using kernel-3.8.11-200.fc18.x86_64 works. When I start an existing CentOS 5 VM this is the last thing I see (after grub): ... root (hd0,0) Filesystem type is ext2fs, partition type 0x83 kernel /vmlinux-2.6.18-348.1.1.el5 ro root=... clocksource=acpi_pm [Linux-bzimage, setup=0x1e00, size=0x2050fc] initrd /initrd-2.6.18-348.1.1.el5.img [Linux-initrd @ 0x37c98000, 0x357ed0 bytes] It seems to be an upstream but or at least the same problem exists on Arch Linux: https://bugs.archlinux.org/task/35247
Still broken with kernel-3.9.4-200.fc18.x86_64. Reassigning to kernel.
I can confirm that there is a difference between qemu-system-x86_64 -cdrom CentOS-5.9-x86_64-netinstall.iso and qemu-system-x86_64 -cdrom CentOS-5.9-x86_64-netinstall.iso -enable-kvm meaning that the latter exhibits the problem. Setup is Debian sid or testing: ii qemu-system-x86 1.5.0+dfsg-4 i386 QEMU full system emulation binaries (x86) Linux tglase.lan.tarent.de 3.9-1-amd64 #1 SMP Debian 3.9.6-1 i686 GNU/Linux Linux ldegen-wirt.lan.tarent.de 3.9-1-amd64 #1 SMP Debian 3.9.6-1 x86_64 GNU/Linux A “ceteris paribus” reboot into the stable Debian kernel makes things work with -enable-kvm (and blazingly fast compared to without it): Linux ldegen-wirt.lan.tarent.de 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1 x86_64 GNU/Linux I’ll also prod the Debian Kernel people. Our primary symptom was, in case someone is interested, a Windows® VM with virtio drivers no longer coming up (“crc error system halted” with enough debug level bumping); my co-admin referenced this bugreport.
I suspect this might also be related to the host CPU. I can run a CentOS VM (or the netinstall) just fine on a quite recent Intel machine but not on an old Intel laptop of mine. The libvirt config is identical as well as the Fedora patch level/installed rpms. working machine: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz 4 cores cpu family 6 model 42 not working: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz 2 cores cpu family 6 model 15 Probably time for some kernel bisecting?
Not quite… Not working #1: processor : 7 vendor_id : GenuineIntel cpu family : 6 model : 26 model name : Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz stepping : 5 microcode : 0x16 cpu MHz : 1596.000 cache size : 8192 KB physical id : 0 siblings : 8 core id : 3 cpu cores : 4 apicid : 7 initial apicid : 7 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dtherm tpr_shadow vnmi flexpriority ept vpid bogomips : 6133.32 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: Not working #2: processor : 7 vendor_id : GenuineIntel cpu family : 6 model : 26 model name : Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz stepping : 5 microcode : 0x11 cpu MHz : 3060.000 cache size : 8192 KB physical id : 0 siblings : 8 core id : 3 cpu cores : 4 apicid : 7 initial apicid : 7 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dtherm tpr_shadow vnmi flexpriority ept vpid bogomips : 6128.71 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:
Pretty sure this is a dup, please reopen if I'm wrong. *** This bug has been marked as a duplicate of bug 967652 ***