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.
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!
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:
Configure auto-login with GDM3. Open “/etc/gdm3/custom.conf” and uncomment or change the following lines:
AutomaticLoginEnable=true
AutomaticLogin=nvidia
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).
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?
@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.
@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:
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.
Install the Xorg dummy:
$ sudo apt install xserver-xorg-video-dummy -y
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
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.
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
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.
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?
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.
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.