Bug 1031665
| Summary: | Cannot start vino on the remote server | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Matěj Cepl <mcepl> | ||||||
| Component: | vino | Assignee: | Søren Sandmann Pedersen <sandmann> | ||||||
| Status: | CLOSED WONTFIX | QA Contact: | Desktop QE <desktop-qa-list> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 7.0 | CC: | ajax, kem, mcepl, rstrode | ||||||
| Target Milestone: | rc | Keywords: | TestBlocker, Triaged | ||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | [cat:modesetting] | ||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2013-11-22 00:00:38 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Matěj Cepl
2013-11-18 13:43:47 UTC
So aside from missing installation of group "X Window System" we have a bug somewhere in Xorg. See attached Xorg logs. Created attachment 825735 [details]
/var/log/Xorg.1.log
Created attachment 825736 [details]
all /var/log/Xorg* and /var/log/gdm logs
Installed: [root@localhost ~]# rpm -qa xorg\* xorg-x11-drv-qxl-0.1.1-5.el7.x86_64 xorg-x11-drv-nouveau-1.0.10-3.el7.x86_64 xorg-x11-glamor-0.5.1-3.20131023git16c86bd.el7.x86_64 xorg-x11-drv-wacom-0.23.0-3.el7.x86_64 xorg-x11-font-utils-7.5-17.el7.x86_64 xorg-x11-xinit-1.3.2-8.el7.x86_64 xorg-x11-drv-ati-7.2.0-6.20131023gitf1dc677.el7.x86_64 xorg-x11-drv-evdev-2.8.2-3.el7.x86_64 xorg-x11-drv-vmmouse-13.0.0-8.el7.x86_64 xorg-x11-drv-vmware-13.0.1-5.el7.x86_64 xorg-x11-drivers-7.7-5.el7.x86_64 xorg-x11-xauth-1.0.7-3.el7.x86_64 xorg-x11-server-utils-7.7-2.el7.x86_64 xorg-x11-xkb-utils-7.7-8.el7.x86_64 xorg-x11-server-common-1.14.99.901-5.20131101.el7.x86_64 xorg-x11-drv-vesa-2.3.2-12.el7.x86_64 xorg-x11-drv-fbdev-0.4.3-12.el7.x86_64 xorg-x11-drv-modesetting-0.8.0-6.el7.x86_64 xorg-x11-drv-synaptics-1.7.1-7.el7.x86_64 xorg-x11-drv-intel-2.21.15-9.el7.x86_64 xorg-x11-server-Xorg-1.14.99.901-5.20131101.el7.x86_64 xorg-x11-drv-v4l-0.2.0-33.el7.x86_64 xorg-x11-drv-dummy-0.3.6-13.el7.x86_64 xorg-x11-drv-void-1.4.0-21.el7.x86_64 xorg-x11-utils-7.5-9.el7.x86_64 [root@localhost ~]# Attachment 825735 [details] shows X failing to start when we have fbdev but not modesetting installed, which is unfortunate. But it can't be the cause of vino not working, because comment #0 shows the vino server starting and then crashing, which means X _has_ to be running - and indeed, Xorg.0.log from attachment 825736 [details] shows X running. Assuming nothing special about the guest, major opcode 130 typically means MIT-SHM in current RHEL7, and minor code 5 for that is the ShmCreatePixmap request. There's a couple of ways that could throw BadAccess: - if the X server doesn't have write permission to the shm segment but the request asked for it - if the size+offset in the request extends beyond the end of the shm segment - if XACE security policy prevents it We can probably exclude the third option since we don't have an XACE policy by default. My hunch is that it's the second one, since this setup is using the cirrus device, which can only do 24bpp not 32bpp, so it's likely that vino is miscomputing the shm segment size. (If permissions were wrong vino just wouldn't work at all on any device, so that seems unlikely.) Reassigning to vino on that basis. Matěj, can reproduce this problem on other guest video devices (vga, qxl, or vmware)? If you can't then this probably shouldn't be considered a test blocker. FWIW, I don't think you want to run vino-server from a connect that has X11 forwarding enabled with ssh -Y. If you do that, you really need to set DISPLAY to the session you're trying to share. when you ssh -Y, DISPLAY is going to be set to the DISPLAY you're sshing *from*, which you almost certainly don't want to do. Furthermore, i don't think SHM works over SSH tunneled X, so that's probably why it's failing. Chatted with Matej abou this. He didn't mean to use ssh -Y and there were some other missing bits in his installation. I'm going to go ahead and close this out, since I don't think the cosmetic problems are worth prioritizing time for. |