The Linux Page

Various settings/tweaks I needed for my Jetson Xavier AGX

Jetson Xavier AGX with a Raspberry Pi showing the ports

First Boot

If you're here because the first boot didn't work, the system showed a message in the console saying:

a start job is running for End-User configuration after initial OEM installation

Then you most certainly have the network connected. The Jetson will not start if there is a chance that it is connected to the Internet and thus could let someone from the outside connect to the board unless you already setup a user account with your very own user name and password.

This is done like this because of a new law in California which now forces people to enter a username and password on new devices instead of creating a default account with a default password which hackers love very much.

If you can't reboot even without the network cable, you'll have to flash the board. Of course, if you're here because of this problem, it's probably too late.

I do not know whether disconnecting the network cable will help. On my end, I flashed and rebooted without the network cable and that Jetson booted as expected. The other two boards, I did not connect the network and they booted right up as expected.

Source: Brand new Jetson AGX Xavier doesn’t boot

Desktop Sharing

There is a bug in the Vino definition which prevents the Desktop Sharing window from opening. It will "crash" (or at least throw an error because that one option is not present).

To fix the problem you can simply add the option in the Vino file.

To open the file, use sudo and the following path:

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

Then add the missing key:

<schemalist>
  <schema id='org.gnome.Vino' path='/org/gnome/desktop/remote-access/'>
    <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>

    <key name='prompt-enabled' type='b'>
      <summary>Prompt the user before completing a connection</summary>
      <description>
        If true, remote users accessing the desktop are not allowed
        access until the user on the host machine approves the
        connection. Recommended especially when access is not password
        protected.
      </description>
      <default>true</default>
   </key>

   ...

I just had to add the part I highlighted in yellow.

For the change to be taken in account you have to compile it. Run the following command:

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

Note that the compiler must not return any error if you want this to work.

Once this is ready, you should be able to setup the server through your preferences. However, at least on my system it has not started it automatically. It was enabled but it needed a little kick. To do that I used:

systemctl --user start vino-server

As usually, you can use the status command to see how the server is doing (crashed, enabled, etc.):

systemctl --user status vino-server

Notice that it uses the --user command line option. This is because this is a user specific server. It does not exist in the system (you can't start that as a system server).

By default, the server will not be automatically started. If you would like the command to auto-start, use the "Startup Applications" interface (click on the "Show Application" and type "Startup Applications" then click on the icon). To add the command to your startup, click the Add button and then enter a name and the start command as shown above. That way, when you log on, it will automatically start your VNC service. Also, when you log out, it will automatically stop it.

For the hard core people, that can be done using an editor. Editing with vim:

vim ~/.config/autostart/systemctl.desktop

Then add an entry such as:

[Desktop Entry]
Type=Application
Exec=systemctl --user start vino-server
Hidden=false
NoDisplay=false
X-GNOME-Autostart-enabled=true
Name[en_US]=Vino Server
Name[fr_FR]=Vino Serveur
Name=Vino Server
Comment[en_US]=Auto-start the VNC service on login in
Comment[fr_FR]=Auto-démare le service VNC sur une connection
Comment=Auto-start the VNC service on login in

If the autostart folder or systemctl.desktop file do not exist, create them.

Source: Ubuntu Internal error when selecting desktop sharing in settings. (answer #18)
Source: How to get vino VNC server to start on startup in Ubuntu 18.04.1?

Desktop Sharing Behind the Firewall

Since I have a strong firewall, all the ports are blocked by default so I needed to open up a little hole so my co-workers would be able to access the desktop I just shared. Without that, it's not going to be very useful to do that sharing. It's fairly slow and I could as well work directly on the Jetson. It's just much faster/easier to do it that way!

So in this case we have to forward packets sent to port 5900 to another computer. This can directly be done with the firewall. In other words, we do not need some weird proxy tool. Linux is great in that respect.

First, we need to forward packets from eth1 to eth2. This is only for the connection itself, not the data traveling afterward. I'll assume you checked my other firewall setup post which explains this in more details.

iptables -A FORWARD -i eth1 -o eth2 -p tcp --syn \
           --dport 5900 -m conntrack --ctstate NEW -j ACCEPT

Next you need to preroute to change the IP address. Without a preroute, the connection would happen on the very server accepting requests. The following shows how this is done. Notice that the input interface is specified. In my case I have one interface to connect to the Internet and another to connect my intranet. It increase your security without as much work, I think.

iptables -A PREROUTING -i eth1 -p tcp --dport 5900 -j DNAT \
                                --to-destination 10.10.10.11

The prerouting is important, but we also need a postrouting to reroute traffic coming back from our intranet computer.

iptables -A POSTROUTING -o eno2 -d 10.10.10.11 -p tcp \
                 --dport 5900 -j SNAT --to-source 10.10.10.1

Notice that we route it to the same interface so the --to-source IP address is our intranet gateway and not the outside internet IP address.

That's it.

Is that going to be more efficient than a proxy service? You bet! Especially, you won't have to sort out that proxy and make it work separately of the rest...

Top View of the Jetson Box

Jetson and Rasberry from the top