Created attachment 810739 [details] screenshot of fedora boot menu under qemu after forced restart Description of problem: I installed a F20 test machine following test day instructions: https://fedoraproject.org/wiki/QA:Testcase_Virtualization_URL_Guest_Install, virt-install part. development/20/x86_64/os/ When the virtual machine is started, virt-manager uses the following command-line: /usr/bin/qemu-system-x86_64 -machine accel=kvm -name test-day-vm -S -machine pc-i440fx-1.6,accel=kvm,usb=off -m 2048 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid ab8a6f57-e12d-48a7-ad60-cc82189b8f14 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/test-day-vm.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -no-kvm-pit-reinjection -no-hpet -no-shutdown -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x4.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x4 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x4.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x4.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/var/lib/libvirt/images/test-day-vm.img,if=none,id=drive-virtio-disk0,format=raw -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:e4:71:da,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0 -spice port=5901,addr=127.0.0.1,disable-ticketing,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 If I restart the VM (by selecting Virtual machine → Shutdown → Force reset), it looks in the grub prompt like in the attached screenshot. When I press keys, parts of the screen get cleared. Looks like some part of memory is not initialized properly. I have never seen grub garble the screen in *this* way (and I have seen it garble the screen more often than not :)), so I'm assuming that this is somehow connected to spice/qemu. Version-Release number of selected component (if applicable): qemu-1.6.0-9.fc20.x86_64 spice-gtk3-0.21-3.fc20.x86_64 spice-server-0.12.4-2.fc20.x86_64 How reproducible: ~20% of forced restarts. Steps to Reproduce: 1. boot vm 2. wait until it gets to gdm prompt 3. select shutdown → power off 4. wait for the machine to hang during poweroff 5. select Virtual machine → Shutdown → Force reset from the qemu menu
Created attachment 818077 [details] Busted screenshot Here's mine, safe reproducer as Comment #0. The grey in that image is the grey from F20 gdm: not sure if this is qemu, guest, spice, or client issue. Ccing some folks that might be able to answer
(In reply to Cole Robinson from comment #1) > Created attachment 818077 [details] > Busted screenshot > > Here's mine, safe reproducer as Comment #0. The grey in that image is the > grey from F20 gdm: not sure if this is qemu, guest, spice, or client issue. > Ccing some folks that might be able to answer Actually CCing
Looks pretty much like the video memory wasn't cleared after setting the video mode. I'll bet on a guest bug. Does F19 show this too? How does grub2.conf (of the installed guest) look like?
(In reply to Gerd Hoffmann from comment #3) > Looks pretty much like the video memory wasn't cleared after setting the > video mode. I'll bet on a guest bug. Yeah, the question is who should clear it. > Does F19 show this too? Yes, seems to be identical (screenshot attached). > How does grub2.conf (of the installed guest) look like? I didn't do any configuration whatsoever, so this is standard from anaconda. Attached.
Created attachment 819196 [details] garbled boot screen with F19 guest after forced reset
Created attachment 819197 [details] grub2 configuration from F20 guest
Hmm, grub2 runs in *text mode* by default.(In reply to Zbigniew Jędrzejewski-Szmek from comment #4) > (In reply to Gerd Hoffmann from comment #3) > > Looks pretty much like the video memory wasn't cleared after setting the > > video mode. I'll bet on a guest bug. > Yeah, the question is who should clear it. Hmm, grub2 uses no graphic mode by default (cfg file confirms this), so it is *text mode* looking this way. Strange. And it makes a guest bug rather unlikely. > > Does F19 show this too? > Yes, seems to be identical (screenshot attached). Tried F19 guest, doesn't reproduce for me :-( Havn't a F20 host at hand, compiled qemu 1.6.0 from git. How did you create the snapshot? Using the gnome snapshot utility? Or using virt-manager/guest-window/virtualmachine/take-snapshot? Any change when using vnc instead of spice? Any change when using stdvga instead of qxl?
(In reply to Gerd Hoffmann from comment #7) > Hmm, grub2 runs in *text mode* by default.(In reply to Zbigniew > Jędrzejewski-Szmek from comment #4) > > (In reply to Gerd Hoffmann from comment #3) > > > Looks pretty much like the video memory wasn't cleared after setting the > > > video mode. I'll bet on a guest bug. > > Yeah, the question is who should clear it. > > Hmm, grub2 uses no graphic mode by default (cfg file confirms this), > so it is *text mode* looking this way. Strange. And it makes a guest > bug rather unlikely. > > > > Does F19 show this too? > > Yes, seems to be identical (screenshot attached). > > Tried F19 guest, doesn't reproduce for me :-( > Havn't a F20 host at hand, compiled qemu 1.6.0 from git. > > How did you create the snapshot? Using the gnome snapshot utility? Or > using virt-manager/guest-window/virtualmachine/take-snapshot? The first one, using gimp. The second one from guest-window/take-snapshot. > Any change when using vnc instead of spice? With "Display Spice" removed, and "Display VNC" added, I cannot reproduce this (5 or 6 tries). (Before I wrote that reproducibility is 30%, but actually, at least now, it is very close to 100%. In some cases there's just a bit of color noise in one of the corners, but it's clear that there's something random. With VNC, the grub prompt is always clean black.) > Any change when using stdvga instead of qxl? With "Video QXL" changed to "Video VGA, 9MB", and display back at "Display Spice", the corruption seems to be less visible but it's there, often just in the corner, but sometimes full-screen.
> > How did you create the snapshot? Using the gnome snapshot utility? Or > > using virt-manager/guest-window/virtualmachine/take-snapshot? > The first one, using gimp. The second one from guest-window/take-snapshot. Cole? How is take-screenshot implemented? Write out window content? Or go through libvirt and ask qemu to write out a screendump that way?
> > Any change when using vnc instead of spice? > With "Display Spice" removed, and "Display VNC" added, I cannot reproduce > this (5 or 6 tries). > > (Before I wrote that reproducibility is 30%, but actually, at least now, it > is very close to 100%. In some cases there's just a bit of color noise in > one of the corners, but it's clear that there's something random. With VNC, > the grub prompt is always clean black.) > > > Any change when using stdvga instead of qxl? > With "Video QXL" changed to "Video VGA, 9MB", and display back at "Display > Spice", the corruption seems to be less visible but it's there, often just > in the corner, but sometimes full-screen. Thanks. That strongly hints the problem is somewhere in spice. What happens if you close and re-open the guest window while grub2 is running? Corruption still visible after reopening?
(In reply to Gerd Hoffmann from comment #9) > > > How did you create the snapshot? Using the gnome snapshot utility? Or > > > using virt-manager/guest-window/virtualmachine/take-snapshot? > > The first one, using gimp. The second one from guest-window/take-snapshot. > > Cole? How is take-screenshot implemented? Write out window content? Or go > through libvirt and ask qemu to write out a screendump that way? It's not through qemu, just grabbing the window content from gtk. I can confirm at least that my screenshot matched what I was seeing on the screen at the time.
(In reply to Gerd Hoffmann from comment #10) > What happens if you close and re-open the guest window while grub2 is > running? Corruption still visible after reopening? Nope, nice and clean in the reopened window.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #12) > (In reply to Gerd Hoffmann from comment #10) > > What happens if you close and re-open the guest window while grub2 is > > running? Corruption still visible after reopening? > Nope, nice and clean in the reopened window. So it is a spice client issue most likely. Reassigning to spice-gtk.
this is probably fixed by http://cgit.freedesktop.org/spice/spice-gtk/commit/?id=32b123f44fc79eaad388d6be09f103457f35d734 Could you try the git version? thanks
I verified that the issue is fixed using spice-gtk git, thanks Marc-Andre !
*** Bug 1029390 has been marked as a duplicate of this bug. ***
*** Bug 1031232 has been marked as a duplicate of this bug. ***
spice-gtk-0.21-5.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/spice-gtk-0.21-5.fc20
Package spice-gtk-0.21-5.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing spice-gtk-0.21-5.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-21630/spice-gtk-0.21-5.fc20 then log in and leave karma (feedback).
spice-gtk-0.21-5.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.