Ubuntu Internal error when selecting desktop sharing in settings.

Hi,

I am trying to setup desktop sharing mainly to run the Jetson Nano board via VNC in headless mode without a monitor.
But everytime I select the Desktop Sharing icon in System Settings menu, I get error:
“Sorry, Ubuntu 18.04 has experienced an internal error.”

Is this a known issue with this initial release? If not, can someone please let me know what the issue may be.
Thanks.

1 Like

Just discovered the README-vnc.txt instructions in the L4T-README folder and tried to follow the instructions.
However the command,
“settings set org.gnome.Vino enabled true” returns 'No such key “enabled”.

Any help setting up VNC server on Jeson Nano will be greatly appreciated!

Hi,

I have tried the same on Jetson TX2 with JetPack 4.2 and failed. There seems to be no key named ‘enabled’. You can create that key, but vino-server will still refuse to start. I gave up on that and after one day of head scratching I found an alternative solution:

  1. Install TigerVNC server:
$ sudo apt install tigervnc-standalone-server tigervnc-xorg-extension -y
  1. Set a password for the VNC server:
$ vncpasswd
  1. Create the file “/home/nvidia/.vnc/xstartup” with the following content:
#!/bin/sh
export XDG_RUNTIME_DIR=/run/user/1000
export XKL_XMODMAP_DISABLE=1
unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS

xrdb /home/nvidia/.Xresources
xsetroot -solid grey

gnome-session &
  1. Create the empty file “.Xresources” in your user’s home directory:
$ touch /home/nvidia/.Xresources
  1. Create the file “/etc/systemd/system/vncserver@.service” with the following content:
[Unit]
Description=Start TightVNC server at startup
After=syslog.target network.target

[Service]
Type=forking
User=nvidia
Group=nvidia
WorkingDirectory=/home/nvidia
PIDFile=/home/nvidia/.vnc/%H:%i.pid
ExecStartPre=-/usr/bin/vncserver -kill :%i > /dev/null 2>&1
ExecStart=/usr/bin/vncserver -localhost no -depth 24 -geometry 1280x720 :%i
ExecStop=/usr/bin/vncserver -kill :%i

[Install]
WantedBy=multi-user.target
  1. Make sure the VNC server starts after system boot:
$ sudo systemctl daemon-reload
$ sudo systemctl enable vncserver@1
  1. Configure auto-login with GDM3. Open “/etc/gdm3/custom.conf” and uncomment or change the following lines:
AutomaticLoginEnable=true
AutomaticLogin=nvidia
  1. Reboot the system and try to reach the VNC server at port 5901.

Warning: You have to open GNOME settings immediately and disable the screen saver and screen locking. If the session is locked you cannot enter your password (reasons unknown).

Please report back.

First thing I noticed, nvidia defaults to the ‘old’ ubuntu desktop, which makes the “Desktop Sharing” application crash. When logging in and entering your password, you can click on a settings button and change the desktop to be loaded.

A more simple way (using GUI) is to install dconf-editor (sudo apt install dconf-editor) and use this tool to enable vnc/vino and disable encryption (encryption apparently gives issues with windows connections).

@IceBlackz: Thanks for pointing this out. I tried to change the session to the ‘real’ GNOME 3 desktop (no Unity) and I could finally enable the vino server. It worked great until I disconnected the monitor and rebooted. After the reboot the vino server is brought up again, but after connecting to it I only saw the NVIDIA logo, but no GNOME desktop. It seems that GNOME has issues if Xorg does not provide a proper modeline (this seems to be a major difference compared to JetPack 3.3).

My approach in #2 has the disadvantage of increased memory usage (actually you are running two GNOME sessions in parallel), but it is a way out of this situation. Another solution would be to install the ‘xserver-xorg-video-dummy’ package and run with a dummy session when there is no monitor available.

Can someone from the NVIDIA staff reproduce this issue and maybe offer some xorg.conf tricks?

Thanks guys for the responses.

@klicker100, I too experienced the issue of being able to connect on VNC with desktop in non-unity mode. This works as long as desktop user is logged in and monitor is connected. As soon as desktop user session is disconnected, VNC refuses to connect.

I would like to try your steps in #2 to get VNC to work. Should this be done in “Unity mode” or “Ubuntu mode”? Not really sure what the differences between the two modes are.

Thanks.

@animan9: Please select the “Ubuntu” session at the login screen and log in to this session one time with a monitor attached. You can then try the instructions in #2. Good luck!

The difference between the two options is the “Unity” session being a home grown desktop developed by Canonical (Ubuntu sponsor) based on GNOME, while the “Ubuntu” session is the ‘real’ GNOME 3 shell. Starting from Ubuntu 18.04 Canonical has abandoned their Unity desktop in favor of the GNOME 3 shell.

If you find the memory usage of the solution in #2 as being too high (it adds ~400 MB) you can also try these steps:

  1. Attach a monitor, log into the “Ubuntu” session, go to

Settings -> Sharing -> Screen Sharing -> turn on screen sharing -> set ‘Access Options’ to ‘Require a password’ and set a password

Close all dialogs afterwards.

  1. Install the Xorg dummy:
$ sudo apt install xserver-xorg-video-dummy -y
  1. Modify the file “/etc/X11/xorg.conf” to look like this:
# Copyright (c) 2011-2013 NVIDIA CORPORATION.  All Rights Reserved.

#
# This is the minimal configuration necessary to use the Tegra driver.
# Please refer to the xorg.conf man page for more configuration
# options provided by the X server, including display-related options
# provided by RandR 1.2 and higher.

# Disable extensions not useful on Tegra.
Section "Module"
    Disable     "dri"
    SubSection  "extmod"
        Option  "omit xfree86-dga"
    EndSubSection
EndSection

Section "Device"
    Identifier  "Tegra0"
    Driver      "nvidia"
    # Allow X server to be started even if no display devices are connected.
    Option      "AllowEmptyInitialConfiguration" "true"
    # Suppress an error in Xorg log
    Option      "ConnectToAcpid" "Off"
EndSection

# Dummy for headless mode

Section "Device"
    Identifier  "Dummy0"
    Driver      "dummy"
    VideoRam    16384
EndSection

Section "Monitor"
   Identifier   "Monitor0"
   HorizSync    5.0-1000.0
   VertRefresh  5.0-200.0
   Modeline     "1280x800" 24.15 1280 1312 1400 1432 800 819 822 841
EndSection

Section "Screen"
   Identifier   "Screen0"
   Monitor      "Monitor0"
   Device       "Dummy0"
   DefaultDepth 24
   SubSection   "Display"
       Depth    24
       Virtual  1280 800
   EndSubSection
EndSection
  1. Disconnect the monitor, reboot the Jetson and try to connect to port 5900 with your favorite VNC viewer.

This way you can use the vino server. The downside is that you cannot attach a monitor to the Jetson after this modification. If you want to attach a monitor you have to comment out all the lines below the “# Dummy for headless mode” line.

I am still looking for a solution to have the two drivers (“nvidia” and “dummy”) coexist peacefully.

@klicker100 Thank you for the detailed instructions and for all the help!

Hi,

I can connect vino-server on Jetson Nano Ubuntu 18.04.

  1. Install vino. ``` sudo apt update sudo apt install vino gsettings set org.gnome.Vino prompt-enabled false gsettings set org.gnome.Vino require-encryption false ```
  2. Find the ethernet UUID. ``` nmcli connection show ```
  3. Add the UUID to vino-server enabled-connections. ``` dconf write /org/gnome/settings-daemon/plugins/sharing/vino-server/enabled-connections "['']" ```
  4. Run vino-server. ``` export DISPLAY=:0 /usr/lib/vino/vino-server ```

Thank you.

1 Like

@nekokeitai after sudo apt install vino and gsettings set org.gnome.vino prompt.enabled false I get the error No such schema “org.gnome.vino”

@kylemcdonald Thank you so much for pointing this out.

I’m sorry for incorrect posting.

I have fixed two missspelled.

gsettings set org.gnome.vino prompt-enabled false
gsettings set org.gnome.vino require-encryption false

Thanks.

Hi, @nekokeitai
I got the same error:

lbl@lbl-jetson-nano:~$ gsettings set org.gnome.vino prompt-enabled false
No such schema “org.gnome.vino”

Note that the command is case sensitive, use gsettings set org.gnome.Vino prompt-enabled false

The ‘V’ from Vino should be capitalized.

I have fixed again.
“org.gnome.Vino” and added “export DISPLAY=:0”.

Thanks a lot

Thanks for help.

But I still can not lauch vino server. I am using a newly installed system based on the image “jetson-nano-sd-r32.1-2019-03-18.zip”.

lbl@lbl-jetson-nano:~$ nmcli connection show
NAME                UUID                                  TYPE      DEVICE
Wired connection 1  0bed475c-0fbf-3610-87ea-a413bcd8fd4a  ethernet  eth0
l4tbr0              d261db64-efbf-4da7-8b45-868beaebdfd5  bridge    l4tbr0
lbl@lbl-jetson-nano:~$ dconf write /org/gnome/settings-daemon/plugins/sharing/vino-server/enabled-connections "['0bed475c-0fbf-3610-87ea-a413bcd8fd4a']"
lbl@lbl-jetson-nano:~$ export DISPLAY=:0
lbl@lbl-jetson-nano:~$ /usr/lib/vino/vino-server
No protocol specified
Unable to init server: Could not connect: Connection refused
Cannot open display:
Run 'vino-server --help' to see a full list of available command line options

Hi,

I think this whole discussion got derailed because the op wanted to use “VNC in headless mode without a monitor”.

@franticupl4e: You are not supposed to start vino-server from the command line. The desktop (e.g. GNOME Shell) has to manage the start of vino-server. That is why we were discussing different paths to get the VNC server working. I am sorry to say this, but the “accepted answer” by nekokeitai is not the right way to approach the problem.

In the meantime I have decided to remove Unity (no reason to keep it), deactivate GDM and respectively GNOME Shell, and to install Xfce and LightDM. This dramatically reduces memory consumption (~1.200 MB with GNOME Shell vs ~800 MB with Xfce) and allows the desktop to actually start in headless mode (although there are still problems with hardware acceleration). If you are interested I can write a step-by-step guide.

Hi, @klicker100

Thanks for pointing that out.

Actually, I was managed to setup a remote desktop via vnc4server + xfce solution at the very beginning. But the webcam streaming was not working, the same as the video playing. The only scenario I would use a remote desktop is testing the inference in a video. So I still need to find other solution. Have you face the same problem? Do you know how to fix it?

Found this article https://blog.hackster.io/getting-started-with-the-nvidia-jetson-nano-developer-kit-43aa7c298797 while googling: Jetson Nano “headless”

Look down in [Enabling Desktop Sharing] section. The first thing you need to do is to edit the org.gnome.Vino schema to restore the missing enabled parameter.

$ sudo vi /usr/share/glib-2.0/schemas/org.gnome.Vino.gschema.xml

and go ahead and add the following key into the XML file.

<key name=’enabled’ type=’b’>
   <summary>Enable remote access to the desktop</summary>
   <description>
   If true, allows remote access to the desktop via the RFB
   protocol. Users on remote machines may then connect to the
   desktop using a VNC viewer.
   </description>
   <default>false</default>
</key>

Then compile the Gnome schemas with the glib-compile-schemas command.

$ sudo glib-compile-schemas /usr/share/glib-2.0/schemas

This quick hack should stop the “Desktop Sharing” panel crashing, allowing you to open it. So go ahead and click on the “Settings” icon, and then the “Desktop Sharing” icon…

A much better solution is to install ‘xrdp’ as suggested in [Enabling Remote Desktop] section, as that can really make your Nano purely headless and also allow occasional attaching a monitor.

2 Likes

Thank you so much #18!! that worked out!!

Hi I am a total newbie at Ubuntu and I would really appreciate some help. I have typed in this

$ sudo vi /usr/share/glib-2.0/schemas/org.gnome.Vino.gschema.xml

but I cannot seem to edit the code to add in the ‘enabled’ key. How do I do that? Love to hear from you guys. Thank you!