Created attachment 748368 [details] screenshot of the stuck VM Er, well, this is embarrassing. I have an up-to-date F19 desktop. I ran Boxes, chose to create a new machine. Chose Fedora-19-Beta-TC4-x86_64-DVD.iso as the install source, and accepted Express configuration. Everything looked okay, so I went ahead and hit Create. The VM showed up, as 'installing', in the interface. I clicked on it, and it seems when you do that, you get the 'box' in full screen. Well, it's there, and it's indefinitely stuck early in the kernel: screenshot attached. Here's the embarrassing part - I've no idea what to do. I don't know how to get out of the fullscreen mode and back to the main UI, even: it doesn't appear to be in the Boxes Help pages at all. The VM doesn't show up in virt-manager, so I can't look at it from there. I can see the qemu-kvm command in ps, it's pasted below. But I'm damned if I know what else to do now. adamw 29794 19.4 1.8 2386288 300628 ? Sl 08:04 0:14 /usr/bin/qemu-system-x86_64 -machine accel=kvm -name fedora19 -S -machine pc-i440fx-1.4,accel=kvm,usb=off -cpu Westmere,+rdtscp,+avx,+osxsave,+xsave,+tsc-deadline,+pcid,+pdcm,+xtpr,+tm2,+est,+vmx,+ds_cpl,+monitor,+dtes64,+pclmuldq,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -m 1152 -smp 8,sockets=1,cores=4,threads=2 -uuid c0c5b0e1-ac9d-4a7a-9d81-44b0904cb8be -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/home/adamw/.config/libvirt/qemu/lib/fedora19.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -no-kvm-pit-reinjection -no-reboot -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -kernel /home/adamw/.cache/gnome-boxes/fedora19-kernel -initrd /home/adamw/.cache/gnome-boxes/fedora19-initrd -append ks=hd:sda:/fedora.ks -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -device usb-ccid,id=ccid0 -drive file=/home/adamw/.local/share/gnome-boxes/images/fedora19,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=2 -drive file=/share/data/isos/19/Beta-TC4/Fedora-19-Beta-TC4-x86_64-DVD.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=1 -drive file=/home/adamw/.cache/gnome-boxes/fedora19-unattended.img,if=none,id=drive-usb-disk0,format=raw -device usb-storage,drive=drive-usb-disk0,id=usb-disk0 -netdev user,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:70:a4:6b,bus=pci.0,addr=0x3 -chardev spicevmc,id=charsmartcard0,name=smartcard -device ccid-card-passthru,chardev=charsmartcard0,id=smartcard0,bus=ccid0.0 -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,image-compression=off,seamless-migration=on -vga qxl -global qxl-vga.ram_size=67108864 -global qxl-vga.vram_size=67108864 -device AC97,id=sound0,bus=pci.0,addr=0x4 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1 -chardev spicevmc,id=charredir2,name=usbredir -device usb-redir,chardev=charredir2,id=redir2 -chardev spicevmc,id=charredir3,name=usbredir -device usb-redir,chardev=charredir3,id=redir3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8
(In reply to comment #0) > Created attachment 748368 [details] > screenshot of the stuck VM > > Er, well, this is embarrassing. > > I have an up-to-date F19 desktop. I ran Boxes, chose to create a new > machine. Chose Fedora-19-Beta-TC4-x86_64-DVD.iso as the install source, and > accepted Express configuration. Everything looked okay, so I went ahead and > hit Create. > > The VM showed up, as 'installing', in the interface. I clicked on it, and it > seems when you do that, you get the 'box' in full screen. > > Well, it's there, and it's indefinitely stuck early in the kernel: > screenshot attached. > > Here's the embarrassing part - I've no idea what to do. I don't know how to > get out of the fullscreen mode and back to the main UI, Yeah, we should show the topbar for a few seconds when going to fullscreen that tells you want to do to ungrab the mouse. The shortcut to ungrab is CTRL+ALT. If you could file a bug upstream about this, that would be nice: https://bugzilla.gnome.org/enter_bug.cgi?product=gnome-boxes > even: it doesn't > appear to be in the Boxes Help pages at all. Blame or help the gnome docs team. :) > The VM doesn't show up in > virt-manager, so I can't look at it from there. That is not exactly our fault or we can do anything about it. I don't know why virt-manager decided to install VMs in a shared location by default. Maybe they had/have some reasons but Boxes keeps users' VMs private. Having said that, you can add a 'qemu+unix:///session' connection to virt-manager and Boxes' VMs will appear there as well then.
(In reply to comment #0) > Created attachment 748368 [details] > screenshot of the stuck VM > > Er, well, this is embarrassing. > > I have an up-to-date F19 desktop. I ran Boxes, chose to create a new > machine. Chose Fedora-19-Beta-TC4-x86_64-DVD.iso as the install source, and > accepted Express configuration. Everything looked okay, so I went ahead and > hit Create. > > The VM showed up, as 'installing', in the interface. I clicked on it, and it > seems when you do that, you get the 'box' in full screen. > > Well, it's there, and it's indefinitely stuck early in the kernel: > screenshot attached. I wasn't able to reproduce exactly that. Instead I end up at a black screen (AFAICT the X server fails to start successfully). However, if i replace 'qxl' video device in the libvirt XML configuration by 'sdl', everything works like a charm after that. So I'm pretty sure that at least the bug I'm seeing is either in qemu's QXL or QXL X driver.
(In reply to comment #2) > (In reply to comment #0) > > Created attachment 748368 [details] > > screenshot of the stuck VM > > > > Er, well, this is embarrassing. > > > > I have an up-to-date F19 desktop. I ran Boxes, chose to create a new > > machine. Chose Fedora-19-Beta-TC4-x86_64-DVD.iso as the install source, and > > accepted Express configuration. Everything looked okay, so I went ahead and > > hit Create. > > > > The VM showed up, as 'installing', in the interface. I clicked on it, and it > > seems when you do that, you get the 'box' in full screen. > > > > Well, it's there, and it's indefinitely stuck early in the kernel: > > screenshot attached. > > I wasn't able to reproduce exactly that. Instead I end up at a black screen > (AFAICT the X server fails to start successfully). However, if i replace > 'qxl' video device in the libvirt XML configuration by 'sdl', everything > works like a charm after that. So I'm pretty sure that at least the bug I'm > seeing is either in qemu's QXL or QXL X driver. This one turned out to be a bug in old spice-server in my jhubild environment. Now I face this in both boxes on F19 and jhbuild: https://bugs.freedesktop.org/show_bug.cgi?id=64714
(In reply to Adam Williamson from comment #0) > > Here's the embarrassing part - I've no idea what to do. I don't know how to > get out of the fullscreen mode and back to the main UI, The fix for the embarrassing part has been submitted and hopefully will be in the next stable update: https://bugzilla.gnome.org/show_bug.cgi?id=700574#c19
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 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, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. 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.
this is all pretty old stuff, closing.