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
