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 "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd";> <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) ** Also affects: dbus (Ubuntu) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu) Status: New => Invalid ** Changed in: cloud-init Status: Invalid => New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1905493 Title: cloud-init status --wait hangs indefinitely in a nested lxd container To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1905493/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
