Description of problem: Attempting to start an xpra server on F22 will fail. A simple "xpra start :100" leaves you with no server running and a log file that contains: /usr/libexec/Xorg.wrap: Only console users are allowed to run the X server 2015-05-25 11:12:34,605 2015-05-25 11:12:34,605 Xvfb command has terminated! xpra cannot continue 2015-05-25 11:12:34,605 2015-05-25 11:12:34,606 removing socket /home/tom/.xpra/bericote.compton.nu-100 I'm not quite what is running Xorg.wrap though, as that is the real X server and xpra should be running Xvfb surely (indeed it implies it is) and I can certainly run Xvfb by hand the command "Xvfb :1 -screen 1 1600x1200x16" works fine. Version-Release number of selected component (if applicable): xpra-0.14.22-4.fc22.x86_64
Setting the xvfb command to the default from the manual page: --xvfb='Xvfb +extension Composite -screen 0 3840x2560x24+32 -nolisten tcp -noreset -auth $XAUTHORITY' makes things work, so it looks like xpra has been configured with a different default that is trying to run the real X server?
The wrapper script by default starts the Xdummy server rather than xvfb. Can you confirm xdummy iis installed?
Well I don't have an Xdummy executable and as far as I can see there isn't one (or at least no package provides /usr/bin/Xdummy) but I do have xorg-x11-drv-dummy.x86_64 installed which provides /usr/lib64/xorg/modules/drivers/dummy_drv.so.
OK, so /usr/libexec/Xorg.bin no longer exists, so the F21 workaround in /usr/bin/xpra_Xdummy fails and it tries to start Xorg.
I think /usr/libexec/Xorg is now the name of the "real" server that Xorg.wrap execs into, but changing /usr/bin/xpra_Xdummy to use that fails with: (++) Log file: "/home/tom/.xpra/Xorg.:100.log", Time: Mon May 25 12:30:08 2015 (++) Using config file: "/etc/xpra/xorg.conf" (==) Using config directory: "/etc/X11/xorg.conf.d" (==) Using system config directory "/usr/share/X11/xorg.conf.d" (EE) Fatal server error: (EE) parse_vt_settings: Cannot open /dev/tty0 (No such file or directory) (EE) (EE)
OK, thanks for the extra info. I don't have access to an F22 box right now, but this logic in the Xpra_wrapper script should be doing the right thing: if [ -x "/usr/libexec/Xorg.bin" ]; then #Fedora 21+ workaround where /usr/bin/Xorg is not suid #because it is a script, which calls /usr/libexec/Xorg.wrap #which is setuid, and which eventually calls this one: XORG_BIN="/usr/libexec/Xorg.bin" else XORG_BIN=$(which Xorg) fi which I think on F22 should actually translate to XORG_BIN being set to /usr/lib/Xorg (rather than the libexec binary that you found). I wonder why it's not. What's the output of "which Xorg"? I'll have an F22 machine availabloe in the next day or two to look at this myself.
Exactly, on F22 XORG_BIN gets set to /usr/bin/Xorg (bin, not lib) which is just a shell script that execs /usr/libexec/Xorg.wrap which is then supposed to exec /usr/libexec/Xorg after doing it's stuff (instead of /usr/libexec/Xorg.bin in F21). The problem, even after fixing Xpra_wrapper to recognise the F22 path, is that the X server still won't start because it tries to fiddle with a vt even though it is being started a a dummy server.
Right, gottit! I think I have a fix, I'll push a test build shortly.
OK, my fix didn't work. Will continue to look at it. In the meantime, have reported upstream too: https://www.xpra.org/trac/ticket/872
BZ #1203780 seems to be relevant here, though it's claimed that is fixed.
Tom - can you confirm you're running xorg-x11-server-1.17.1-12 ? (or later).
Adding Hans de Goede to cc list. Hi Hans, the issue with Xorg failing to start with the Xdummy driver (which is wwhat Xpra invokes) seems to be failing on F22 - see comment #5. This looks like BZ #1203780 again, and is a regression fro F21. Any pointers?
No I only have -11 at the moment by the looks of it. Looking at bodhi -12 only got pushed into stable last night when the first post-freeze updates push was done. I'll grab that update this evening and hopefully that will fix it - it certainly looks like it should (along with a fix to the Xpra wrapper script of course).
OK, great. I've just put a patch on the upstream BZ to fix the wrapper script, which I'll include in a subsequent package build.
This build should fix the script issue: http://koji.fedoraproject.org/koji/taskinfo?taskID=9852263
xpra-0.14.22-5.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/xpra-0.14.22-5.fc22
I can confirm that the combination of the -12 X server and the new xpra build fixes this.
Great thanks. Could you add karma on bodhi so the update can hit the stable updates asap, then I'll get on with updating to 0.14.24.
Package xpra-0.14.22-5.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing xpra-0.14.22-5.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-8975/xpra-0.14.22-5.fc22 then log in and leave karma (feedback).
xpra-0.14.22-5.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.