yahoo-eng-team team mailing list archive

[Christian Ehrhardt  <1905493@xxxxxxxxxxxxxxxxxx>]

Due to a ping on IRC I wanted to summarize the situation here as it
seems this still affects people.

In nested LXD container we seem to have multiple issues:
- apparmor service failing to start (might need to work with LXD to sort out why and how to fix it)
  - if it doesn't work at least fail to start more gracefully
  - comment 2 has a workaround to make dbus not insist on apparmor, but that is not a real fix we could generally apply

- snapd snapd.seeded.service needs code to die/exit gracefully in this situation (as it won't work)
  - See comment 7, might have changed since then, but worth a revisit

** Also affects: lxd (Ubuntu)
   Importance: Undecided
       Status: New

** Summary changed:

- cloud-init status --wait hangs indefinitely in a nested lxd container
+ Services (apparmor, snapd.seeded, ...?) fail to start in nested lxd container

-- 
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 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