[vmwgfx] Gnome Desktop only starting with root rights

[Tim Mueller]

All files in home folder are owned by the user. startx is only working with root rights.

xinit: connection to X server lost/usr/bin/gnome-session: 29: exec:
/usr/libexec/gnome-session-binary: Permission denied

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: xorg 1:7.7+19ubuntu14
ProcVersionSignature: Ubuntu 5.4.0-33.37-generic 5.4.34
Uname: Linux 5.4.0-33-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu27.2
Architecture: amd64
CasperMD5CheckResult: skip
CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
Date: Thu Jun 4 16:25:19 2020
DistUpgraded: 2020-04-26 18:18:02,277 ERROR Cache can not be locked (E:Konnte keinen exklusiven Zugang zur Sperrdatei /var/lib/dpkg/lock erhalten. Diese wird vom Prozess 21979 (dpkg) gehalten., W:Beachten Sie, dass das Entfernen der Sperrdatei keine Lösung ist und Ihr System zerstören kann., E:Sperren des Administrationsverzeichnisses (/var/lib/dpkg/) nicht möglich, wird es von einem anderen Prozess verwendet?)
DistroCodename: focal
DistroVariant: ubuntu
DkmsStatus:
 rapiddisk, 5.2, 5.4.0-31-generic, x86_64: installed
 rapiddisk, 5.2, 5.4.0-33-generic, x86_64: installed
ExtraDebuggingInterest: Yes
GraphicsCard:
 VMware SVGA II Adapter [15ad:0405] (prog-if 00 [VGA controller])
   Subsystem: VMware SVGA II Adapter [15ad:0405]
Lsusb: Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Lsusb-t: /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
MachineType: QEMU Standard PC (i440FX + PIIX, 1996)
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.4.0-33-generic root=UUID=f8fcb1ae-51b1-4ab2-b79d-66cf34ad77d9 ro nomodeset rootflags=subvol=ROOT
SourcePackage: xorg
UpgradeStatus: Upgraded to focal on 2020-04-26 (38 days ago)
dmi.bios.date: 04/01/2014
dmi.bios.vendor: SeaBIOS
dmi.bios.version: rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org
dmi.chassis.type: 1
dmi.chassis.vendor: QEMU
dmi.chassis.version: pc-i440fx-4.1
dmi.modalias: dmi:bvnSeaBIOS:bvrrel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org:bd04/01/2014:svnQEMU:pnStandardPC(i440FX+PIIX,1996):pvrpc-i440fx-4.1:cvnQEMU:ct1:cvrpc-i440fx-4.1:
dmi.product.name: Standard PC (i440FX + PIIX, 1996)
dmi.product.version: pc-i440fx-4.1
dmi.sys.vendor: QEMU
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.101-2
version.libgl1-mesa-dri: libgl1-mesa-dri 20.0.4-2ubuntu1
version.libgl1-mesa-glx: libgl1-mesa-glx 20.0.4-2ubuntu1
version.xserver-xorg-core: xserver-xorg-core 2:1.20.8-2ubuntu2.1
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.6-1
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20200226-1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1

[Daniel van Vugt (vanvugt)]

Can you log in normally from the login screen? Is it only an issue with 'startx'?

[Daniel van Vugt (vanvugt)]

Also please run:

  ls -l /usr/libexec/gnome-session-binary

and tell us what you see.

[Tim Mueller (muellert1)]

Can you log in normally from the login screen? Is it only an issue with 'startx'?

No, if I try to boot directly to GUI the resolution changes several times (I can see that via VNC which is available at boot time for the VPS because the VNC size is changing several times) and then get's stuck. This happens on two different VPS. I have upgraded from 18.04 LTS. But this error is not connected to the update. I also tried to use a fresh install and the result was the same. Which means there is no login screen on both machines.

If it get's stuck the beavior is different on both VPS even if I copy everything except /sys /run /proc (which means the same installation is used) one VPS gets stuck in a purple screen and it is possible to change to command line via Alt+F. The other one ends up in a blueish screen with lines and a blinking cursor but this one is totally stuck. I added two screenshots of that.

Sometimes I see the desktop for a part of a socond between the resolution changes. I also tried to set a fixed resolution but was not sucessfull because the switching is still happening. If I stop the gdm serrvice startx with root is possible afterwards. IT took me a while to realize this because at first I thought I should focus on the GUI boot problem.

I now switched both VPS to multi user target insted of graphical boot. If I use stop service gdm3 and start service gdm3 the result is the same like described above. XRDP combined with remote desktop is also only working via root login.

Also please run:
  ls -l /usr/libexec/gnome-session-binary
ls -l /usr/libexec/gnome-session-binary
-rwxr-xr-x 1 root root 334664 Mar 26 13:22 /usr/libexec/gnome-session-binary

On tests with xrdp I also saw some other errors in syslog which are more detailed as the gnome session permission error which does not seem to be the root cause:
May 27 18:34:59 systemd[587724]: at-spi-dbus-bus.service: Failed to execute command: Permission denied
May 27 18:34:59 systemd[587724]: at-spi-dbus-bus.service: Failed at step EXEC spawning /usr/libexec/at-spi-bus-launcher: Permission denied
May 27 18:34:59 systemd[1678]: at-spi-dbus-bus.service: Main process exited, code=exited, status=203/EXEC

I have seen some oher useers with this kind of problem which switched off at-spi-dbus-bus.service. I tried that and ended up with. That's where I stopped trying and switched at-spi-dbus-bus.service to start agein like before. Which means I'm now on standard settings after upgrade again:

dbus-daemon[642845]: [session uid=0 pid=642843] Activating service name='org.freedesktop.systemd1' requested by ':1.20' (uid=0 pid=642800 comm="/usr/libexec/gnome-session-binary --builtin " label="unconfined")
May 27 19:49:30 dbus-daemon[642845]: [session uid=0 pid=642843] Activated service 'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1 exited with status 1
May 27 19:49:30 org.gtk.vfs.Daemon[642897]: A connection to the bus can't be made
May 27 19:49:30 gnome-control-c[646635]: gnome-control-center-search-provider: Fatal IO error 11 (Die Ressource ist zur Zeit nicht verfügbar) on X server :0.
May 27 19:49:30 seahorse[643522]: seahorse: Fatal IO error 11 (Die Ressource ist zur Zeit nich...

[Tim Mueller (muellert1)]

To be clear - I have not found an edit option:
-stop service gdm3
-start service gdm3
+sudo service gdm3 stop
+sudo service gdm3 start

This will not result in something visible in the VNC. sudo startx does.

[Daniel van Vugt (vanvugt)]

> if I try to boot directly to GUI the resolution changes several times ... and then get's stuck.

That sounds like an interesting separate bug which we might be able to fix or explain. Please open a new bug for that if you can.

> I now switched both VPS to multi user target insted of graphical boot

By chance I am also using multi-user.target right now. But 'startx' works for me.

[Daniel van Vugt (vanvugt)]

BTW, the failing line 29 of script is systemd-related:

if [ -d "${XDG_RUNTIME_DIR}/systemd" ]; then
  exec /usr/libexec/gnome-session-binary --systemd "$@"
else
  exec /usr/libexec/gnome-session-binary --builtin "$@"
fi

So I wonder if you just need to remove ${XDG_RUNTIME_DIR}/systemd ?

[Tim Mueller (muellert1)]

You are using multi user target because you like to or also having some kind of problems?

If I use (which means removing the if else)
exec /usr/libexec/gnome-session-binary --systemd "$@"
the result is the same. Still the same message for missing permission.

And with
exec /usr/libexec/gnome-session-binary --builtin "$@"
the result is identical.

I thought maybe it's good to sort out this error first and if there are no problems without starting GUI without root rights than maybe a second bug report for boot to gui. But I can also open another bug report now. I'm not sure if this bugs / problems are connected in any way or not.

With 18.04 I did not have this kind of errors on both machines. The funny thing is: On my Raspberry Pi 4b it is working from start (ok, this is a special distribution for special hardware so it should run).

[Daniel van Vugt (vanvugt)]

I am using multi-user.target because I am compiling gnome-shell from scratch, for development. So also run it manually.

[Tim Mueller (muellert1)]

Ah, that makes much sense. If you are having problems you could help yourself. ;)

[Launchpad Janitor (janitor)]

[Expired for xorg-server (Ubuntu) because there has been no activity for 60 days.]