L4T/JetPack 4.4 DP desktop sharing and Bluetooth bugs

I got the original Ubuntu Vino VNC server running on a dozen or 2 (virtual) machines connecting with TightVNC.
Always switch off require-encryption with dconf, cuz this setting is still not in the GUI after years.
Installed 4.4 DP on the TX2 (after a year collecting dust). After two years still hoping flashing will get less complicated.

Bug 1:
Settings (unity-control-center) > Desktop Sharing crashed w/o comment for a dozen times and just threw a first Error Report (but to Canonical, screenshot attached).
When I check settings with dconf the “enabled” item is missing (in comparison to an Ubuntu 16.04).
In gnome-control-center sharing is enabled, but can’t switch on Screen Sharing. (due to no network selected?)

Bug 2:
Yesterday I had a Bluetooth keyboard connected successfully. In the Status Bar I can switch Connection on, in the dialog I can’t.
gnome-control-center tells I have no BT.


The only thing I could see from the screenshot was “signal 5”, which is probably just the system being told to generate the crash report (signal 5 seems to be a trace or breakpoint trap, which implies instructions to a debugger). I doubt it would help, but you might look closer at the stack trace…I am not certain, but perhaps you can use that crash report tool to show details, and a stack trace could perhaps offer more clues.

Thanks for helping!
One of the problems is: The seemingly very basic crash report tool only gets triggered 1 in several dozen or so. Otherwise settings dies silently. And no apparent way to export the crash data in text.

Edit Found the crash file in /var/crash/_usr_bin_unity-control-center.1000.crash, but seemingly 1 crash is 6.2MB and is too big for upload. (and gedit nealy chokes)

Also wanna find the sharing config file, cuz I guess sth’s screwed up there. Gnome vs Unity.

Any further ideas? Experience with (4.4) DP?

We’re getting to the bottom. Though normally refusing to use cannons for sparrows I did a reinstall, just to be sure. Same.
Suspicion re “enabled” hardened. Tried gnome-control-center variant:

gy@gtx2:~$ unity-control-center sharing
…Could not find settings panel “sharing”

(unity-control-center:11921): GLib-GIO-ERROR **: 13:00:40.934: Settings schema ‘org.gnome.Vino’ does not contain a key named ‘enabled’
Trace/breakpoint trap (core dumped)

And I got another screenshot with disassembly and stacktrace expanded.


I don’t know enough about the app to do much here. However, if the app has debug symbols or a debug version available (and there probably are debug symbols available, but I don’t know what would be needed to make those symbols available), then more information would probably be provided during the dump. Better yet, you could perhaps then start the sharing app within gdb and get even more detail. Right now it seems you’ve likely found an uninitialized (or invalid) function call argument due to some basic setting.

There is a bug report I saw, but did not read details of, which is likely what you are running into:

This reminds me, are your packages all updated and current? That particular bug report mentions a fix released. A fix might be as simple as an update.

1 Like

SOLVED! Yeah, thanks for digging up the bug report matching my suspicion! Seems to be a major regression!

In a nutshell comment #11 there says:
sudo nano /usr/share/glib-2.0/schemas/org.gnome.Vino.gschema.xml

You can add the “enabled” xml-snippet as very first key:

    <key name='enabled' type='b'>
      <summary>Enable remote access to the desktop</summary>
        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.

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

Now System Settings > Desktop Sharing doesn’t crash any more and you can set your parameters.

Major edit / reversal of result / works now:
didn’t sound right to start a service, but with one other hint it works, simple as it’ll get.
Look for an app Startup Applications and Add the command there. Didn’t know that simple approach to start daemons at boot.

I have no idea why the WiFi on my client machine was switched off, but this was the socket error!
Thanks for the input, @linuxdev!

Disregard the below snippet / prior version (Don’t know how to strike-through):
doesn’t sound like expert advice and I still get a socket error at the VNC client.
(L4T doesn’t seem to know ufw, so the firewall shouldn’t be a problem!?)

The start-Vino-as-daemon example code on askubuntu seems reasonable.

The file /etc/systemd/system/vinostartup.service mentioned there doesn’t exist in 4.4 DP, so the problem seems to be much deeper.

Guess it’s time someone official from Nvidia steps in to clean up this mess.

Any input to get it really running? (TeamViewer is available everywhere, but not on Linux ARM!! arrrghh)
At least my Bluetooth kbd / trackpad works again to free some ports.

1 Like

UFW simply is not installed by default. Works well after “sudo apt-get install ufw” (or the GUI version, “sudo apt-get install gufw”).

I can’t help on the actual vino issue, and the TeamViewer people would have to provide a 64-bit ARM release (which I’ve not heard of). There are other people who have had different remote desktop sharing apps which work though.

Hey, you seem to be replying to the original version of my last post, which says bug, but after an hour of more digging I reversed it to solved. Please have a look and thanks again for your help!

Re UFW: Yeah, thanks. Didn’t dig more. Just checked it wasn’t a factor.

Re RD alt: See RDP from Windows fails recommending NoMachine.
Rather have Vino working than install half a dozen alternatives of every kind of sw, like IDEs, graphics frameworks,…


Your solution works! I also disabled encryption so I can connect to TX2. Run as normal user is OK.
gsettings set org.gnome.Vino require-encryption false