Description of problem: f11 installation hangs up after all packages installed in kvm. when all packages are installed ,the installer should go next step to reboot the system. Version-Release number of selected component (if applicable): virt-manager-0.7.0-4.fc11.i586 How reproducible: 100% Steps to Reproduce: 1. create a VM in kvm to install f11 2. All select default, after all packages install finished,the installation hung up there and system did not reboot automatically. 3. Actual results: when all packages are installed ,the installer should go next step to reboot the system.We need to force shut off the system and restart.We can start the system ,but mouse and keyboard do not work, it's another bug. Expected results: Additional info:
What version of libvirt and qemu is this? Please include ~/.virt-manager/virt-manager.log and the guest log from /var/log/libvirt/qemu/ What version of F11 is this? Beta?
Created attachment 345387 [details] virt-manager.log
Created attachment 345388 [details] f11 log
[root@dhcp-66-70-91 iso]# rpm -qa |grep qemu qemu-system-cris-0.10.4-5.fc11.i586 qemu-0.10.4-5.fc11.i586 qemu-common-0.10.4-5.fc11.i586 qemu-system-sparc-0.10.4-5.fc11.i586 qemu-system-x86-0.10.4-5.fc11.i586 qemu-system-mips-0.10.4-5.fc11.i586 qemu-kvm-0.10.4-5.fc11.i586 qemu-user-0.10.4-5.fc11.i586 qemu-system-arm-0.10.4-5.fc11.i586 qemu-system-ppc-0.10.4-5.fc11.i586 qemu-img-0.10.4-5.fc11.i586 qemu-debuginfo-0.10.4-5.fc11.i586 qemu-system-sh4-0.10.4-5.fc11.i586 qemu-kvm-tools-0.10.4-5.fc11.i586 qemu-system-m68k-0.10.4-5.fc11.i586 logs, please see attachments. Thanks
Okay, confirmed with rc0.1 To clarify a little further: - x86_64 KVM guest install from DVD ISO - When anaconda finishes installing packages, it doesn't wait at the install screen - The guest fails to reboot Adding to F11VirtBlocker and re-assigning to anaconda
I don't think this is an anaconda bug, at least not directly. A text mode install shows the following happening around the time of bootloader installation (on /dev/vda): ata2.00: exception Emask 0x0 SACt 0x0 SErr 0x0 action 0x6 ata2.00: cmd a0/00:00:00:00:00:/00:00:00:00:00/a0 tag 0 cdb 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res 01/60:00:00:00:00:00:/00:00:00:00:00/a0 Emask 0x3 (HSM violation) ata2.00: status: {ERR} ata2: soft resetting link ata2.01: NODEV after polling detection ata2.00: configured for MWDMA2 ata2: EH complete VFS: busy inodes on changed media or resized disk sr0 ... <large amounts of VFS and squashfs errors follow>
Created attachment 345509 [details] anaconda.log tail of anaconda.log. Can't actually get it off the box due to no CD filesystem.
Created attachment 345510 [details] storage.log
Created attachment 345511 [details] program.log
In text mode, you still get the reboot button (which may happen to work, due to the paged-in-ness of the installer). In GUI mode, you'll see the hang because the install exits abnormally when X SIGBUSes after the CD error.
Bouncing back to KVM for now. Could also be kernel.
Of note, in the host dmesg: kvm: 2788: cpu0 unhandled wrmsr: 0xc0010117 data 0 kvm: 2788: cpu0 unhandled rdmsr: 0xc0010117 kvm: 2788: cpu0 unhandled rdmsr: 0xc0010117
While it occurs about the time the bootloader is installed, it's reproducible on installs where 'no bootloader' is selected.
Looking at the anaconda log, bad things happen around/near step 'methodcomplete': def doMethodComplete(anaconda): def _ejectDevice(): # Ejecting the CD/DVD for kickstart is handled only after %post scripts # have been run. if anaconda.isKickstart: return None if anaconda.mediaDevice: return anaconda.id.storage.devicetree.getDeviceByName(anaconda.mediaDevice) # If we booted off the boot.iso instead of disc 1, eject that as well. if anaconda.stage2 and anaconda.stage2.startswith("cdrom://"): dev = anaconda.stage2[8:].split(':')[0] return anaconda.id.storage.devicetree.getDeviceByName(dev) anaconda.backend.complete(anaconda) dev = _ejectDevice() if dev: dev.eject() So, somewhere in the kernel, or the virtual CD emulation, we're not returning -EBUSY on eject?
Confirmed - just running 'eject /dev/sr0' from tty2 triggers it.
On a 'normal' DVD based install, the ioctl to eject returns EIO. On a virt DVD based install, it succeeds and 'ejects' the device, causing mayhem. So it does appear qemu/kvm is at fault somehow.
Given that this also occurs when installing on a F10 host, this looks to be a longstanding qemu/kvm issue. Removing from the blocker list.
Created attachment 345550 [details] qemu screenshot I played around with an F10 netinst image I had around and was able to go to the shell during install and eject the CD. Attached screenshot shows the block device info from the qemu console before and after running the eject command.
Wonder if this is a result of interactions in QEMU's IDE CDROM emulation for eject/tray locking. QEMU appears to support the IDE commands for 'eject' and 'lock tray', but the implementation of the 'eject' method doesn't appear to check if the tray is marked as locked. Perhaps anaconda is relying on the eject command failing if the tray is locked ?
Created attachment 345586 [details] prevent-cdrom-media-eject-while-device-is-locked.patch Thanks for tracking this down Bill danpb: yeah, that's it - I've already posted a patch to qemu-devel and it fixes the problem
http://lists.gnu.org/archive/html/qemu-devel/2009-05/msg01324.html
*** Bug 499740 has been marked as a duplicate of this bug. ***
No response from upstream yet, going ahead and build this with the fix: * Wed Jun 3 2009 Mark McLoughlin <markmc> - 2:0.10.5-2 - Prevent locked cdrom eject - fixes hang at end of anaconda installs (#501412) - Fix crash with '-net socket,listen=...' (#501264) - Avoid harmless 'unhandled wrmsr' warnings (#499712)
qemu-0.10.5-2.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/qemu-0.10.5-2.fc11
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
*** Bug 505577 has been marked as a duplicate of this bug. ***
qemu-0.10.5-2.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
For reference, this patch did get applied upstream: http://git.kernel.org/?p=virt/kvm/qemu-kvm.git;a=commitdiff;h=aea2a33c73
*** Bug 505840 has been marked as a duplicate of this bug. ***
I am experiencing the same problem installing Fedora 11 64-bit onto VMware Workstation 6.5. I am using Fedora 11 obtained using Fedora-11-x86_64-DVD.torrent dated 2009-06-09. Does this version have the fix or is another version going to be released? When will the fixed version be available?