1

Lubuntu 16.04 LTS running headless on a Banana Pro, starting from LeMaker's official image. After imaging a 32GB SD card, I expanded the system partition from ~3.7GB to fill the card, then booted for the first time and followed this pseudocode:

do
  # Boot and SSH in
  ssh bananapi@<ip_address>
  bananapi

  # Initial Setup on SSH
  sudo su
  bananapi
  apt-get update
  apt-get dist-upgrade -y                     # let it do everything it wants
  apt-get autoremove -y
  nano /etc/sudoers                           # add bananapi back in, copying root
  nano /etc/update-manager/release-upgrades   # set the desired option here
  do-release-upgrade                          # let it do everything it wants, including reboot
while(do-release-upgrade did something)

apt-get install x11vnc -y
x11vnc -storepasswd ******** /etc/x11vnc.pass
nano /etc/rc.local

/etc/rc.local includes the line:

/usr/bin/x11vnc -noxrecord -shared -xkb -forever -auth /var/run/lightdm/root/:0 -display :0 -rfbauth /etc/x11vnc.pass -rfbport 5900 -bg -o /var/log/x11vnc.log

When it finishes rebooting, my VNC clients on different Windows and Lubuntu machines can connect to it and control it. I finish setting it up, using a combination of VNC/GUI tweaks, SSH for easy copy/paste, and sFTP for prefab scripts and source code to build on the Pi, and reboot again.

When it comes back up, I reconnect a VNC client, and all seems well. But some time later, I notice that the VNC window is unresponsive. Not just readonly, but the clock doesn't even change. This is also consistent between Windows and Linux clients. A newly connected client shows the same problem immediately: the connection succeeds, but it shows an outdated screenshot that doesn't respond to anything.

By this time, having completed all of my setup, I have an auto-shutdown script (remember this is headless) for when the system switches to battery power, so I can still shut it down gracefully by pulling the AC plug. When it comes back up, VNC works again...for a while. I also notice that even when VNC has failed, SSH and the WiFi access point still work, so it's not a complete system failure. Just VNC.

This problem is the same on 16.04 as it is on the original 14.04 image with just the package upgrades, except that LeMaker hasn't actually released an official 16.04 image yet.

Any ideas?

AaronD
  • 813

1 Answers1

0

I finally figured it out! Thanks to this thread about a different VNC server on a different machine and some happenstance playing with the Pi:

https://forum.ultravnc.net/viewtopic.php?f=3&t=31898

Basically the problem is that the VNC server continues to read a display buffer that is no longer updated because the video stuff has shut down. In the thread above, that's because I closed the lid of a laptop running that server; in the case of this question, it's because the default screen blanking time was still there. Once it timed out, the Pi's graphics chip shut down, no longer updating the buffer, and so the VNC server appeared to have frozen.

Why it didn't come back on a VNC'ed mouse event, I don't know, but setting the Pi to never turn the screen off fixed the dropout in the first place.

(It's headless anyway, so it's not like I'm wasting power on a screen by doing this. Maybe a little bit on a graphics chip, but that's negligible in my application.)

AaronD
  • 813