GNOME Bugzilla – Bug 763960
screen flicker at GDM, mouse click erratic response, black login screen
Last modified: 2018-01-11 10:42:28 UTC
Created attachment 324391 [details] journal of F24 alpha6 in Boxes (guest) Host: virt-manager-1.3.2-1.fc23.noarch libvirt-daemon-1.2.18.2-2.fc23.x86_64 gnome-boxes-3.18.1-1.fc23.x86_64 Problem happens in Boxes with Fedora-Workstation-Live-x86_64-24_Alpha-6.iso but does not happen with Alpha 5. Nor does it happen with either Alpha 5 or Alpha 6 in virt-manager. At flickering gdm screen, I keep getting a lot of these entries: Mar 20 16:03:57 localhost.localdomain gnome-settings-daemon.desktop[1560]: (gnome-settings-daemon:1560): color-plugin-WARNING **: unable to get EDID for xrandr-Virtual23: unable to get EDID for output Mar 20 16:03:58 localhost.localdomain gnome-settings-daemon.desktop[1560]: (gnome-settings-daemon:1560): color-plugin-WARNING **: unable to get EDID for xrandr-Virtual23: unable to get EDID for output Mar 20 16:03:59 localhost.localdomain gnome-settings-daemon.desktop[1560]: (gnome-settings-daemon:1560): color-plugin-WARNING **: unable to get EDID for xrandr-Virtual23: unable to get EDID for output Mar 20 16:04:00 localhost.localdomain kernel: qxl 0000:00:02.0: ffff88007a3d0800 unpin not necessary Mar 20 16:04:00 localhost.localdomain gnome-settings-daemon.desktop[1560]: (gnome-settings-daemon:1560): color-plugin-WARNING **: unable to get EDID for xrandr-Virtual23: unable to get EDID for output Mar 20 16:04:01 localhost.localdomain gnome-settings-daemon.desktop[1560]: (gnome-settings-daemon:1560): color-plugin-WARNING **: unable to get EDID for xrandr-Virtual23: unable to get EDID for output Mar 20 16:04:02 localhost.localdomain gnome-settings-daemon.desktop[1560]: (gnome-settings-daemon:1560): color-plugin-WARNING **: unable to get EDID for xrandr-Virtual23: unable to get EDID for output Mar 20 16:04:03 localhost.localdomain gnome-settings-daemon.desktop[1560]: (gnome-settings-daemon:1560): color-plugin-WARNING **: unable to get EDID for xrandr-Virtual23: unable to get EDID for output Mar 20 16:04:04 localhost.localdomain gnome-settings-daemon.desktop[1560]: (gnome-settings-daemon:1560): color-plugin-WARNING **: unable to get EDID for xrandr-Virtual23: unable to get EDID for output Once logging in, there are a lot of messages so I'll just include the entire journal for this boot as an attachment. Loging attempt starts at monotonic time 129.
Created attachment 324392 [details] journal of F24 alpha6 in virt-manager (guest) This is the same qcow2 file that's used by gnome-boxes.
Link for the ISO. Further note, the live environment itself does not exhibit this problem. Only once installed and rebooted is the problem apparent. And it still happens even if enforcing=0 is used to boot the post-install system. Pretty weird. https://kojipkgs.fedoraproject.org/compose/24/Fedora-24-20160319.1/compose/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-24_Alpha-6.iso
(In reply to Chris Murphy from comment #0) > Created attachment 324391 [details] > journal of F24 alpha6 in Boxes (guest) > > Host: > virt-manager-1.3.2-1.fc23.noarch > libvirt-daemon-1.2.18.2-2.fc23.x86_64 > gnome-boxes-3.18.1-1.fc23.x86_64 > > > Problem happens in Boxes with Fedora-Workstation-Live-x86_64-24_Alpha-6.iso > but does not happen with Alpha 5. Nor does it happen with either Alpha 5 or > Alpha 6 in virt-manager. Is it possible that in virt-manager (nor you) didn't choose QXL for video card?
Boxes config: <video> <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video> virt-manager config: <video> <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video>
http://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/message/WFJWRSFLRNCOHM5PSAONBHJFMWUFD6SH/ It happens even with enforcing=0 so I don't think it's selinux related. It might be worth waiting for another compose and see if this reproduces; but if it doesn't that is also concerning, just for different reasons.
Hm.. then it's not QXL. Still unlikely to be a Boxes bug but will need to check what's to blame.
Actually if you are up for it, could you please shutdown the VM, remove the USB mouse from the configuration XML and try reproducing again?
Quit Boxes # virsh edit boxes-unknown Then deleted this line: <input type='mouse' bus='ps2'/> :wq Launch Boxes, then click on the VM. Same behavior. (And it doesn't respond to choosing ctrl+alt+f2 in the keyboard icon popdown; same as before.) Oops just now I get a partial draw of g-i-s. I'll take a screen shot of what I'm seeing.
(In reply to Chris Murphy from comment #8) > Quit Boxes Just to be sure, you did ensure box was shutdown and not in saved state?
Created attachment 324495 [details] screenshot after login First thing is the time is off-centered; so there's some disconnect between the VM's display device resolution and what the guest OS thinks that display resolution is? And then a few seconds later while clicking around, the g-i-s portion shows up. If I wait long enough for the display "sleep" timeout to be reached, I'll see a partial lock screen with just the time floating on a mostly black background
And just to note the due diligence, the sha256 of the downloaded ISO matches what's published. And I've done the installation multiple times (defaults). It's very odd booting the live OS itself doesn't have this behavior, but the installed version does (which is just rsync'd from the live's own files, it's not like it's a separate set of packages being installed). Yet either installing it in virt-manager doesn't reproduce; nor does using the Boxes qcow2 with virt-manager.
(In reply to Zeeshan Ali (Khattak) from comment #9) > (In reply to Chris Murphy from comment #8) > > Quit Boxes > > Just to be sure, you did ensure box was shutdown and not in saved state? Not totally sure because I don't know how to put it in a saved state? To shutdown the VM I'm connecting to the guest with ssh and then issuing 'poweroff' command. The other very odd thing that seems unrelated is Alpha 6 in Boxes changes the volume of the host to maximum upon booting the guest. This also doesn't happen in virt-manager, and doesn't happen with Alpha 5.
(In reply to Chris Murphy from comment #12) > (In reply to Zeeshan Ali (Khattak) from comment #9) > > (In reply to Chris Murphy from comment #8) > > > Quit Boxes > > > > Just to be sure, you did ensure box was shutdown and not in saved state? > > Not totally sure because I don't know how to put it in a saved state? By exitting the UI while VM is running or through the option in the context menu or selection mode. > To > shutdown the VM I'm connecting to the guest with ssh and then issuing > 'poweroff' command. If you did shut it down before exiting Boxes, it was then in shutdown state sine Boxes won't and can't save shutdown VMs. > The other very odd thing that seems unrelated is Alpha 6 in Boxes changes > the volume of the host to maximum upon booting the guest. Not sure what that means. Guest allocates all the capacity of the volume or volume capacity somehow is set to max available?
FYI: <input type='tablet' bus='usb'/> <input type='mouse' bus='usb'/> <input type='keyboard' bus='usb'/> <input type='mouse' bus='ps2'/> <input type='keyboard' bus='ps2'/> If I delete both mouses and both keyboards, then use virsh edit again, these two are still there: <input type='mouse' bus='ps2'/> <input type='keyboard' bus='ps2'/> So I guess I deleted the wrong one before, but it doesn't matter, the behavior is the same.
(In reply to Zeeshan Ali (Khattak) from comment #13) > By exitting the UI while VM is running or through the option in the context > menu or selection mode. No I'm not doing that. I use ssh to poweroff because there's no functioning UI to do a clean shutdown. > > The other very odd thing that seems unrelated is Alpha 6 in Boxes changes > > the volume of the host to maximum upon booting the guest. > > Not sure what that means. Guest allocates all the capacity of the volume or > volume capacity somehow is set to max available? 1. Boxes is not running 2. On host, turn volume down to minimum using keyboard volume key. 3. Launch Boxes, click on Alpha 6 VM. 4. While VM boots, click on Terminal or any other host application, and check volume is still minimal. 5. Once VM is at GDM, and in Terminal/Gedit whatever (but not Boxes), click on volume key, it's now at maximum setting. So the guest via Boxes is definitely changing the host's volume. Maybe it's a separate bug...
(In reply to Chris Murphy from comment #14) > FYI: > <input type='tablet' bus='usb'/> > <input type='mouse' bus='usb'/> > <input type='keyboard' bus='usb'/> > <input type='mouse' bus='ps2'/> > <input type='keyboard' bus='ps2'/> > > If I delete both mouses and both keyboards, then use virsh edit again, these > two are still there: > > <input type='mouse' bus='ps2'/> > <input type='keyboard' bus='ps2'/> Yeah, that is exactly what I was expecting to happen. (In reply to Chris Murphy from comment #15) > (In reply to Zeeshan Ali (Khattak) from comment #13) > > > By exitting the UI while VM is running or through the option in the context > > menu or selection mode. > > No I'm not doing that. I use ssh to poweroff because there's no functioning > UI to do a clean shutdown. We'll be adding a "Restart" button at least. Might add a shutdown button too or just replace 'Force shutdown' with 'Shutdown'. > > > The other very odd thing that seems unrelated is Alpha 6 in Boxes changes > > > the volume of the host to maximum upon booting the guest. > > > > Not sure what that means. Guest allocates all the capacity of the volume or > > volume capacity somehow is set to max available? > > 1. Boxes is not running > 2. On host, turn volume down to minimum using keyboard volume key. > 3. Launch Boxes, click on Alpha 6 VM. > 4. While VM boots, click on Terminal or any other host application, and > check volume is still minimal. > 5. Once VM is at GDM, and in Terminal/Gedit whatever (but not Boxes), click > on volume key, it's now at maximum setting. > > So the guest via Boxes is definitely changing the host's volume. Maybe it's > a separate bug... Ah you were talking about sound volume, I thought you were talking about storage volume. :) Yes, please file a bug. Although Boxes isn't doing anything with volume but maybe Boxes needs to save the settings for SPICE.
Problem still happens with Fedora-Workstation-Live-x86_64-24_Alpha-7.iso, which is the release version. So hopefully someone else will hit this and we'll figure out what's going on, it's not a one off.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-boxes/issues/92.