I noticed this crash 4 times today. To recreate, ran the following
commands (almost always in this order)
5.11.0-41-generic | 20.04.1-Ubuntu | x86_64 | x86_64 | x86_64
$ sudo lxc-ls
$ sudo lxc-start -n test
$ sudo lxc-ls -f
$ sudo lxc-console -n test
$ sudo lxc-stop test
$ sudo lxc-ls -f
$ sudo
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: apparmor (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1811248
Title:
After having upgraded the host to:
unbuntu disco (19.04) | kernel 5.0.0-13 | aa 2.13.2-9 | systemd 240-6
the issue is still present
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1811248
Title:
adding cross reference
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916639#85
> I think that disabling AppArmor by default for new LXC containers for
Buster would be an OK-ish fallback option, if nothing else can
realistically be made to work in time for the freeze; that would be
sad, but
Whilst 'lxc.apparmor.profile: unconfined' appears the only way to keep
unprivileged lxc guests with systemd v240 alive it defeats the purpose
of AppArmor.
Notwithstanding, the tail riding on this bug
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1813622
https://github.com/lxc/lxd/issues/5439#issuecomment-461257784
> The fix in LXD is only partial because there's currently no safe way
for us to fix that for privileged containers due to an apparmor parser
bug that the AppArmor team is still working on.
So we've made the change only to the
*** This bug is a duplicate of bug 1813622 ***
https://bugs.launchpad.net/bugs/1813622
** This bug has been marked a duplicate of bug 1813622
systemd-resolved, systemd-networkd and others fail to start in lxc container
with v240 systemd
--
You received this bug notification because you
Going further, for those who are running arch containers in proxmox who
reach here after googling via getting a message similar to this:
[ 2204.273155] audit: type=1400 audit(1548030556.960:100):
apparmor="DENIED" operation="mount" info="failed flags match" error=-13
profile="lxc-101_" name="/"
This issue accelerating/cascading to the extent that that the lxc arch
linux guest is now entirely dead
https://bugs.archlinux.org/task/61428
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1811248
Some further input from the lxc dev team:
> What systemd wants to do is the equivalent of executing mount --make-rslave /
> on the commandline. The syscall from systemd specifically AFAICT is:
> mount(NULL, "/", NULL, MS_REC|MS_SLAVE, NULL);
As for the AppArmor profile rule, see
strace does not seem to be the tool to figure out the info you are
asking for. Considering that the pid of the involved processes would be
unknown at the time of starting strace. And executing the process(es)
from the cli along with strace will not bear fruit for the case.
Going back to the log
On Fri, Jan 11, 2019 at 02:36:30AM -, km wrote:
> profile="lxc-container-default-cgns"
>
> profile lxc-container-default-cgns
> flags=(attach_disconnected,mediate_deleted) {
> #include
>
> # the container may never be allowed to mount devpts. If it does, it
> # will remount the
profile="lxc-container-default-cgns"
profile lxc-container-default-cgns flags=(attach_disconnected,mediate_deleted) {
#include
# the container may never be allowed to mount devpts. If it does, it
# will remount the host's devpts. We could allow it to do it with
# the newinstance
Could you add to this bug which mount flags are being used by the
mount(2) system call that's failed and which mount rules are in the
profile? I couldn't find either information in the linked bugs.
Thanks
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
14 matches
Mail list logo
