Once again there are problems on the VNC side (logging in remotely, using VNC), particularly useful when accessing the server from an Mac (OSX) machine, where you “share screen…” with the Linux server. However, it appears that the upgrade to Ubuntu 18.04 probably changes the default desktop back to gdm3, which still appears not to support the VNC setup well according to the below:

https://askubuntu.com/questions/1033274/ubuntu-18-04-connect-to-login-screen-over-vnc/

Running the below command, and selecting to use lightdm as the desktop manager will get things back working again.

dpkg-reconfigure lightdm

It appears this changes the following symlink:

root@shuttle:/etc/systemd/system/multi-user.target.wants# ls -l /etc/systemd/system/display-manager.service
lrwxrwxrwx 1 root root 35 Dec 26 21:44 /etc/systemd/system/display-manager.service -> /lib/systemd/system/lightdm.service

I find that staying behind the curve for upgrades, particularly where it is a must work machine, saves a fair amount of grief. Although I invariably have to track down problems, by the time I get around to an upgrade there tend to be other people who have found (and worked-around) similar issues. This means I can cherry-pick the preferred fix (rather than having to use the horrible hack someone has documented, or track down the real problem/fix).

During this upgrade, after rebooting the screen remained blank. After finding the machine was actually on the network, I tracked it down to this problem:
http://askubuntu.com/questions/792129/16-04-boot-stops-at-a-start-job-is-running-for-hold-until-boot-process-finish

Switching from the gdm3 desktop manager to lightdm fixed this issue; X usage is minimal so features are of minimal interest, as long as it works!

To get x11vnc (the common/standard desktop-agnostic Ubuntu VNC server for X) to start in 16.04 (and later), with systemd, you need the following:
https://help.ubuntu.com/community/VNC/Servers#Have_x11vnc_start_automatically_via_systemd_in_any_environment_.28Vivid.2B-.29

Following the instructions does not seem to cause VNC to start. There must be a better way, but the brute-force reboot caused
it to start a process on port 5900.

The side effect of switching away from gdm3 is that my VNC server configuration no longer functions … more work to do! By way of a reminder, the reason for VNC server is so that the user can connect to do admin tasks without having to physically connect KVM (keyboard/video/mouse) to the server. As OSX is the usual client, integration using Zeroconf (Avahi) makes a lot of difference!

To get Avahi notifying about the service, add the below config to a file (eg, rfb.service) to the /etc/avahi/services/ directory:

———-
<?xml version=”1.0″ standalone=’no’?><!–*-nxml-*–>
<!DOCTYPE service-group SYSTEM “avahi-service.dtd”>
<service-group>
<name replace-wildcards=”yes”>%h</name>
<service>
<type>_rfb._tcp</type>
<port>5900</port>
</service>
</service-group>

The above was shamelessly taken from holyarmy.org – why re-invent the wheel?

Let’s hope that other things haven’t boken, although TimeMachine integration breakage tends to happen on OSX upgrades!