Hi there, thanks of the update. Just in in case anyone else here is interested in a temporary workaround, this is what I did for my use case: - create a config file for dbus like the one mentioned in comment #2 - apt remove apparmor - reboot
After that "runlevel", "systemctl is-system-running" and "cloud-init -status --wait" should work. Last but not least, I would like to mention this issue affects running autopkgtests in nested containers (autopkgtest uses "runlevel" to detect if the container is properly started), I had an interesting conversation about this here (thanks a lot ddstreet for the help!): https://irclogs.ubuntu.com/2022/06/13/%23ubuntu-devel.html#t15:05 ** Also affects: autopkgtest Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dbus in Ubuntu. https://bugs.launchpad.net/bugs/1905493 Title: Services (apparmor, snapd.seeded, ...?) fail to start in nested lxd container Status in AppArmor: New Status in autopkgtest: New Status in cloud-init: Invalid Status in snapd: Confirmed Status in dbus package in Ubuntu: Confirmed Status in lxd package in Ubuntu: New Status in systemd package in Ubuntu: Invalid Bug description: When booting a nested lxd container inside another lxd container (just a normal container, not a VM) (i.e. just L2), using cloud-init -status --wait, the "." is just printed off infinitely and never returns. To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1905493/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
