The systemd-logind problem is due to dbus defaulting to apparmor mode 'enabled', but apparmor can't do much of anything inside a container so it fails to start, and dbus can't contact it.
In the 2nd level container, create a file like '/etc/dbus-1/system.d/no-apparmor.conf' with content:
Then restart the 2nd level container and recheck systemd-logind which should now work
Of course, fixing dbus should be a bit smarter about only disabling its use of apparmor if it's inside a container.
However, cloud-init status --wait still hangs after systemd-logind starts up, so that wasn't the original problem (or at least wasn't the only problem)
The systemd-logind problem is due to dbus defaulting to apparmor mode 'enabled', but apparmor can't do much of anything inside a container so it fails to start, and dbus can't contact it.
In the 2nd level container, create a file like '/etc/dbus- 1/system. d/no-apparmor. conf' with content:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE busconfig PUBLIC p//DTD D-BUS Bus Configuration 1.0//EN" www.freedesktop .org/standards/ dbus/1. 0/busconfig. dtd">
"-//freedeskto
"http://
<busconfig>
<apparmor mode="disabled"/>
</busconfig>
Then restart the 2nd level container and recheck systemd-logind which should now work
Of course, fixing dbus should be a bit smarter about only disabling its use of apparmor if it's inside a container.
However, cloud-init status --wait still hangs after systemd-logind starts up, so that wasn't the original problem (or at least wasn't the only problem)