← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1905493] Re: Services (apparmor, snapd.seeded, ...?) fail to start in nested lxd container

 

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 Yahoo!
Engineering Team, which is subscribed to cloud-init.
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



References