Hi, Pierre-Elliott Bécue: >>>> Setting up lxc (1:3.1.0+really3.0.3-2) ... >>>> Warning from stdin (line 1): config file '/etc/apparmor/parser.conf' not >>>> found >>>> Cache read/write disabled: interface file missing. (Kernel needs >>>> AppArmor 2.4 compatibility patch.) >>>> Warning: unable to find a suitable fs in /proc/mounts, is it mounted? >>>> Use --subdomainfs to override. >>>> dpkg: error processing package lxc (--configure): >>>> installed lxc package post-installation script subprocess >>>> returned error exit status 1
>>>> >> > See my staged commits. >> > >> > https://salsa.debian.org/lxc-team/lxc/commit/a0e6b5f26227236e44ab8ff4cee745228201bb7d typo: s/runn/run/ >> weirdy, if you first install apparmor, then install lxc in a separate >> apt invocaation, it works just fine. and, if you do `apt install -f` >> after the initial failure, it also works fine. > I think it's a matter of AppArmor doing some magic at the end via a > trigger. apparmor.postinst starts apparmor.service on package configuration; so far, that's pretty much standard; but then apparmor.service mounts securityfs if it was not mounted yet… and apparmor_parser uses securityfs to interact with the Linux kernel. lxc.postinst calls apparmor_parser. So if lxc is configured before apparmor, indeed the call to "apparmor_parser -r -W -T /etc/apparmor.d/lxc-containers" will fail. FTR dh-apparmor handles this situation by generating this postinst code snippet, which is equivalent to what lxc.postinst has, modulo different output: if aa-enabled --quiet 2>/dev/null; then apparmor_parser -r -T -W "$APP_PROFILE" || true fi This is clearly not ideal, because depending on package configuration ordering, some profiles may be loaded and some might not be. I've not thought much about this problem yet, but I suspect that for service packages such as LXC, handling this sort of things at the systemd unit level might give us more robust ordering than what we're currently doing via postinst. Food for thought :) Cheers, -- intrigeri