Display Black at Boot

Symptom:

Xena boots and everything seems fine until it starts display-manager[-legacy], i.e. X-Windows and its greeter, which is lightdm. The X-Server starts, it flips to VT7, and shows a black screen, no greeter. It's possible to do ctrl-alt-F1 and log in, for troubleshooting.

What's happening:

Xena has a virtual machine, Petra. Xena has a bridge (br0) plus wild-side egress ports for Ethernet and Wi-Fi (en0, rad0) which are not in the bridge. The bridge has Xena's IP addresses. The network setup closely resembles Jacinth and Surya. Petra's egress port is vnet0 on the outside, and it's a member of Xena's bridge, if Petra is running.

Lightdm (per /etc/lightdm/lightdm.conf) has VNC enabled and it's listen-address=:: port 5900. This gives an error message: Failed to create IPv4 VNC socket: Error binding to address [::]:5900: Address family not supported by protocol". But the VNC viewer can connect to Xena's IPv4 address. Presumably it is using the IPv6 listen socket with an IPv4 mapped address.

If Petra isn't running, Xena's br0 has no members and is seen to have no carrier. When lightdm starts up it tries to bind to port 5900 but fails because the port is not up. Lightdm fails ungracefully, taking the X-Server down too, and you are left with a black screen.

How to fix:

According to Google's AI, this is a quirk of NetworkManager. (That's not a bug, that's a feature!) But you can override it: in the NetworkManager config file /etc/NetworkManager/system-connections/Bridge0 find the [bridge] section and add or alter a line to say ignore-carrier=true. That brought lightdm back to life.

So why was Petra down? In this case it wasn't actually down, but there was a chicken and egg issue: it couldn't contact the DNS server on Xena because NetworkManager wouldn't bring up br0, so Kea DHCP server could not resolve hostnames needed to get Petra's assigned DHCP address.

Another more annoying issue came from this scenario which is all too easy to get into by mistake.

• On Xena (which hosts Petra), update libvirt-daemon and friends to a version which cannot deal with managed-save images created by the back-version daemon. This is part of a dist-upgrade campaign done on all the hosts.

• When rebooting after upgrades, the first step should be to shut down all the virtual machines, so there will be no managed-save images. But you think, I want to monitor the reboot process from Xena, so I should reboot Xena first. Not a wise move.

• When Xena comes up and autostarts Petra, it can't read the managed save image, Petra doesn't start, and things on Xena go downhill from there. At least I was able to flip to VT1, log in as root, and figure out what went wrong.

• To recover Petra, I undefined and redefined it. Commands:

  • virsh undefine --managed-save --keep-nvram petra
    (Look at the other options too, if relevant for your virtual machines.) This removes the offending managed-save image, and doesn't remove Petra's NVRAM.
  • virsh define /s1/kvm/petra/petra.xml
    (I have my own storage for each virtual machine's definition file. The native VM definition file is /etc/libvirt/qemu/petra.xml).
  • virsh autostart petra
    (It's revoked when the host is undefined.)