it's interesting that apparmor appears to work ok in the first-level
container, but fails in the nested container, e.g.:
$ lxc shell lp1905493-f
root@lp1905493-f:~# systemctl status apparmor
● apparmor.service - Load AppArmor profiles
Loaded: loaded (/lib/systemd/system/apparmor.service;
I wonder if this is actually a problem with the specific apparmor
profile that's created by lxd, maybe it doesn't provide enough
permissions to allow the container's lxd to correctly pass the apparmor
profile down to the nested container. Similar to how lxd locks down
containers a bit too tight by
Yep, that's what I've found; cloud-init is just waiting for its later
stages to run, which are blocked by snapd.seeded.service exiting.
** Changed in: cloud-init
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
FWIW I know what the snapd issue is, the issue is that snapd does not
and will not work in a nested LXD container, we need to add code to make
snapd.seeded.service die/exit gracefully in this situation.
** Also affects: snapd
Importance: Undecided
Status: New
** Changed in: snapd
Given that the logind issue is an AppArmor issue and, per my previous
comment, "the two running jobs are systemd-logind.service and
snapd.seeded.service", I suspect that we'll find that snapd is running
into similar sorts of issues. I'll take a quick look now.
--
You received this bug
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:
Hi Ian,
I've just launched such a container and I see a bunch of non-cloud-init
errors in the log and when I examine `systemctl list-jobs`, I see that
the two running jobs are systemd-logind.service and
snapd.seeded.service:
root@certain-cod:~# systemctl list-jobs
JOB UNIT
