Description of problem: When trying to install Fedora 10 as a KVM guest Virtual Machine, from the DVD - Fedora setup stucks at the near end setup stage, when trying to install GRUB bootloader into HDD. It didn't proceed within one hour, which indicates "stucked" VM. Sometimes it may stuck earlier - during init or during early setup. Live CD (32-bit) started fine on both Intel and AMD. (except top menu minor rendering bug) Guest(s): Fedora 10 64-bit Guest(s): Fedora 10 32-bit Host(s): Fedora 7 64-bit, Intel, KVM-79 Host(s): Fedora 7 64-bit, AMD, KVM-79 Command: (for DVD) qemu-kvm -cdrom /isos/linux/Fedora-10-x86_64-DVD.iso -m 512 -hda /vm/f10-64.qcow2 -boot d *and* (for LiveCD) qemu-kvm -cdrom /isos/linux/F10-i686-Live.iso -m 512 I compiled kvm-79 from source tarball. Version-Release number of selected component (if applicable): KVM-79 How reproducible: Steps to Reproduce: 1. Take any host with recent KVM 2. Try to install Fedora 10 on it 3. Actual results: Install will fail after all 1000+ packages copied, during bootloader copy. Expected results: Bootloader should install successfully, and Fedora 10 Anaconda setup should ask for restart. Additional info: I don't know if the bug is in kvm or in Fedora 10, but would really like to find out. Previous Fedora versions work fine (7/8/9). Similar bug is opened in KVM bugzilla: http://sourceforge.net/tracker/index.php?func=detail&aid=2353510&group_id=180599&atid=893831 -Alexey 2.12.2008.
Alexey, This usecase WFM. In this case, can you provide us with more info? Examples of interesting information are: * host dmesg * guest dmesg (if you are able to ctrl+alt+f2 and get a shell) * info registers in qemu monitor when the crashes happen.
Short intro: I'm a new (Sept 1st) anaconda team member. I use kvm to try and reproduce all kind of anaconda bugs, resulting in all kind of kvm abuse. And I'm seeing this bug too. I've tried any combination of (from koji): kernel-2.6.27.7-132.fc10.x86_64 kernel-2.6.28-3.fc11.x86_64 kvm-74-10.fc10.x86_64.rpm kvm-81-1.fc11.x86_64.rpm I'm doing http installs from an apache http server running on the host machine. I'm not specifying any os-variant, as I do not want to use virtio devices. I have only managed to install F-10 successfully once. In this case I was doing an install to an iscsi based root fs (scsi over tcp/ip) install, only /boot was on a virtual kvm harddisk (the iscsi disk is a partition on my host harddisk, made available as iscsi disk through the iscsitarget software). Normal F-10 installs fail consistently, so this *might* be disk I/O related. My latest 20 or so attempts have all been using a setup with 2 virtual disks using the special qcow images available here: http://wiki.debian.org/DebianInstaller/SataRaid These images contain empty disks with sil dmraid (cheap motherboard "hardware" raid) signatures on them, to be able to test dmraid installs. These cause anaconda (and Fedora once installed) to see these 2 disks as a "hardware" raid 1 array (which gets treated as software raid 1 as it really is) raid 1 is mirroring, so each write gets done twice leading to lots of disk I/O. I've seen various types of install failures with this setup: 1) Most often the guest OS would completely hang in various places 2) Some times there were mysterious disk I/O errors, where for example trying to mount a just mkfs-ed fs failed with an error that it was not a valid ext3 fs 3) Some times the network connection would completely die When the guest OS did not completely hang I did try doing dmesg, and I've done dmesg on the host too, there was nothing relevant in either. I'm writing this all down now, as I've just had a break through, specifying "clocksource=jiffies" (I haven't tried other clocksources yet) made the F-10 on fake raid 1 install succeed in one try! This is with the 2.6.28-3 kernel and 74-10 kvm (haven't tried other versions yet).
Oh, btw I'm using the following CPU: vendor_id : AuthenticAMD cpu family : 15 model : 107 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ Using x86_64 F-10 host, trying to install i386 F-10 guest
I also encountered multiple failures attempting to install a Fedora 10 x86_64 kvm guest (using Fedora 10 x86_64 as the host). The usual failure mode was that the entire guest would hang sometime during package installation (often on selinux-policy-targeted). At least once, though, anaconda died because rpm code threw an assertion. I also managed to finish the installation once, but then installing the boot loader bombed out. I was finally able to get a successful install (using virtio drivers), but the resulting system is unstable; it hasn't made it more than 12 hours without locking hard. Hans, given that you got a successful install when you changed the clocksource, I think this might actually be an instance of bug 475598.
Yes, I agree with Comment #4. I'm going to close it as a dup of 475598 for now; if it turns out to be something different, we can re-open. Chris Lalancette *** This bug has been marked as a duplicate of bug 475598 ***
Verified not-a-dup. Copied from BZ# 475598: I have the following symptoms: * Fedora 10/x86-64 fails to install as KVM guest. Hangs at "installing bootloader" step. * Fedora 10/x86-64 with current updates is the host OS. This behavior appears with both the Fedora stock kernel or a custom 2.6.29-rc5 kernel running on the host. I tried "clocksource=acpi_pm" for the Fedora 10 guest, without success. Hardware: Intel ICH10 /proc/cpuinfo selected lines: ... vendor_id : GenuineIntel cpu family : 6 model : 26 model name : Genuine Intel(R) CPU 000 @ 3.20GHz stepping : 4 ... 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 xtopology nonstop_tsc pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 lahf_lm ida tpr_shadow vnmi flexpriority ept vpid
I don't know if this information comes at any value at you, but for me it turned out to be sufficient to increase RAM of guest to 1024MB.
Reproduced! Host config: Fedora 10, x86-64, KVM, 4GB RAM Guest config: Fedora 10, x86-64 When guest is configured "512mb initial, 1024mb max" Fedora 10 guest install hangs at "installing bootloader" step. When guest is configured "1024mb initial, 1024mb max" Fedora 10 guest install succeeds.
Cool ... I think this is bug #480826 then, right?
I dunno whether the root cause is the same, but the symptoms here are different from bug #480826 Here, the Fedora 10 installer freezes at "installing bootloader". The installer does not crash; and at least in my own case, I use a pre-existing, pre-allocated file 8GB in size for the main disk. I agree with your comment in the other bug, though: at the very least, until the root cause is found, shouldn't we warn users when they select memory < 1GB? Also, FWIW, I moved the memory back down to 512MB after install, and things are working fine (presumably in part because swap is setup and I am not OOMing.....?)
Okay, moving to anaconda
A recent change to anaconda causes us to use tmpfs instead of ramfs for certain filesystems now, which means we have the ability to swap those things out and therefore use less memory. It's quite likely this lowers the memory requirements and fixes this bug. If you could test with F11 when released and let us know if you are still seeing this problem. Thanks.
I am also seeing the problem where the system hangs at "Installing bootloader" with F11 guest on debian host even when allocating 2048 megs of RAM. Details: DISK kvm-img create -f qcow2 f11-base.img 4G Partitions ("custom"): sda1 200M ext3 /boot sda2 3894M ext4 / no swap PACKAGES Deselect "Office and Productivity", select "Customize later", so there is a "minimal" install without doing real specific customization. KVM QEMU PC emulator version 0.9.1 (kvm-72) kvm -hda f11-base.img -cdrom Fedora-11-x86_64-DVD.iso -boot d -m 2048 -no-acpi -vnc :3 -redir tcp:6303::22 HOST System Debian 5.0.2 (stable) amd64 (x86_64) kernel 2.6.30 (custom, not tainted) 4 gigs RAM, 8 CPU
Created attachment 350544 [details] dmesg from within the F11 anaconda kvm guest
Created attachment 350545 [details] dmesg of debian kvm host
When the system hangs on "Installing bootloader", I can't ctrl-alt-fN over to other consoles as the system is locked. So what I tried doing 3 times now, is to get the package install running, then leave the console switched over to console 1 (ctrl-alt-f1) or console 5 to see what it barfs out when crashed. But everytime (well, 3 in a row) that I do this, the system installs fine (e.g. F1 says "You may safely reboot your system"). I can switch to other consoles (the system isn't crashed), but on console 6 (the GUI), there is nothing displayed, just a blank screen with an underscore in the upper left. Anyway, I thought it was interesting each time that I don't leave it on the GUI screen things work. I would provide more info from kvm if I knew what in particular you were looking for (and how to get it).
host A f10 2.6.27.25-170.2.72.fc10.x86_64 kqemu-1.3.0-0.8.pre11.fc10.noarch qemu-0.9.1-12.fc10.x86_64 host B f9 2.6.27.25-78.2.56.fc9.x86_64 qemu-0.9.1-6.fc9.x86_64 kqemu-1.3.0-0.8.pre11.fc9.noarch guests: both f10 & f11 kickstarted with only base { with f10 and 512MB RAX=00007f533e289000 RBX=00007f533e289568 RCX=000000000012792a RDX=0000000000000001 RSI=000000000012a81e RDI=0000000000000000 RBP=00007f533e289000 RSP=00007fff46286fd0 R8 =00000000ffffffff R9 =0000000000000000 R10=0000000000000022 R11=0000000000010246 R12=0000000000400040 R13=0000000000000000 R14=0000000000000000 R15=0000000000000010 RIP=000000000011aff4 RFL=00010206 [-----P-] CPL=3 II=0 A20=1 SMM=0 HLT=0 ES =0000 0000000000000000 00000000 00000000 CS =0033 0000000000000000 ffffffff 00affb00 SS =002b 0000000000000000 ffffffff 00cff300 DS =0000 0000000000000000 00000000 00000000 FS =0000 0000000000000000 00000000 00000000 GS =0000 0000000000000000 00000000 00000000 LDT=0000 0000000000000000 00000000 00008000 TR =0040 ffff880001012080 00002087 00008900 GDT= ffff88000100b000 0000007f IDT= ffffffff81712000 00000fff CR0=8005003b CR2=00007f533e289028 CR3=0000000003cf1000 CR4=000006e0 Unsupported return value: 0xffffffff with f10 and 1024MB RAX=0000000000000001 RBX=00007f38b19874c8 RCX=0000000000000000 RDX=0000000000404210 RSI=000000000041628b RDI=0000000000b03660 RBP=00007fffb99885a0 RSP=00007fffb9988440 R8 =0000000002dd0603 R9 =000000000000001b R10=00007fffb99883c0 R11=0000000000af0cb0 R12=00000000b74180db R13=0000000000000000 R14=0000000000000000 R15=00007fffb9988568 RIP=000000000011a46f RFL=00010297 [--S-APC] CPL=3 II=0 A20=1 SMM=0 HLT=0 ES =0000 0000000000000000 00000000 00000000 CS =0033 0000000000000000 ffffffff 00affb00 SS =002b 0000000000000000 ffffffff 00cff300 DS =0000 0000000000000000 00000000 00000000 FS =0000 00007f38b19856f0 00000000 00000000 GS =0000 0000000000000000 00000000 00000000 LDT=0000 0000000000000000 00000000 00008000 TR =0040 ffff880001015080 00002087 00008900 GDT= ffff88000100e000 0000007f IDT= ffffffff81712000 00000fff CR0=8005003b CR2=00007f38b19877dd CR3=0000000009dd5000 CR4=000006e0 Unsupported return value: 0xffffffff } dmesg: Jul 30 13:57:34 whale kernel: kqemu: aborting: Unexpected exception 0x0d in monitor space Jul 30 13:57:34 whale kernel: err=0000 CS:EIP=f180:00000000f000277e SS:SP=0000:00000000f00c8e10 Jul 30 14:00:05 whale kernel: kqemu: aborting: Unexpected exception 0x0d in monitor space Jul 30 14:00:05 whale kernel: err=0000 CS:EIP=f180:00000000f000277e SS:SP=0000:00000000f00c8e70 for me essentially it always crashes, with selinux on host/guest or without
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
Too old. Closing.