Re: [Touch-packages] [Bug 1931064] [NEW] lxc autotest failure with kernel >= 5.13
On Mon, Jun 07, 2021 at 05:14:50AM -, Andrea Righi wrote:
> Public bug reported:
>
> The lxc autotest is failing with the following error(s) on the latest
> kernel linux-unstable 5.13:
>
> FAIL: lxc-tests: lxc-test-apparmor (1s)
> ---
> failed - opened /sys/kernel/uevent_helper
> ---
> PASS: lxc-tests: lxc-test-apparmor-generated (0s)
> PASS: lxc-tests: lxc-test-apparmor-mount (29s)
> FAIL: lxc-tests: lxc-test-attach (1s)
> ---
> attach.c: 410: main: Using "/tmp/attach_x8lgO2" as temporary log file for
> container lxc-attach-test
>
> I was able to bisect the problem and found that the offending commit is:
>
> bfb819ea20ce8bbeeba17e1a6418bf8bda91fc28 ("proc: Check /proc/$pid/attr/
> writes against file opener")
>
> This commit looks like a sane fix, so simply reverting it in the kernel
> doesn't seem a viable solution.
>
> I think we should address and understand the issue in the lxc package.
So this failure implies that the
/sys/kernel/uevent_helper
file that we denied access to via AppArmor can now be opened. And then
lxc-test-attach reports an LSM label mismatch in the link you posted
below too so that seems scary...
>
> Detailed log of the failure: https://autopkgtest.ubuntu.com/results
> /autopkgtest-impish-canonical-kernel-team-
> bootstrap/impish/amd64/l/lxc/20210601_082733_a3ae4@/log.gz
>
> ** Affects: lxc (Ubuntu)
> Importance: Undecided
> Status: New
>
> ** Description changed:
>
> The lxc autotest is failing with the following error(s) on the latest
> kernel linux-unstable 5.13:
>
> FAIL: lxc-tests: lxc-test-apparmor (1s)
> ---
> failed - opened /sys/kernel/uevent_helper
> ---
> PASS: lxc-tests: lxc-test-apparmor-generated (0s)
> PASS: lxc-tests: lxc-test-apparmor-mount (29s)
> FAIL: lxc-tests: lxc-test-attach (1s)
> ---
> attach.c: 410: main: Using "/tmp/attach_x8lgO2" as temporary log file for
> container lxc-attach-test
>
> I was able to bisect the problem and found that the offending commit is:
>
> bfb819ea20ce8bbeeba17e1a6418bf8bda91fc28 ("proc: Check /proc/$pid/attr/
> writes against file opener")
>
> This commit looks like a sane fix, so simply reverting it in the kernel
> doesn't seem a viable solution.
>
> I think we should address and understand the issue in the lxc package.
> +
> + Detailed log of the failure: https://autopkgtest.ubuntu.com/results
> + /autopkgtest-impish-canonical-kernel-team-
> + bootstrap/impish/amd64/l/lxc/20210601_082733_a3ae4@/log.gz
>
> --
> You received this bug notification because you are a member of Ubuntu
> containers team, which is subscribed to lxc in Ubuntu.
> Matching subscriptions: lxc
> https://bugs.launchpad.net/bugs/1931064
>
> Title:
> lxc autotest failure with kernel >= 5.13
>
> Status in lxc package in Ubuntu:
> New
>
> Bug description:
> The lxc autotest is failing with the following error(s) on the latest
> kernel linux-unstable 5.13:
>
> FAIL: lxc-tests: lxc-test-apparmor (1s)
> ---
> failed - opened /sys/kernel/uevent_helper
> ---
> PASS: lxc-tests: lxc-test-apparmor-generated (0s)
> PASS: lxc-tests: lxc-test-apparmor-mount (29s)
> FAIL: lxc-tests: lxc-test-attach (1s)
> ---
> attach.c: 410: main: Using "/tmp/attach_x8lgO2" as temporary log file for
> container lxc-attach-test
>
> I was able to bisect the problem and found that the offending commit
> is:
>
> bfb819ea20ce8bbeeba17e1a6418bf8bda91fc28 ("proc: Check
> /proc/$pid/attr/ writes against file opener")
>
> This commit looks like a sane fix, so simply reverting it in the
> kernel doesn't seem a viable solution.
>
> I think we should address and understand the issue in the lxc package.
>
> Detailed log of the failure: https://autopkgtest.ubuntu.com/results
> /autopkgtest-impish-canonical-kernel-team-
> bootstrap/impish/amd64/l/lxc/20210601_082733_a3ae4@/log.gz
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1931064/+subscriptions
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1931064
Title:
lxc autotest failure with kernel >= 5.13
Status in ubuntu-kernel-tests:
New
Status in lxc package in Ubuntu:
New
Bug description:
The lxc autotest is failing with the following error(s) on the latest
kernel linux-unstable 5.13:
FAIL: lxc-tests: lxc-test-apparmor (1s)
---
failed - opened /sys/kernel/uevent_helper
---
PASS: lxc-tests: lxc-test-apparmor-generated (0s)
PASS: lxc-tests: lxc-test-apparmor-mount (29s)
FAIL: lxc-tests: lxc-test-attach (1s)
---
attach.c: 410: main: Using "/tmp/attach_x8lgO2" as temporary log file for
container lxc-attach-test
I was able to bisect the problem and found that the offending commit
is:
bfb819ea20ce8bbeeba17e1a6418bf8bda91fc28 ("proc: Check
/proc/$pid/attr/ writes against file opener")
This commit looks like a
[Touch-packages] [Bug 1931064] Re: lxc autotest failure with kernel >= 5.13
I'm currently treating this as an upstream kernel regression reported
here
https://lore.kernel.org/regressions/20210607142245.eikvyeacqwwu6dn3@wittgenstein
We should wait whether a simple revert will be acceptable or whether
anything else is needed from LXC specifically.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1931064
Title:
lxc autotest failure with kernel >= 5.13
Status in ubuntu-kernel-tests:
New
Status in lxc package in Ubuntu:
New
Bug description:
The lxc autotest is failing with the following error(s) on the latest
kernel linux-unstable 5.13:
FAIL: lxc-tests: lxc-test-apparmor (1s)
---
failed - opened /sys/kernel/uevent_helper
---
PASS: lxc-tests: lxc-test-apparmor-generated (0s)
PASS: lxc-tests: lxc-test-apparmor-mount (29s)
FAIL: lxc-tests: lxc-test-attach (1s)
---
attach.c: 410: main: Using "/tmp/attach_x8lgO2" as temporary log file for
container lxc-attach-test
I was able to bisect the problem and found that the offending commit
is:
bfb819ea20ce8bbeeba17e1a6418bf8bda91fc28 ("proc: Check
/proc/$pid/attr/ writes against file opener")
This commit looks like a sane fix, so simply reverting it in the
kernel doesn't seem a viable solution.
I think we should address and understand the issue in the lxc package.
Detailed log of the failure: https://autopkgtest.ubuntu.com/results
/autopkgtest-impish-canonical-kernel-team-
bootstrap/impish/amd64/l/lxc/20210601_082733_a3ae4@/log.gz
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1931064/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1969905] Re: lxc-test-no-new-privs in ubuntu_lxc failed on F-s390x zVM (lxc 1:4.0.12-0ubuntu1~20.04.1 )
And that only fails on s390x? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1969905 Title: lxc-test-no-new-privs in ubuntu_lxc failed on F-s390x zVM (lxc 1:4.0.12-0ubuntu1~20.04.1 ) Status in ubuntu-kernel-tests: New Status in lxc package in Ubuntu: New Bug description: Issue found on F 5.4.0-108.122 s390x node kernel04 Test failed with: Running '/tmp/lxc-pkg-ubuntu/src/tests/lxc-test-no-new-privs' + DONE=0 + trap cleanup EXIT SIGHUP SIGINT SIGTERM + '[' '!' -d /etc/lxc ']' + lxc-create -t busybox -n c1 + echo 'lxc.no_new_privs = 1' + lxc-start -n c1 ++ lxc-info -n c1 -p -H + p1=65479 + '[' 65479 '!=' -1 ']' + lxc-attach -n c1 --clear-env -- mkdir -p /home/ubuntu + lxc-attach -n c1 --clear-env -- /bin/sh -c 'cat <> /etc/passwd ubuntu:x:1000:1000:ubuntu:/home/ubuntu:/bin/sh EOF' + lxc-attach -n c1 --clear-env --uid 1000 --gid 1000 -- ping -c 1 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes ping: permission denied (are you root?) + lxc-stop -n c1 -k + sed -i 's/lxc.no_new_privs = 1/lxc.no_new_privs = 0/' /var/lib/lxc/c1/config + lxc-start -n c1 + lxc-attach -n c1 --clear-env --uid 1000 --gid 1000 -- ping -c 1 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes ping: sendto: Network is unreachable Managed to ping localhost + echo 'Managed to ping localhost' + false + cleanup + cd / + lxc-destroy -n c1 -f FAIL + '[' 0 -eq 0 ']' + echo FAIL + exit 1 It's worthy to note that this test has passed with 5.4.0-106.120 + lxc 1:4.0.6-0ubuntu1~20.04.1 The test output is a bit different, I think it's because of this commit: https://github.com/lxc/lxc/commit/f6a53ad2c593ade2320cc357abd15e01e22b6f8d To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1969905/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1959013] Re: systemd test_exec_umask_namespace fails in privileged container
Are the tests run with security.nesting=true set? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1959013 Title: systemd test_exec_umask_namespace fails in privileged container Status in lxd package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: systemd added a new test case to it's "test-execute", which is failing in privileged containers, while passing everywhere else. https://github.com/systemd/systemd- stable/commit/ae53f4b5e48860b473c4d05958486a77f84ecc6d exec-umask-namespace.service: Passing 0 fds to service exec-umask-namespace.service: About to execute /bin/ls -lahd /tmp/subdir exec-umask-namespace.service: Forked /bin/ls as 2485 exec-umask-namespace.service: Changed dead -> start exec-umask-namespace.service: User lookup succeeded: uid=65534 gid=65534 Received SIGCHLD from PID 2485 (ls). Child 2485 (ls) died (code=exited, status=2/INVALIDARGUMENT) exec-umask-namespace.service: Failed to read oom_kill field of memory.events cgroup attribute: No such file or directory exec-umask-namespace.service: Child 2485 belongs to exec-umask-namespace.service. exec-umask-namespace.service: Main process exited, code=exited, status=2/INVALIDARGUMENT exec-umask-namespace.service: Failed with result 'exit-code'. exec-umask-namespace.service: Service will not restart (restart setting) exec-umask-namespace.service: Changed start -> failed exec-umask-namespace.service: Unit entered failed state. src/test/test-execute.c:868:test_exec_umask_namespace: exec-umask-namespace.service: exit status 2, expected 0 A full test-run / log is available at https://autopkgtest.ubuntu.com/results/autopkgtest-jammy-slyon-testing/jammy/amd64/s/systemd/20220125_143301_25947@/log.gz I'll be skipping this test case fow now, to be able to move forward with systemd 249.9 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1959013/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1917601] Re: lxc 1:4.0.4-0ubuntu3 ADT test failure with linux 5.8.0-45.51
This is with 4.0.4 and the bug is fixed in 4.0.6 which it seems hasn't made it into Groovy yet (but is released). I'm not sure what Stéphane's timeline is there. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1917601 Title: lxc 1:4.0.4-0ubuntu3 ADT test failure with linux 5.8.0-45.51 Status in lxc package in Ubuntu: New Status in lxc source package in Groovy: New Bug description: We seem to get failed dep8 testing on lxc in Groovy for a while. What we are interested in is knowing whether this is known problems in the testing or something that waits on kernel fixes (who would be driving those if this is the case). Testing failed on: amd64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/amd64/l/lxc/20210224_161232_5c8ac@/log.gz arm64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/arm64/l/lxc/20210224_202135_e7aed@/log.gz ppc64el: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/ppc64el/l/lxc/20210224_172418_73aab@/log.gz s390x: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/s390x/l/lxc/20210224_164056_06e00@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1917601/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1884024] Re: lxc-test-device-add-remove from ubuntu_lxc failed on B-5.4
This has been fixed a long while ago: commit 920cbb00268ce50d1306daebb74871f66583a46c Author: Christian Brauner Date: Mon Nov 18 15:08:22 2019 +0100 tests: use /dev/loop-control instead of /dev/network_latency BugLink: https://bugs.launchpad.net/bugs/1848587 The latter device has been removed apparently. which is also backported stable-3.0. So Stéphane just needs to cut a new stable point release. ** Changed in: lxc (Ubuntu) Status: New => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1884024 Title: lxc-test-device-add-remove from ubuntu_lxc failed on B-5.4 Status in ubuntu-kernel-tests: New Status in lxc package in Ubuntu: Fix Committed Bug description: Issue found on with 5.4.0-1016.16~18.04.1-oracle on both VM.Standard2.1 and VM.Standard2.16 Test failed with: FAIL: lxc-tests: lxc-test-device-add-remove (1s) --- Adding /dev/network_latency to the container (device_add_remove_test) failed... This issue can be found on oracle : 5.4.0-1011.11~18.04.1 on VM.Standard2.16 but passed on VM.Standard2.1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1884024/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1776381] Re: lxc-test-api-reboot will hang with autopkgtest
Hm, what is the LXC version used here? Is it the one in Bionic? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1776381 Title: lxc-test-api-reboot will hang with autopkgtest Status in ubuntu-kernel-tests: Confirmed Status in lxc package in Ubuntu: New Bug description: Steps: 1. Deploy Bionic on a bare-metal system. 2. Enable deb-src, install the autopkgtest package 3. sudo autopkgtest lxc -- null Result: * The test will hang, a "reboot" lxc container will be created. The last message on the screen will be: make[1]: Entering directory '/tmp/autopkgtest.JxRLRE/build.bSQ/src' make[1]: Nothing to be done for 'all-am'. make[1]: Leaving directory '/tmp/autopkgtest.JxRLRE/build.bSQ/src' * Tried to connect to the "reboot" container with "sudo lxc-console reboot", but nothing there: Connected to tty 1 Type to exit the console, to enter Ctrl+a itself * If you kill the job and run it again, this time the test will go on (fail with the lxc-test-api-reboot test, as the container has already been created) This issue can be reproduced on an amd64 box and a s390x zKVM. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1776381/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1938771] Re: lxc-test-rootfs test regression with 4.0.10-0ubuntu3
Thanks for reporting this. I've fixed this in: https://github.com/lxc/lxc/pull/3921 ** Changed in: lxc (Ubuntu Impish) Status: New => Confirmed ** Changed in: lxc (Ubuntu Impish) Assignee: (unassigned) => Christian Brauner (cbrauner) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1938771 Title: lxc-test-rootfs test regression with 4.0.10-0ubuntu3 Status in lxc package in Ubuntu: Confirmed Status in lxc source package in Impish: Confirmed Bug description: It looks like the option "lxc.rootfs.options = ro" is not honored with lxc 4.0.10-0ubuntu3 and it used to work with lxc 4.0.6-0ubuntu1 (kernel is the same, I'm testing this with 5.13.0-13.13). Output of the test: 09:12 ubuntu@impish$ sudo ./src/tests/lxc-test-rootfs + PHASE=setup + trap cleanup EXIT + lxc-destroy -n lxc-test-rootfs -f lxc-destroy: lxc-test-rootfs: tools/lxc_destroy.c: main: 242 Container is not defined + true + lxc-create -t busybox -n lxc-test-rootfs + PHASE=ro_rootfs + echo 'Starting phase ro_rootfs' Starting phase ro_rootfs + config=/var/lib/lxc/lxc-test-rootfs/config + sed -i /lxc.rootfs.options/d /var/lib/lxc/lxc-test-rootfs/config + echo 'lxc.rootfs.options = ro' + lxc-start -n lxc-test-rootfs ++ lxc-info -n lxc-test-rootfs -p -H + pid=2147 + ro=0 + mkdir /proc/2147/root/rotest + '[' 0 -ne 0 ']' + cleanup + set +e + lxc-destroy -n lxc-test-rootfs -f + '[' ro_rootfs '!=' done ']' + echo 'rootfs test failed at ro_rootfs' rootfs test failed at ro_rootfs + exit 1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1938771/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1938771] Re: lxc-test-rootfs test regression with 4.0.10-0ubuntu3
Also added tests around rootfs mount options. ** Changed in: lxc (Ubuntu Impish) Status: Confirmed => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1938771 Title: lxc-test-rootfs test regression with 4.0.10-0ubuntu3 Status in lxc package in Ubuntu: In Progress Status in lxc source package in Impish: In Progress Bug description: It looks like the option "lxc.rootfs.options = ro" is not honored with lxc 4.0.10-0ubuntu3 and it used to work with lxc 4.0.6-0ubuntu1 (kernel is the same, I'm testing this with 5.13.0-13.13). Output of the test: 09:12 ubuntu@impish$ sudo ./src/tests/lxc-test-rootfs + PHASE=setup + trap cleanup EXIT + lxc-destroy -n lxc-test-rootfs -f lxc-destroy: lxc-test-rootfs: tools/lxc_destroy.c: main: 242 Container is not defined + true + lxc-create -t busybox -n lxc-test-rootfs + PHASE=ro_rootfs + echo 'Starting phase ro_rootfs' Starting phase ro_rootfs + config=/var/lib/lxc/lxc-test-rootfs/config + sed -i /lxc.rootfs.options/d /var/lib/lxc/lxc-test-rootfs/config + echo 'lxc.rootfs.options = ro' + lxc-start -n lxc-test-rootfs ++ lxc-info -n lxc-test-rootfs -p -H + pid=2147 + ro=0 + mkdir /proc/2147/root/rotest + '[' 0 -ne 0 ']' + cleanup + set +e + lxc-destroy -n lxc-test-rootfs -f + '[' ro_rootfs '!=' done ']' + echo 'rootfs test failed at ro_rootfs' rootfs test failed at ro_rootfs + exit 1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1938771/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1938771] Re: lxc-test-rootfs test regression with 4.0.10-0ubuntu3
** Changed in: lxc (Ubuntu Impish) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1938771 Title: lxc-test-rootfs test regression with 4.0.10-0ubuntu3 Status in lxc package in Ubuntu: Fix Committed Status in lxc source package in Impish: Fix Committed Bug description: It looks like the option "lxc.rootfs.options = ro" is not honored with lxc 4.0.10-0ubuntu3 and it used to work with lxc 4.0.6-0ubuntu1 (kernel is the same, I'm testing this with 5.13.0-13.13). Output of the test: 09:12 ubuntu@impish$ sudo ./src/tests/lxc-test-rootfs + PHASE=setup + trap cleanup EXIT + lxc-destroy -n lxc-test-rootfs -f lxc-destroy: lxc-test-rootfs: tools/lxc_destroy.c: main: 242 Container is not defined + true + lxc-create -t busybox -n lxc-test-rootfs + PHASE=ro_rootfs + echo 'Starting phase ro_rootfs' Starting phase ro_rootfs + config=/var/lib/lxc/lxc-test-rootfs/config + sed -i /lxc.rootfs.options/d /var/lib/lxc/lxc-test-rootfs/config + echo 'lxc.rootfs.options = ro' + lxc-start -n lxc-test-rootfs ++ lxc-info -n lxc-test-rootfs -p -H + pid=2147 + ro=0 + mkdir /proc/2147/root/rotest + '[' 0 -ne 0 ']' + cleanup + set +e + lxc-destroy -n lxc-test-rootfs -f + '[' ro_rootfs '!=' done ']' + echo 'rootfs test failed at ro_rootfs' rootfs test failed at ro_rootfs + exit 1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1938771/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1943441] Re: lxc: lxc-test-parse-config-file failure
** Changed in: lxc (Ubuntu) Status: New => Confirmed ** Changed in: lxc (Ubuntu) Status: Confirmed => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1943441 Title: lxc: lxc-test-parse-config-file failure Status in lxc package in Ubuntu: In Progress Bug description: I'm getting the following error with the lxc kernel autotest on impish: 08:46:04 DEBUG| parse_config_file.c: 60: set_get_compare_clear_save_load: expected value "system_u:system_r:lxc_t:s0:c22" and retrieved value "" for config key "lxc.selinux.context" do not match 08:46:04 DEBUG| 08:46:04 DEBUG| parse_config_file.c: 382: main: lxc.selinux.context 08:46:06 INFO | ERRORubuntu_lxc.lxc-test-parse-config-file ubuntu_lxc.lxc-test-parse-config-filetimestamp=1631090766localtime=Sep 08 08:46:06Command failed, rc=1, Command returned non-zero exit status * Command: /tmp/lxc-pkg-ubuntu/src/tests/lxc-test-parse-config-file Exit status: 1 Duration: 0.0550210475922 stderr: parse_config_file.c: 60: set_get_compare_clear_save_load: expected value "system_u:system_r:lxc_t:s0:c22" and retrieved value "" for config key "lxc.selinux.context" do not match parse_config_file.c: 382: main: lxc.selinux.context I haven't investigated very much, but it looks like a (mis)configuration change / issue. Does it ring any bell? Otherwise I'll investigate more. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1943441/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1943441] Re: lxc: lxc-test-parse-config-file failure
This was caused by a recent change to how we handle selinux and apparmor config options when LXC is compiled without support. I've sent https://github.com/lxc/lxc/pull/3969 specific to stable-4.0. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1943441 Title: lxc: lxc-test-parse-config-file failure Status in lxc package in Ubuntu: In Progress Bug description: I'm getting the following error with the lxc kernel autotest on impish: 08:46:04 DEBUG| parse_config_file.c: 60: set_get_compare_clear_save_load: expected value "system_u:system_r:lxc_t:s0:c22" and retrieved value "" for config key "lxc.selinux.context" do not match 08:46:04 DEBUG| 08:46:04 DEBUG| parse_config_file.c: 382: main: lxc.selinux.context 08:46:06 INFO | ERRORubuntu_lxc.lxc-test-parse-config-file ubuntu_lxc.lxc-test-parse-config-filetimestamp=1631090766localtime=Sep 08 08:46:06Command failed, rc=1, Command returned non-zero exit status * Command: /tmp/lxc-pkg-ubuntu/src/tests/lxc-test-parse-config-file Exit status: 1 Duration: 0.0550210475922 stderr: parse_config_file.c: 60: set_get_compare_clear_save_load: expected value "system_u:system_r:lxc_t:s0:c22" and retrieved value "" for config key "lxc.selinux.context" do not match parse_config_file.c: 382: main: lxc.selinux.context I haven't investigated very much, but it looks like a (mis)configuration change / issue. Does it ring any bell? Otherwise I'll investigate more. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1943441/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1831258] Re: journalctl --list-boots does not recognize boots in a container
Several people tried to namespace this but this is really tied to a physical machine so it's kinda tricky to fake. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1831258 Title: journalctl --list-boots does not recognize boots in a container Status in lxd package in Ubuntu: New Status in systemd package in Ubuntu: Invalid Status in lxd source package in Bionic: New Status in systemd source package in Bionic: Invalid Status in lxd source package in Eoan: New Status in systemd source package in Eoan: Invalid Bug description: $ lxc launch ubuntu-daily:eoan devel1 $ sleep 10 # wait for boot $ lxc exec devel1 /bin/bash root@devel1:~# cat /proc/uptime 183.00 173.00 root@devel1:~# cat /etc/cloud/build.info build_name: server serial: 20190531 root@devel1:~# lsb_release -sc eoan root@devel1:~# journalctl --no-pager --list-boots 0 4ecd6fb081964b75b1ddc09baf1be3d9 Fri 2019-05-31 14:58:48 UTC—Fri 2019-05-31 15:06:10 UTC root@devel1:~# reboot root@devel1:~# $ lxc exec devel1 /bin/bash ## verify the reboot happened root@devel1:~# cat /proc/uptime 12.00 6.00 ## but journalctl only shows the same boot it did before. root@devel1:~# journalctl --no-pager --list-boots 0 4ecd6fb081964b75b1ddc09baf1be3d9 Fri 2019-05-31 14:58:48 UTC—Fri 2019-05-31 15:09:10 UTC ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: systemd 240-6ubuntu5 ProcVersionSignature: Ubuntu 4.15.0-50.54-generic 4.15.18 Uname: Linux 4.15.0-50-generic x86_64 ApportVersion: 2.20.11-0ubuntu2 Architecture: amd64 Date: Fri May 31 15:06:24 2019 MachineType: LENOVO 20KGS3Y900 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-50-generic root=UUID=25df9069-80c7-46f4-a47c-305613c2cb6b ro quiet splash vt.handoff=1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/20/2019 dmi.bios.vendor: LENOVO dmi.bios.version: N23ET63W (1.38 ) dmi.board.asset.tag: Not Available dmi.board.name: 20KGS3Y900 dmi.board.vendor: LENOVO dmi.board.version: SDK0J40697 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrN23ET63W(1.38):bd04/20/2019:svnLENOVO:pn20KGS3Y900:pvrThinkPadX1Carbon6th:rvnLENOVO:rn20KGS3Y900:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad X1 Carbon 6th dmi.product.name: 20KGS3Y900 dmi.product.version: ThinkPad X1 Carbon 6th dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1831258/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1831258] Re: journalctl --list-boots does not recognize boots in a container
Fix here: https://github.com/lxc/lxc/pull/3034 ** Changed in: lxd (Ubuntu Bionic) Status: New => In Progress ** Changed in: lxd (Ubuntu Eoan) Status: New => In Progress ** Changed in: systemd (Ubuntu Bionic) Status: Invalid => In Progress ** Changed in: systemd (Ubuntu Eoan) Status: Invalid => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1831258 Title: journalctl --list-boots does not recognize boots in a container Status in lxd package in Ubuntu: In Progress Status in systemd package in Ubuntu: In Progress Status in lxd source package in Bionic: In Progress Status in systemd source package in Bionic: In Progress Status in lxd source package in Eoan: In Progress Status in systemd source package in Eoan: In Progress Bug description: $ lxc launch ubuntu-daily:eoan devel1 $ sleep 10 # wait for boot $ lxc exec devel1 /bin/bash root@devel1:~# cat /proc/uptime 183.00 173.00 root@devel1:~# cat /etc/cloud/build.info build_name: server serial: 20190531 root@devel1:~# lsb_release -sc eoan root@devel1:~# journalctl --no-pager --list-boots 0 4ecd6fb081964b75b1ddc09baf1be3d9 Fri 2019-05-31 14:58:48 UTC—Fri 2019-05-31 15:06:10 UTC root@devel1:~# reboot root@devel1:~# $ lxc exec devel1 /bin/bash ## verify the reboot happened root@devel1:~# cat /proc/uptime 12.00 6.00 ## but journalctl only shows the same boot it did before. root@devel1:~# journalctl --no-pager --list-boots 0 4ecd6fb081964b75b1ddc09baf1be3d9 Fri 2019-05-31 14:58:48 UTC—Fri 2019-05-31 15:09:10 UTC ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: systemd 240-6ubuntu5 ProcVersionSignature: Ubuntu 4.15.0-50.54-generic 4.15.18 Uname: Linux 4.15.0-50-generic x86_64 ApportVersion: 2.20.11-0ubuntu2 Architecture: amd64 Date: Fri May 31 15:06:24 2019 MachineType: LENOVO 20KGS3Y900 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-50-generic root=UUID=25df9069-80c7-46f4-a47c-305613c2cb6b ro quiet splash vt.handoff=1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/20/2019 dmi.bios.vendor: LENOVO dmi.bios.version: N23ET63W (1.38 ) dmi.board.asset.tag: Not Available dmi.board.name: 20KGS3Y900 dmi.board.vendor: LENOVO dmi.board.version: SDK0J40697 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrN23ET63W(1.38):bd04/20/2019:svnLENOVO:pn20KGS3Y900:pvrThinkPadX1Carbon6th:rvnLENOVO:rn20KGS3Y900:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad X1 Carbon 6th dmi.product.name: 20KGS3Y900 dmi.product.version: ThinkPad X1 Carbon 6th dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1831258/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1831258] Re: journalctl --list-boots does not recognize boots in a container
** Also affects: lxc (Ubuntu) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu Bionic) Status: In Progress => Invalid ** Changed in: systemd (Ubuntu Eoan) Status: In Progress => Invalid ** Changed in: lxc (Ubuntu Bionic) Status: New => Incomplete ** Changed in: lxc (Ubuntu Bionic) Status: Incomplete => Fix Committed ** Changed in: lxc (Ubuntu Eoan) Status: New => Fix Committed ** Changed in: lxd (Ubuntu Bionic) Status: In Progress => Invalid ** Changed in: lxd (Ubuntu Eoan) Status: In Progress => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1831258 Title: journalctl --list-boots does not recognize boots in a container Status in lxc package in Ubuntu: Fix Committed Status in lxd package in Ubuntu: Invalid Status in systemd package in Ubuntu: Invalid Status in lxc source package in Bionic: Fix Committed Status in lxd source package in Bionic: Invalid Status in systemd source package in Bionic: Invalid Status in lxc source package in Eoan: Fix Committed Status in lxd source package in Eoan: Invalid Status in systemd source package in Eoan: Invalid Bug description: $ lxc launch ubuntu-daily:eoan devel1 $ sleep 10 # wait for boot $ lxc exec devel1 /bin/bash root@devel1:~# cat /proc/uptime 183.00 173.00 root@devel1:~# cat /etc/cloud/build.info build_name: server serial: 20190531 root@devel1:~# lsb_release -sc eoan root@devel1:~# journalctl --no-pager --list-boots 0 4ecd6fb081964b75b1ddc09baf1be3d9 Fri 2019-05-31 14:58:48 UTC—Fri 2019-05-31 15:06:10 UTC root@devel1:~# reboot root@devel1:~# $ lxc exec devel1 /bin/bash ## verify the reboot happened root@devel1:~# cat /proc/uptime 12.00 6.00 ## but journalctl only shows the same boot it did before. root@devel1:~# journalctl --no-pager --list-boots 0 4ecd6fb081964b75b1ddc09baf1be3d9 Fri 2019-05-31 14:58:48 UTC—Fri 2019-05-31 15:09:10 UTC ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: systemd 240-6ubuntu5 ProcVersionSignature: Ubuntu 4.15.0-50.54-generic 4.15.18 Uname: Linux 4.15.0-50-generic x86_64 ApportVersion: 2.20.11-0ubuntu2 Architecture: amd64 Date: Fri May 31 15:06:24 2019 MachineType: LENOVO 20KGS3Y900 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-50-generic root=UUID=25df9069-80c7-46f4-a47c-305613c2cb6b ro quiet splash vt.handoff=1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/20/2019 dmi.bios.vendor: LENOVO dmi.bios.version: N23ET63W (1.38 ) dmi.board.asset.tag: Not Available dmi.board.name: 20KGS3Y900 dmi.board.vendor: LENOVO dmi.board.version: SDK0J40697 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrN23ET63W(1.38):bd04/20/2019:svnLENOVO:pn20KGS3Y900:pvrThinkPadX1Carbon6th:rvnLENOVO:rn20KGS3Y900:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad X1 Carbon 6th dmi.product.name: 20KGS3Y900 dmi.product.version: ThinkPad X1 Carbon 6th dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1831258/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
Re: [Touch-packages] [Bug 1848587] [NEW] lxc 3.0.4-0ubuntu1 ADT test failure with linux 5.4.0-1.2
Is this a flake or consistently reproducible? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1848587 Title: lxc 3.0.4-0ubuntu1 ADT test failure with linux 5.4.0-1.2 Status in lxc package in Ubuntu: New Bug description: Testing failed on: amd64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-unstable/eoan/amd64/l/lxc/20191016_150939_0f81d@/log.gz arm64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-unstable/eoan/arm64/l/lxc/20191016_152027_0f81d@/log.gz ppc64el: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-unstable/eoan/ppc64el/l/lxc/20191016_150251_0f81d@/log.gz s390x: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-unstable/eoan/s390x/l/lxc/20191016_150201_0f81d@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1848587/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1848587] Re: lxc 3.0.4-0ubuntu1 ADT test failure with linux 5.4.0-1.2
Sorry, mail got lost. Here's a fix: https://github.com/lxc/lxc/pull/3187 ** Changed in: lxc (Ubuntu) Status: Confirmed => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1848587 Title: lxc 3.0.4-0ubuntu1 ADT test failure with linux 5.4.0-1.2 Status in lxc package in Ubuntu: In Progress Bug description: Testing failed on: amd64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-unstable/eoan/amd64/l/lxc/20191016_150939_0f81d@/log.gz arm64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-unstable/eoan/arm64/l/lxc/20191016_152027_0f81d@/log.gz ppc64el: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-unstable/eoan/ppc64el/l/lxc/20191016_150251_0f81d@/log.gz s390x: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-unstable/eoan/s390x/l/lxc/20191016_150201_0f81d@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1848587/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1848587] Re: lxc 3.0.4-0ubuntu1 ADT test failure with linux 5.4.0-1.2
** Changed in: lxc (Ubuntu) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1848587 Title: lxc 3.0.4-0ubuntu1 ADT test failure with linux 5.4.0-1.2 Status in lxc package in Ubuntu: Fix Committed Bug description: Testing failed on: amd64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-unstable/eoan/amd64/l/lxc/20191016_150939_0f81d@/log.gz arm64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-unstable/eoan/arm64/l/lxc/20191016_152027_0f81d@/log.gz ppc64el: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-unstable/eoan/ppc64el/l/lxc/20191016_150251_0f81d@/log.gz s390x: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-unstable/eoan/s390x/l/lxc/20191016_150201_0f81d@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1848587/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1850667] Re: cgroup v2 is not fully supported yet, proceeding with partial confinement
https://github.com/lxc/lxc/issues/3198#issuecomment-562064091 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1850667 Title: cgroup v2 is not fully supported yet, proceeding with partial confinement Status in docker.io package in Ubuntu: New Status in lxc package in Ubuntu: New Status in lxcfs package in Ubuntu: New Status in lxd package in Ubuntu: New Status in snapd package in Ubuntu: In Progress Bug description: Systemd upstream switched the default cgroup hierarchy to unified with v243. This change is reverted by the Ubuntu systemd packages, but as unified is the way to go per upstream support should be added to all relevant Ubuntu packges (and snaps): https://github.com/systemd/systemd/blob/v243/NEWS#L56 * systemd now defaults to the "unified" cgroup hierarchy setup during build-time, i.e. -Ddefault-hierarchy=unified is now the build-time default. Previously, -Ddefault-hierarchy=hybrid was the default. This change reflects the fact that cgroupsv2 support has matured substantially in both systemd and in the kernel, and is clearly the way forward. Downstream production distributions might want to continue to use -Ddefault-hierarchy=hybrid (or even =legacy) for their builds as unfortunately the popular container managers have not caught up with the kernel API changes. Systemd is rebuilt using the new default and is available from the following PPA for testing: https://launchpad.net/~rbalint/+archive/ubuntu/systemd-unified-cgh The autopkgtest results against other packges are available here: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified-cgh/?format=plain https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-focal-rbalint-systemd-unified-cgh/?format=plain lxc autopkgtest failing: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified- cgh/eoan/amd64/d/docker.io/20191030_155944_2331e@/log.gz snapd autopkgtest failing: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified- cgh/eoan/amd64/s/snapd/20191030_161354_94b26@/log.gz docker.io autopkgtest failing: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified- cgh/eoan/amd64/d/docker.io/20191030_155944_2331e@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1850667/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1855513] Re: log file
** Changed in: lxc (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1855513 Title: log file Status in lxc package in Ubuntu: Invalid Bug description: required log and cli bash To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1855513/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
Re: [Touch-packages] [Bug 1850667] Re: cgroup v2 is not fully supported yet, proceeding with partial confinement
On Mon, Dec 09, 2019 at 08:41:18PM -, Ryutaroh Matsumoto wrote: > https://github.com/lxc/lxc/issues/3221 Another LXC-container-doesn't > -start-at-all type issue also observed on Ubuntu Eoan with > systemd.unified_cgroup_hierarchy as well as Fedora 31. That seems specific to LXC stable-3.0 which had barebone unified hierarchy support to deal with systemd hyrbid cgroup layouts. However the changes to git master which enable full cgroup2 compatibility have been backported to the stable-3.0 branch and will be released with the next bugfix release. In other words, the start-at-all on a pure unified layout with 3.0.4 is expected unfortunately. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1850667 Title: cgroup v2 is not fully supported yet, proceeding with partial confinement Status in docker.io package in Ubuntu: New Status in lxc package in Ubuntu: New Status in lxcfs package in Ubuntu: New Status in lxd package in Ubuntu: New Status in snapd package in Ubuntu: In Progress Bug description: Systemd upstream switched the default cgroup hierarchy to unified with v243. This change is reverted by the Ubuntu systemd packages, but as unified is the way to go per upstream support should be added to all relevant Ubuntu packges (and snaps): https://github.com/systemd/systemd/blob/v243/NEWS#L56 * systemd now defaults to the "unified" cgroup hierarchy setup during build-time, i.e. -Ddefault-hierarchy=unified is now the build-time default. Previously, -Ddefault-hierarchy=hybrid was the default. This change reflects the fact that cgroupsv2 support has matured substantially in both systemd and in the kernel, and is clearly the way forward. Downstream production distributions might want to continue to use -Ddefault-hierarchy=hybrid (or even =legacy) for their builds as unfortunately the popular container managers have not caught up with the kernel API changes. Systemd is rebuilt using the new default and is available from the following PPA for testing: https://launchpad.net/~rbalint/+archive/ubuntu/systemd-unified-cgh The autopkgtest results against other packges are available here: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified-cgh/?format=plain https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-focal-rbalint-systemd-unified-cgh/?format=plain lxc autopkgtest failing: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified- cgh/eoan/amd64/d/docker.io/20191030_155944_2331e@/log.gz snapd autopkgtest failing: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified- cgh/eoan/amd64/s/snapd/20191030_161354_94b26@/log.gz docker.io autopkgtest failing: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified- cgh/eoan/amd64/d/docker.io/20191030_155944_2331e@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1850667/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1858799] Re: lxc ADT test failure on Bionic with linux-raspi2-5.3 arm64
This might be caused by changes to busybox since this looks like it's testing liblxc-3.0.4. In any case, I believe that the following commit in the stable-3.0 tree would fix it: https://github.com/lxc/lxc/commit/3daa49d845b153dfb2012b61dba763cbc6e11374 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1858799 Title: lxc ADT test failure on Bionic with linux-raspi2-5.3 arm64 Status in lxc package in Ubuntu: New Status in lxc source package in Bionic: New Bug description: On Bionic with linux-raspi2-5.3 arm64: PASS: lxc-tests: lxc-test-api-reboot (78s) PASS: lxc-tests: lxc-test-apparmor (1s) PASS: lxc-tests: lxc-test-apparmor-mount (52s) PASS: lxc-tests: lxc-test-attach (3s) PASS: lxc-tests: lxc-test-autostart (68s) PASS: lxc-tests: lxc-test-basic (0s) FAIL: lxc-tests: lxc-test-cgpath (1s) --- /usr/share/lxc/templates/lxc-busybox: 143: cannot create /var/lib/lxc/lxctest1/rootfs/: Is a directory cgpath.c:91 cgroup_get failed --- PASS: lxc-tests: lxc-test-checkpoint-restore (0s) PASS: lxc-tests: lxc-test-cloneconfig (8s) PASS: lxc-tests: lxc-test-clonetest (2s) PASS: lxc-tests: lxc-test-concurrent (7s) PASS: lxc-tests: lxc-test-config-jump-table (1s) PASS: lxc-tests: lxc-test-console (3s) PASS: lxc-tests: lxc-test-console-log (10s) PASS: lxc-tests: lxc-test-containertests (5s) PASS: lxc-tests: lxc-test-createtest (1s) PASS: lxc-tests: lxc-test-criu-check-feature (0s) PASS: lxc-tests: lxc-test-cve-2019-5736 (4s) PASS: lxc-tests: lxc-test-destroytest (4s) PASS: lxc-tests: lxc-test-device-add-remove (3s) PASS: lxc-tests: lxc-test-get_item (2s) PASS: lxc-tests: lxc-test-getkeys (0s) PASS: lxc-tests: lxc-test-list (0s) PASS: lxc-tests: lxc-test-locktests (3s) PASS: lxc-tests: lxc-test-lxc-attach (4s) PASS: lxc-tests: lxc-test-lxcpath (0s) PASS: lxc-tests: lxc-test-no-new-privs (66s) PASS: lxc-tests: lxc-test-parse-config-file (0s) PASS: lxc-tests: lxc-test-raw-clone (0s) PASS: lxc-tests: lxc-test-reboot (0s) PASS: lxc-tests: lxc-test-rootfs (2s) PASS: lxc-tests: lxc-test-saveconfig (1s) PASS: lxc-tests: lxc-test-share-ns (144s) PASS: lxc-tests: lxc-test-shortlived (9s) PASS: lxc-tests: lxc-test-shutdowntest (26s) PASS: lxc-tests: lxc-test-snapshot (2s) PASS: lxc-tests: lxc-test-startone (5s) IGNORED: lxc-tests: lxc-test-state-server PASS: lxc-tests: lxc-test-symlink (2s) PASS: lxc-tests: lxc-test-unpriv (29s) PASS: lxc-tests: lxc-test-utils (0s) Removing 'local diversion of /usr/bin/dirmngr to /usr/bin/dirmngr.orig' SUMMARY: pass=39, fail=1, ignored=1 autopkgtest [20:47:46]: test exercise: ---] autopkgtest [20:47:48]: test exercise: - - - - - - - - - - results - - - - - - - - - - exercise FAIL non-zero exit status 1 autopkgtest [20:47:49]: summary exercise FAIL non-zero exit status 1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1858799/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1635382] Re: PrivateNetwork=yes (hostnamed, localed) does not work in lxd
What? That's totally possible. Simply try unshare -n inside an unprivileged container as root. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1635382 Title: PrivateNetwork=yes (hostnamed, localed) does not work in lxd Status in systemd package in Ubuntu: Triaged Bug description: $ lxc launch ubuntu-daily:yakkety y-hostname1 $ sleep 10 $ lxc exec y-hostname1 -- hostnamectl set-hostname smoser Could not set property: Connection timed out $ lxc exec y-hostname1 -- systemctl status --no-pager -l systemd-hostnamed ● systemd-hostnamed.service - Hostname Service Loaded: loaded (/lib/systemd/system/systemd-hostnamed.service; static; vendor preset: enabled) Active: failed (Result: exit-code) since Thu 2016-10-20 19:19:16 UTC; 1min 9s ago Docs: man:systemd-hostnamed.service(8) man:hostname(5) man:machine-info(5) http://www.freedesktop.org/wiki/Software/systemd/hostnamed Process: 561 ExecStart=/lib/systemd/systemd-hostnamed (code=exited, status=225/NETWORK) Main PID: 561 (code=exited, status=225/NETWORK) Oct 20 19:19:16 y-hostname1 systemd[1]: Starting Hostname Service... Oct 20 19:19:16 y-hostname1 systemd[1]: systemd-hostnamed.service: Main process exited, code=exited, status=225/NETWORK Oct 20 19:19:16 y-hostname1 systemd[1]: Failed to start Hostname Service. Oct 20 19:19:16 y-hostname1 systemd[1]: systemd-hostnamed.service: Unit entered failed state. Oct 20 19:19:16 y-hostname1 systemd[1]: systemd-hostnamed.service: Failed with result 'exit-code'. ProblemType: Bug DistroRelease: Ubuntu 16.10 Package: systemd 231-9git1 ProcVersionSignature: Ubuntu 4.8.0-22.24-generic 4.8.0 Uname: Linux 4.8.0-22-generic x86_64 ApportVersion: 2.20.3-0ubuntu8 Architecture: amd64 Date: Thu Oct 20 19:02:29 2016 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.8.0-22-generic.efi.signed root=UUID=f897b32a-eacf-4191-9717-844918947069 ro quiet splash vt.handoff=7 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.vendor: Intel Corporation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1635382/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1770481] [NEW] core: fall back to bind-mounts for PrivateDevices= execution environments
Public bug reported: Hey, Currently any service that has PrivateDevices=true set will fail to start in unprivileged containers since mknod is not possible and in privileged containers that drop CAP_MKNOD. I pushed a patch to systemd upstream that solves this problem and makes PrivateDevices useable in both scenarios. It would be great if this could be backported to Ubuntu 16.04 and 18.04. We already have a lot of users that would like this feature enabled/don't want to edit each service file: 16498617443da94533ef9ae28be0ffaace40c526 : https://github.com/systemd/systemd/commit/af984e137e7f53ca3e2fd885b03a25e17fdd0fad af984e137e7f53ca3e2fd885b03a25e17fdd0fad : https://github.com/systemd/systemd/commit/16498617443da94533ef9ae28be0ffaace40c526 Thanks! Christian ** Affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1770481 Title: core: fall back to bind-mounts for PrivateDevices= execution environments Status in systemd package in Ubuntu: New Bug description: Hey, Currently any service that has PrivateDevices=true set will fail to start in unprivileged containers since mknod is not possible and in privileged containers that drop CAP_MKNOD. I pushed a patch to systemd upstream that solves this problem and makes PrivateDevices useable in both scenarios. It would be great if this could be backported to Ubuntu 16.04 and 18.04. We already have a lot of users that would like this feature enabled/don't want to edit each service file: 16498617443da94533ef9ae28be0ffaace40c526 : https://github.com/systemd/systemd/commit/af984e137e7f53ca3e2fd885b03a25e17fdd0fad af984e137e7f53ca3e2fd885b03a25e17fdd0fad : https://github.com/systemd/systemd/commit/16498617443da94533ef9ae28be0ffaace40c526 Thanks! Christian To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1770481/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1770481] Re: core: fall back to bind-mounts for PrivateDevices= execution environments
We just had a short discussion on systemd and for systemd 229 on 16.04 we also need: 9e5f825280192be429cc79153235d12778427fae : https://github.com/systemd/systemd/commit/9e5f825280192be429cc79153235d12778427fae -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1770481 Title: core: fall back to bind-mounts for PrivateDevices= execution environments Status in systemd package in Ubuntu: New Bug description: Hey, Currently any service that has PrivateDevices=true set will fail to start in unprivileged containers since mknod is not possible and in privileged containers that drop CAP_MKNOD. I pushed a patch to systemd upstream that solves this problem and makes PrivateDevices useable in both scenarios. It would be great if this could be backported to Ubuntu 16.04 and 18.04. We already have a lot of users that would like this feature enabled/don't want to edit each service file: 16498617443da94533ef9ae28be0ffaace40c526 : https://github.com/systemd/systemd/commit/af984e137e7f53ca3e2fd885b03a25e17fdd0fad af984e137e7f53ca3e2fd885b03a25e17fdd0fad : https://github.com/systemd/systemd/commit/16498617443da94533ef9ae28be0ffaace40c526 Thanks! Christian To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1770481/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1734410] Re: systemd: handle undelegated cgroup2 hierarchy
** Tags removed: verification-needed verification-needed-artful ** Tags added: verification-done-artful -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1734410 Title: systemd: handle undelegated cgroup2 hierarchy Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Confirmed Status in systemd source package in Zesty: Won't Fix Status in systemd source package in Artful: Fix Committed Status in systemd source package in Bionic: Fix Released Bug description: [Impact] * When a container is presented with a unified cgroup hierarchy, which is not properly delegated, systemd should not attempt (and fail) to use. This improves compatibility of xenial containers running on unified cgroup hierarchy hosts. [Test Case] * Xenial containers should boot, with non-writable unified cgroup hierarchy hosts. [Regression Potential] * unified cgroup hierarchy is not in use by default on xenial hosts, thus this is forward compatibility improvment with e.g. bionic hosts running xenial containers. [Other Info] * Original bug report Hey everyone, Current systemd versions all fail when the unified cgroup hierarchy is not-writable. This is especially problematic in containers where the systemd administrator might decide to not delegate the unified hierarchy or when running with a liblxc driver that doesn't yet know how to handle the unified cgroup hierarchy. I've pushed patches to systemd upstream that let systemd ingnore the non-delegated unified hierarchy. The relevant commits are: e07aefbd675b651f8d45b5fb458f2747b04d6e04 2d56b80a1855836abf1d7458394c345ad9d55382 1ff654e28b7b8e7d0a0be33522a84069ac6b07c0 These patches will be in 236 but should be backported from xenial upwards. Christian To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1734410/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1734410] Re: systemd: handle undelegated cgroup2 hierarchy
Sorry for the brevity before. I tested this with systemd 23{5,6}
inside xenial and artful containers which is really the only case
where it matters.
A systemd with my patch applied would happily:
1. skip over undelegated /sys/fs/cgroup/unified mountpoints
(e07aefbd675b651f8d45b5fb458f2747b04d6e04).
2. skip over undelegated pur cgroup2 mountpoints at /sys/fs/cgroup
(2d56b80a1855836abf1d7458394c345ad9d55382)
3. remove any empty mountpoints created for case 1. and 2.
(1ff654e28b7b8e7d0a0be33522a84069ac6b07c0)
Thanks for backporting these patches!
Christian
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1734410
Title:
systemd: handle undelegated cgroup2 hierarchy
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Xenial:
Confirmed
Status in systemd source package in Zesty:
Won't Fix
Status in systemd source package in Artful:
Fix Released
Status in systemd source package in Bionic:
Fix Released
Bug description:
[Impact]
* When a container is presented with a unified cgroup hierarchy,
which is not properly delegated, systemd should not attempt (and fail)
to use. This improves compatibility of xenial containers running on
unified cgroup hierarchy hosts.
[Test Case]
* Xenial containers should boot, with non-writable unified cgroup
hierarchy hosts.
[Regression Potential]
* unified cgroup hierarchy is not in use by default on xenial hosts,
thus this is forward compatibility improvment with e.g. bionic hosts
running xenial containers.
[Other Info]
* Original bug report
Hey everyone,
Current systemd versions all fail when the unified cgroup hierarchy is
not-writable. This is especially problematic in containers where the
systemd administrator might decide to not delegate the unified
hierarchy or when running with a liblxc driver that doesn't yet know
how to handle the unified cgroup hierarchy. I've pushed patches to
systemd upstream that let systemd ingnore the non-delegated unified
hierarchy. The relevant commits are:
e07aefbd675b651f8d45b5fb458f2747b04d6e04
2d56b80a1855836abf1d7458394c345ad9d55382
1ff654e28b7b8e7d0a0be33522a84069ac6b07c0
These patches will be in 236 but should be backported from xenial
upwards.
Christian
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1734410/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1757470] Re: apport autopkgtests broken (valgrind error) LXC regression?
Can we get some logs for the LXC containers that created and fail? Otherwise this is very much a black box. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/1757470 Title: apport autopkgtests broken (valgrind error) LXC regression? Status in apport package in Ubuntu: New Status in lxc package in Ubuntu: New Bug description: --- Testing apport_valgrind --- test_help_display (__main__.T) help display ... ok test_intentional_mem_leak_detection (__main__.T) apport-valgrind log reports intentional memory leak ... ok test_invalid_args (__main__.T) return code is not 0 when invalid args are passed ... ok test_sandbox_cache_options (__main__.T) apport-valgrind creates a user specified sandbox and cache ... WARNING: /lib/x86_64-linux-gnu/libc.so.6 is needed, but cannot be mapped to a package ERROR: Cannot find package which ships ExecutablePath /bin/true Interrupted while creating sandbox ERROR test_unpackaged_exe (__main__.T) apport-valgrind creates valgrind log on unpackaged executable ... /tmp/autopkgtest.aOT0xm/autopkgtest_tmp/apport-tests ok test_valgrind_min_installed (__main__.T) valgrind is installed and recent enough ... ok test_vlog_created (__main__.T) apport-valgrind creates valgrind.log with expected content ... ok == ERROR: test_sandbox_cache_options (__main__.T) apport-valgrind creates a user specified sandbox and cache -- Traceback (most recent call last): File "./test_apport_valgrind.py", line 143, in test_sandbox_cache_options subprocess.check_call(cmd) File "/usr/lib/python3.6/subprocess.py", line 291, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '['apport-valgrind', '--sandbox-dir', '/tmp/tmpbvxep0y2/test-sandbox', '--cache', '/tmp/tmpbvxep0y2/test-cache', 'true']' returned non-zero exit status 1. -- Ran 7 tests in 30.319s FAILED (errors=1) --- Testing backend_apt_dpkg --- the regression seems to indicate a coreutils installation issue apport-valgrind creates a user specified sandbox and cache ... Installing extra package coreutils to get ExecutablePath Sandbox directory: /tmp/tmpoytew5vn/test-sandbox Cache directory: /tmp/tmpoytew5vn/test-cache ok To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1757470/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1758380] Re: unpriveleged containers no longer could start due to start.c: lxc_spawn: 1555 Failed initializing cgroup support
** Changed in: lxc (Ubuntu) Status: New => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1758380 Title: unpriveleged containers no longer could start due to start.c: lxc_spawn: 1555 Failed initializing cgroup support Status in lxc package in Ubuntu: Fix Committed Bug description: After upgrade from xenial to bionic (beta) I no longer could start unpriveleged containers, they failed with following message: lxc-start: test: start.c: lxc_spawn: 1555 Failed initializing cgroup support lxc-start: test: start.c: __lxc_start: 1868 Failed to spawn container "test" The container failed to start. Additional information can be obtained by setting the --logfile and --logpriority options. Moreover, I could see this in auth log: Mar 23 18:21:46 host sudo: PAM unable to dlopen(pam_cgfs.so): /lib/security/pam_cgfs.so: cannot open shared object file: No such file or directory Mar 23 18:21:46 host sudo: PAM adding faulty module: pam_cgfs.so I have installed libpam-cgfs, but it provides only /lib/x86_64-linux- gnu/security/pam_cgfs.so Moreover, if I create a symlink from /lib/security/pam_cgfs.so to /lib/x86_64-linux-gnu/security/pam_cgfs.so it fails with follwing message: PAM unable to dlopen(pam_cgfs.so): /lib/security/pam_cgfs.so: undefined symbol: file_exists ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: lxc 3.0.0~beta2-0ubuntu2 ProcVersionSignature: Ubuntu 4.15.0-12.13-generic 4.15.7 Uname: Linux 4.15.0-12-generic x86_64 ApportVersion: 2.20.8-0ubuntu10 Architecture: amd64 CurrentDesktop: X-Cinnamon Date: Fri Mar 23 18:20:38 2018 DistributionChannelDescriptor: # This is a distribution channel descriptor # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor canonical-oem-somerville-xenial-amd64-20160624-2 EcryptfsInUse: Yes InstallationDate: Installed on 2017-06-22 (274 days ago) InstallationMedia: Ubuntu 16.04 "Xenial" - Build amd64 LIVE Binary 20160624-10:47 PackageArchitecture: all SourcePackage: lxc UpgradeStatus: No upgrade log present (probably fresh install) defaults.conf: lxc.net.0.type = veth lxc.net.0.link = lxcbr0 lxc.net.0.flags = up lxc.net.0.hwaddr = 00:16:3e:xx:xx:xx To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1758380/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1755250] Re: backport statx syscall whitelist fix
This is indeed pretty important for some use-cases so we should try to come up with a reasonable solution. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1755250 Title: backport statx syscall whitelist fix Status in docker.io package in Ubuntu: New Status in libseccomp package in Ubuntu: New Bug description: Hello maintainer, The docker version 17.03 (bionic) in ubuntu doesn't allow the statx syscall which is needed to build qt >=5.10 applications: https://github.com/docker/for-linux/issues/208#issuecomment-372400859 Could this fix be backported in the ubuntu package ? https://github.com/moby/moby/pull/36417 regards, xan. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1755250/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
Re: [Touch-packages] [Bug 1776381] Re: lxc-test-api-reboot will hang with autopkgtest
On Tue, Jun 12, 2018 at 12:46 PM, Free Ekanayaka wrote: > It might be a duplicate of https://github.com/lxc/lxd/issues/4485 (which > is fixed in 3.0.1, now in -proposed I believe). This is a LXC integration test that is failing, not a LXD one. :) > > We'd need to see the logs of the LXD daemon to really tell, though. > > ** Bug watch added: LXD bug tracker #4485 >https://github.com/lxc/lxd/issues/4485 > > -- > You received this bug notification because you are a member of Ubuntu > containers team, which is subscribed to lxc in Ubuntu. > Matching subscriptions: lxc > https://bugs.launchpad.net/bugs/1776381 > > Title: > lxc-test-api-reboot will hang with autopkgtest > > Status in lxc package in Ubuntu: > New > > Bug description: > Steps: > 1. Deploy Bionic on a bare-metal system. > 2. Enable deb-src, install the autopkgtest package > 3. sudo autopkgtest lxc -- null > > Result: > * The test will hang, a "reboot" lxc container will be created. The last > message on the screen will be: > make[1]: Entering directory '/tmp/autopkgtest.JxRLRE/build.bSQ/src' > make[1]: Nothing to be done for 'all-am'. > make[1]: Leaving directory '/tmp/autopkgtest.JxRLRE/build.bSQ/src' > * Tried to connect to the "reboot" container with "sudo lxc-console > reboot", but nothing there: > Connected to tty 1 > Type to exit the console, to enter Ctrl+a > itself > * If you kill the job and run it again, this time the test will go on > (fail with the lxc-test-api-reboot test, as the container has already been > created) > > This issue can be reproduced on an amd64 box and a s390x zKVM. > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1776381/+subscriptions -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1776381 Title: lxc-test-api-reboot will hang with autopkgtest Status in lxc package in Ubuntu: New Bug description: Steps: 1. Deploy Bionic on a bare-metal system. 2. Enable deb-src, install the autopkgtest package 3. sudo autopkgtest lxc -- null Result: * The test will hang, a "reboot" lxc container will be created. The last message on the screen will be: make[1]: Entering directory '/tmp/autopkgtest.JxRLRE/build.bSQ/src' make[1]: Nothing to be done for 'all-am'. make[1]: Leaving directory '/tmp/autopkgtest.JxRLRE/build.bSQ/src' * Tried to connect to the "reboot" container with "sudo lxc-console reboot", but nothing there: Connected to tty 1 Type to exit the console, to enter Ctrl+a itself * If you kill the job and run it again, this time the test will go on (fail with the lxc-test-api-reboot test, as the container has already been created) This issue can be reproduced on an amd64 box and a s390x zKVM. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1776381/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
Re: [Touch-packages] [Bug 1776381] Re: lxc-test-api-reboot will hang with autopkgtest
On Tue, Jun 12, 2018 at 8:39 AM, Po-Hsu Lin wrote: > If you leave it there for a long period, it will time out in the end: > make[1]: Leaving directory '/tmp/autopkgtest.ZiY11u/build.Nic/src' > FAIL: lxc-tests: lxc-test-api-reboot (9845s) The API reboot tests will hang indefinitely if the container fails to reboot properly. This can happen for a variety of reasons. The most likely are that the container in question does either not have its signal handlers set up correctly at the time it receives the reboot signal or that this is a broken busybox implementation that doesn't correctly handle reboots. > --- > Terminated > --- > > Session terminated, terminating shell...bash: line 1: 15305 Terminated > /tmp/autopkgtest.ZiY11u/build.Nic/src/debian/tests/exercise 2> >(tee -a > /tmp/autopkgtest.ZiY11u/exercise-stderr >&2) > >(tee -a > /tmp/autopkgtest.ZiY11u/exercise-stdout) > ...terminated. > autopkgtest [06:26:24]: ERROR: timed out on command "su -s /bin/bash root -c > set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 || true; . > ~/.profile >/dev/null 2>&1 || true; > buildtree="/tmp/autopkgtest.ZiY11u/build.Nic/src"; mkdir -p -m 1777 -- > "/tmp/autopkgtest.ZiY11u/exercise-artifacts"; export > AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest.ZiY11u/exercise-artifacts"; export > ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755 > "/tmp/autopkgtest.ZiY11u/autopkgtest_tmp"; export > AUTOPKGTEST_TMP="/tmp/autopkgtest.ZiY11u/autopkgtest_tmp"; export > ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive; export > LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=16; unset LANGUAGE LC_CTYPE > LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES LC_PAPER LC_NAME > LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT LC_IDENTIFICATION LC_ALL;rm -f > /tmp/autopkgtest_script_pid; set -C; echo $$ > /tmp/autopkgtest_script_pid; > set +C; trap "rm -f /tmp/autopkgtest_script_pid" EXIT INT QUIT PIPE; cd > "$buildtree"; export AUTOPKGTEST_NORMAL_USER=; export ADT_NORMAL_USER=; chmod > +x /tmp/autopkgtest.ZiY11u/build.Nic/src/debian/tests/exercise; touch > /tmp/autopkgtest.ZiY11u/exercise-stdout > /tmp/autopkgtest.ZiY11u/exercise-stderr; > /tmp/autopkgtest.ZiY11u/build.Nic/src/debian/tests/exercise 2> >(tee -a > /tmp/autopkgtest.ZiY11u/exercise-stderr >&2) > >(tee -a > /tmp/autopkgtest.ZiY11u/exercise-stdout);" (kind: test) > autopkgtest [06:26:24]: test exercise: ---] > autopkgtest [06:26:24]: test exercise: - - - - - - - - - - results - - - - - > - - - - - > exercise FAIL timed out > autopkgtest [06:26:24]: summary > exercise FAIL timed out > > -- > You received this bug notification because you are a member of Ubuntu > containers team, which is subscribed to lxc in Ubuntu. > Matching subscriptions: lxc > https://bugs.launchpad.net/bugs/1776381 > > Title: > lxc-test-api-reboot will hang with autopkgtest > > Status in lxc package in Ubuntu: > New > > Bug description: > Steps: > 1. Deploy Bionic on a bare-metal system. > 2. Enable deb-src, install the autopkgtest package > 3. sudo autopkgtest lxc -- null > > Result: > * The test will hang, a "reboot" lxc container will be created. The last > message on the screen will be: > make[1]: Entering directory '/tmp/autopkgtest.JxRLRE/build.bSQ/src' > make[1]: Nothing to be done for 'all-am'. > make[1]: Leaving directory '/tmp/autopkgtest.JxRLRE/build.bSQ/src' > * Tried to connect to the "reboot" container with "sudo lxc-console > reboot", but nothing there: > Connected to tty 1 > Type to exit the console, to enter Ctrl+a > itself > * If you kill the job and run it again, this time the test will go on > (fail with the lxc-test-api-reboot test, as the container has already been > created) > > This issue can be reproduced on an amd64 box and a s390x zKVM. > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1776381/+subscriptions -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1776381 Title: lxc-test-api-reboot will hang with autopkgtest Status in lxc package in Ubuntu: New Bug description: Steps: 1. Deploy Bionic on a bare-metal system. 2. Enable deb-src, install the autopkgtest package 3. sudo autopkgtest lxc -- null Result: * The test will hang, a "reboot" lxc container will be created. The last message on the screen will be: make[1]: Entering directory '/tmp/autopkgtest.JxRLRE/build.bSQ/src' make[1]: Nothing to be done for 'all-am'. make[1]: Leaving directory '/tmp/autopkgtest.JxRLRE/build.bSQ/src' * Tried to connect to the "reboot" container with "sudo lxc-console reboot", but nothing there: Connected to tty 1 Type to exit the console, to enter Ctrl+a itself * I
Re: [Touch-packages] [Bug 1776381] Re: lxc-test-api-reboot will hang with autopkgtest
On Thu, Jun 14, 2018 at 04:19:39AM -, Po-Hsu Lin wrote: > Is there anything that I can do for debugging this? Hm, you could try manually creating a busybox container and trying to: - shut it down - reboot it with lxc-stop Christian -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1776381 Title: lxc-test-api-reboot will hang with autopkgtest Status in lxc package in Ubuntu: New Bug description: Steps: 1. Deploy Bionic on a bare-metal system. 2. Enable deb-src, install the autopkgtest package 3. sudo autopkgtest lxc -- null Result: * The test will hang, a "reboot" lxc container will be created. The last message on the screen will be: make[1]: Entering directory '/tmp/autopkgtest.JxRLRE/build.bSQ/src' make[1]: Nothing to be done for 'all-am'. make[1]: Leaving directory '/tmp/autopkgtest.JxRLRE/build.bSQ/src' * Tried to connect to the "reboot" container with "sudo lxc-console reboot", but nothing there: Connected to tty 1 Type to exit the console, to enter Ctrl+a itself * If you kill the job and run it again, this time the test will go on (fail with the lxc-test-api-reboot test, as the container has already been created) This issue can be reproduced on an amd64 box and a s390x zKVM. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1776381/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1575779] Re: hostnamectl fails under lxd unpriv container
Hey, so we're seeing an instance of this issue and the problem is that a lock is taken on an fd instead of a path. This should be legal and we urgently need a fix for this since this is starting to break all systemd services running in a container that use PrivateUsers= and anything else that hits the following codepath: if (lockf(netns_storage_socket[0], F_LOCK, 0) < 0) return -errno; in systemd. ** Changed in: apparmor (Ubuntu) Status: Triaged => Confirmed ** Changed in: apparmor (Ubuntu) Importance: High => Critical -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1575779 Title: hostnamectl fails under lxd unpriv container Status in apparmor package in Ubuntu: Confirmed Bug description: 1. % lsb_release -rd Description: Ubuntu 16.04 LTS Release: 16.04 2. % apt-cache policy apparmor apparmor: Installed: 2.10.95-0ubuntu2 Candidate: 2.10.95-0ubuntu2 Version table: *** 2.10.95-0ubuntu2 500 500 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages 100 /var/lib/dpkg/status % apt-cache policy lxd lxd: Installed: 2.0.0-0ubuntu4 Candidate: 2.0.0-0ubuntu4 Version table: *** 2.0.0-0ubuntu4 500 500 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages 100 /var/lib/dpkg/status 3. lxc launch ubuntu-daily:xenial x1 lxc exec x1 /bin/bash root@x1:~# hostnamectl status Static hostname: x1 Icon name: computer-container Chassis: container Machine ID: 833b8548c7ce4118b4c9c5c3ae4f133d Boot ID: 9d5fbb053cf7494589c0863a0a4cf0ca Virtualization: lxc Operating System: Ubuntu 16.04 LTS Kernel: Linux 4.4.0-18-generic Architecture: x86-64 4. hostnamectl status hangs indefinitely On the host, there are some audit messages for each invocation of hostnamectl [411617.032274] audit: type=1400 audit(1461695563.731:100): apparmor="DENIED" operation="file_lock" profile="lxd- x1_" pid=17100 comm="(ostnamed)" family="unix" sock_type="dgram" protocol=0 addr=none It's related to socket activation. One can workaround this by running systemd-hostnamed in the background first root@x1:~# /lib/systemd/systemd-hostnamed & [1] 2462 root@x1:~# hostnamectl status Static hostname: x1 Icon name: computer-container Chassis: container Machine ID: 833b8548c7ce4118b4c9c5c3ae4f133d Boot ID: 9d5fbb053cf7494589c0863a0a4cf0ca Virtualization: lxc Operating System: Ubuntu 16.04 LTS Kernel: Linux 4.4.0-18-generic Architecture: x86-64 ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: apparmor 2.10.95-0ubuntu2 ProcVersionSignature: Ubuntu 4.4.0-18.34-generic 4.4.6 Uname: Linux 4.4.0-18-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2 Architecture: amd64 CurrentDesktop: GNOME-Flashback:GNOME Date: Wed Apr 27 11:19:27 2016 InstallationDate: Installed on 2016-01-01 (117 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20151209) ProcKernelCmdline: BOOT_IMAGE=/boot/vmlinuz-4.4.0-18-generic root=UUID=e0b8b294-f364-4ef5-aa70-1916cdd37192 ro quiet splash vt.handoff=7 SourcePackage: apparmor Syslog: UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1575779/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1575779] Re: hostnamectl fails under lxd unpriv container
So, the good news is that this is all fixed upstream starting with 4.17 with the socket mediation patchset that got merged a short while ago. The bad news is that we need to get this patchset backported and it is quite large: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=80a17a5f501ea048d86f81d629c94062b76610d4 ** Changed in: apparmor (Ubuntu) Status: Confirmed => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1575779 Title: hostnamectl fails under lxd unpriv container Status in apparmor package in Ubuntu: Fix Committed Bug description: 1. % lsb_release -rd Description: Ubuntu 16.04 LTS Release: 16.04 2. % apt-cache policy apparmor apparmor: Installed: 2.10.95-0ubuntu2 Candidate: 2.10.95-0ubuntu2 Version table: *** 2.10.95-0ubuntu2 500 500 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages 100 /var/lib/dpkg/status % apt-cache policy lxd lxd: Installed: 2.0.0-0ubuntu4 Candidate: 2.0.0-0ubuntu4 Version table: *** 2.0.0-0ubuntu4 500 500 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages 100 /var/lib/dpkg/status 3. lxc launch ubuntu-daily:xenial x1 lxc exec x1 /bin/bash root@x1:~# hostnamectl status Static hostname: x1 Icon name: computer-container Chassis: container Machine ID: 833b8548c7ce4118b4c9c5c3ae4f133d Boot ID: 9d5fbb053cf7494589c0863a0a4cf0ca Virtualization: lxc Operating System: Ubuntu 16.04 LTS Kernel: Linux 4.4.0-18-generic Architecture: x86-64 4. hostnamectl status hangs indefinitely On the host, there are some audit messages for each invocation of hostnamectl [411617.032274] audit: type=1400 audit(1461695563.731:100): apparmor="DENIED" operation="file_lock" profile="lxd- x1_" pid=17100 comm="(ostnamed)" family="unix" sock_type="dgram" protocol=0 addr=none It's related to socket activation. One can workaround this by running systemd-hostnamed in the background first root@x1:~# /lib/systemd/systemd-hostnamed & [1] 2462 root@x1:~# hostnamectl status Static hostname: x1 Icon name: computer-container Chassis: container Machine ID: 833b8548c7ce4118b4c9c5c3ae4f133d Boot ID: 9d5fbb053cf7494589c0863a0a4cf0ca Virtualization: lxc Operating System: Ubuntu 16.04 LTS Kernel: Linux 4.4.0-18-generic Architecture: x86-64 ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: apparmor 2.10.95-0ubuntu2 ProcVersionSignature: Ubuntu 4.4.0-18.34-generic 4.4.6 Uname: Linux 4.4.0-18-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2 Architecture: amd64 CurrentDesktop: GNOME-Flashback:GNOME Date: Wed Apr 27 11:19:27 2016 InstallationDate: Installed on 2016-01-01 (117 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20151209) ProcKernelCmdline: BOOT_IMAGE=/boot/vmlinuz-4.4.0-18-generic root=UUID=e0b8b294-f364-4ef5-aa70-1916cdd37192 ro quiet splash vt.handoff=7 SourcePackage: apparmor Syslog: UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1575779/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1734409] [NEW] systemd-sysctl: exit gracefully on EPERM/EACCESS
Public bug reported: Hi everyone, systemd-sysctl in systemd versions prior to 232 will exit with FAILED when not being able to apply kernel variables. In containers it should simply move on and exit with SUCCESS. Upstream systemd carries appropriate patches for this already. The relevant commits are: 411e869f497c7c7bd0688f1e3500f9043bc56e48 39540de8abe24886693ca29a9caeea85c88089aa these should be backported to xenial's systemd. Christian ** Affects: systemd (Ubuntu) Importance: Undecided Assignee: Dimitri John Ledkov (xnox) Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1734409 Title: systemd-sysctl: exit gracefully on EPERM/EACCESS Status in systemd package in Ubuntu: New Bug description: Hi everyone, systemd-sysctl in systemd versions prior to 232 will exit with FAILED when not being able to apply kernel variables. In containers it should simply move on and exit with SUCCESS. Upstream systemd carries appropriate patches for this already. The relevant commits are: 411e869f497c7c7bd0688f1e3500f9043bc56e48 39540de8abe24886693ca29a9caeea85c88089aa these should be backported to xenial's systemd. Christian To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1734409/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1734410] [NEW] systemd: handle undelegated cgroup2 hierarchy
Public bug reported: Hey everyone, Current systemd versions all fail when the unified cgroup hierarchy is not-writable. This is especially problematic in containers where the systemd administrator might decide to not delegate the unified hierarchy or when running with a liblxc driver that doesn't yet know how to handle the unified cgroup hierarchy. I've pushed patches to systemd upstream that let systemd ingnore the non-delegated unified hierarchy. The relevant commits are: e07aefbd675b651f8d45b5fb458f2747b04d6e04 2d56b80a1855836abf1d7458394c345ad9d55382 1ff654e28b7b8e7d0a0be33522a84069ac6b07c0 These patches will be in 235 but should be backported from xenial upwards. Christian ** Affects: systemd (Ubuntu) Importance: Undecided Assignee: Dimitri John Ledkov (xnox) Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1734410 Title: systemd: handle undelegated cgroup2 hierarchy Status in systemd package in Ubuntu: New Bug description: Hey everyone, Current systemd versions all fail when the unified cgroup hierarchy is not-writable. This is especially problematic in containers where the systemd administrator might decide to not delegate the unified hierarchy or when running with a liblxc driver that doesn't yet know how to handle the unified cgroup hierarchy. I've pushed patches to systemd upstream that let systemd ingnore the non-delegated unified hierarchy. The relevant commits are: e07aefbd675b651f8d45b5fb458f2747b04d6e04 2d56b80a1855836abf1d7458394c345ad9d55382 1ff654e28b7b8e7d0a0be33522a84069ac6b07c0 These patches will be in 235 but should be backported from xenial upwards. Christian To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1734410/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
Re: [Touch-packages] [Bug 1729357] Re: unprivileged user can drop supplementary groups
On Thu, Feb 15, 2018 at 11:29:03AM -, Aleksa Sarai wrote:
> I've just sent a request for a CVE. I'm working on the patch now. My
I assume the CVE will at least be correctly attributed to Craig.
Christian
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to shadow in Ubuntu.
https://bugs.launchpad.net/bugs/1729357
Title:
unprivileged user can drop supplementary groups
Status in shadow package in Ubuntu:
Confirmed
Bug description:
Distribution: Ubuntu 16.04.3 LTS
Kernel: 4.4.0-97-generic
uidmap package version: 1:4.2-3.1ubuntu5.3
The newgidmap setuid executable allows any user to write a single
mapping line to the gid_map of a process whose identity is the same as
the calling process, as long as that mapping line maps the process's
own GID outside of the user namespace to GID 0 inside the user
namespace.
Newgidmap will write the mapping regardless of the content of
/proc/$process_being_mapped/setgroups, which will initially contain
the string "allow". After this mapping is performed, and also after
the process' uid_map is written with newuidmap, the process in the
user namespace will be able to use the setgroups system call to drop
supplementary groups.
This is possible even if there is no entry for the user in
/etc/subgid, because no subordinate GIDs are actually being used.
This allows any user to circumvent the use of supplementary groups as
blacklists, e.g. for some file owned by root:blacklist with permission
bits 0604 (octal). Normally any process whose identity included the
group "blacklist" in its supplementary groups would not be able to
read that file. By performing this exploit using newgidmap, they can
drop all supplementary groups and read that file.
If newgidmap was not available, unprivileged users would not be able
to write a process's gid_map until writing "deny" to
/proc/$pid/setgroups. A fix for this might be for newgidmap to check
the content of /proc/$process_being_mapped/setgroups is "deny", but we
have not tried to patch this ourselves.
An example using 2 login shells for a user named "someone" on Ubuntu
Xenial, with the uidmap package installed:
Shell 1
someone@ubuntu-xenial:~$ id
uid=1001(someone) gid=1001(someone) groups=1001(someone),1002(restricted)
someone@ubuntu-xenial:~$ ls -al /tmp/should_restrict
-rwr-- 1 root restricted 8 Nov 1 12:23 /tmp/should_restrict
someone@ubuntu-xenial:~$ cat /tmp/should_restrict
cat: /tmp/should_restrict: Permission denied
someone@ubuntu-xenial:~$ unshare -U --setgroups allow #
/proc/self/setgroups already contains 'allow', but let's be explicit
nobody@ubuntu-xenial:~$ echo $$
1878
Shell 2
someone@ubuntu-xenial:~$ cat /etc/subuid
lxd:10:65536
root:10:65536
ubuntu:165536:65536
someone@ubuntu-xenial:~$ cat /etc/subgid
lxd:10:65536
root:10:65536
ubuntu:165536:65536
# There are no entries in /etc/sub{u,g}id for someone, but this
doesn't matter that much as subordinate IDs are not being requested.
someone@ubuntu-xenial:~$ newuidmap 1878 0 1001 1
someone@ubuntu-xenial:~$ newgidmap 1878 0 1001 1
Back to shell 1
nobody@ubuntu-xenial:~$ id
uid=0(root) gid=0(root) groups=0(root),65534(nogroup)
# The presence of the "nogroup" supplementary group indicates that
some unmapped GIDs are present as supplementary GIDs. The kernel knows
that this process still has "restricted" in its supplementary groups,
so it can't read the restricted file yet.
nobody@ubuntu-xenial:~$ cat /tmp/should_restrict
cat: /tmp/should_restrict: Permission denied
# The process has gained CAP_SETGID in its user namespace by becoming
UID 0. /proc/$pid/setgroups contains "allow", so it can call
setgroups(2). By su-ing to root (itself, in the user namespace), it
can drop the supplementary groups. It can't read /root/.bashrc as that
file is owned by UID 0 in the initial user namespace, which creates
some distracting error output but doesn't matter in this case.
nobody@ubuntu-xenial:~$ su root
su: Authentication failure
(Ignored)
bash: /root/.bashrc: Permission denied
# Supplementary groups have been dropped
root@ubuntu-xenial:~# id
uid=0(root) gid=0(root) groups=0(root)
# It can read the restricted file
root@ubuntu-xenial:~# cat /tmp/should_restrict
content
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1729357/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
Re: [Touch-packages] [Bug 1750654] [NEW] "lxc-create -B best" fails on non-btrfs/zfs system
On Tue, Feb 20, 2018 at 08:43:41PM -, Martin Pitt wrote: > Public bug reported: > > As per documentation, the `-B best` option should automatically select > the best backingstore, falling back all the way to dir. > > But apparently it doesn't, at least not in artful's 2.1.0-0ubuntu1: Hm, is it possible for you to try and reproduce with current master. Works fine for me: chb@conventiont|~ > sudo lxc-create -B best --name=autopkgtest-xenial -t ubuntu -- -r xenial lxc-create: autopkgtest-xenial: storage/btrfs.c: btrfs_create: 861 Inappropriate ioctl for device - Failed to create btrfs subvolume "/var/lib/lxc/autopkgtest-xenial/rootfs" lxc-create: autopkgtest-xenial: storage/zfs.c: zfs_create: 762 Failed to create zfs dataset "zfs:default/lxc/autopkgtest-xenial": The ZFS modules are not loaded. Try running '/sbin/modprobe zfs' as root to load them. lxc-create: autopkgtest-xenial: storage/lvm.c: do_lvm_create: 183 Failed to create logical volume "autopkgtest-xenial": Volume group "lvm_img" not found lxc-create: autopkgtest-xenial: storage/lvm.c: lvm_create: 655 Error creating new logical volume "lvm:/dev/lvm_img/autopkgtest-xenial" of size "1073741824 bytes" Checking cache download in /var/cache/lxc/xenial/rootfs-amd64 ... Installing packages in template: apt-transport-https,ssh,vim,language-pack-en Downloading ubuntu xenial minimal ... W: Target architecture is the same as host architecture; disabling QEMU support I: Running command: debootstrap --arch amd64 --verbose --components=main,universe --include=apt-transport-https,ssh,vim,language-pack-en xenial /var/cache/lxc/xenial/partial-amd64 http://archive.ubuntu.com/ubuntu I: Retrieving InRelease I: Checking Release signature I: Valid Release signature (key id 790BC7277767219C42C86F933B4FE6ACC0B21F32) I: Retrieving Packages I: Validating Packages I: Retrieving Packages -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1750654 Title: "lxc-create -B best" fails on non-btrfs/zfs system Status in lxc package in Ubuntu: New Bug description: As per documentation, the `-B best` option should automatically select the best backingstore, falling back all the way to dir. But apparently it doesn't, at least not in artful's 2.1.0-0ubuntu1: $ sudo lxc-create -B best --name=autopkgtest-xenial -t ubuntu -- -r xenial lxc-create: autopkgtest-xenial: storage/btrfs.c: btrfs_create: 860 Inappropriate ioctl for device - Failed to create btrfs subvolume "/var/lib/lxc/autopkgtest-xenial/rootfs" lxc-create: autopkgtest-xenial: storage/zfs.c: zfs_create: 758 Failed to create zfs dataset "zfs:lxc/autopkgtest-xenial": lxc-create: autopkgtest-xenial: utils.c: run_command: 2326 failed to exec command lxc-create: autopkgtest-xenial: storage/zfs.c: zfs_mount: 256 No such file or directory - Failed to mount "lxc/autopkgtest-xenial" on "/usr/lib/x86_64-linux-gnu/lxc" lxc-create: autopkgtest-xenial: lxccontainer.c: create_run_template: 1294 Failed to mount rootfs lxc-create: autopkgtest-xenial: lxccontainer.c: create_run_template: 1473 container creation template for autopkgtest-xenial failed lxc-create: autopkgtest-xenial: storage/zfs.c: zfs_destroy: 613 Failed to detect zfs dataset "lxc/autopkgtest-xenial": lxc-create: autopkgtest-xenial: lxc-create: autopkgtest-xenial: lxccontainer.c: container_destroy: 2653 Error destroying rootfs for autopkgtest-xenial lxc-create: autopkgtest-xenial: tools/lxc_create.c: main: 326 Error creating container autopkgtest-xenial Moreover, it creates cruft which is hard to clean up again: $ sudo lxc-ls -f NAME STATE AUTOSTART GROUPS IPV4 IPV6 autopkgtest-xenial STOPPED 0 - -- $ sudo lxc-destroy -n autopkgtest-xenial lxc-destroy: autopkgtest-xenial: storage/zfs.c: zfs_destroy: 613 Failed to detect zfs dataset "lxc/autopkgtest-xenial": lxc-destroy: autopkgtest-xenial: utils.c: run_command: 2326 failed to exec command lxc-destroy: autopkgtest-xenial: lxccontainer.c: container_destroy: 2653 Error destroying rootfs for autopkgtest-xenial Destroying autopkgtest-xenial failed $ sudo ls -lR /var/lib/lxc/autopkgtest-xenial /var/lib/lxc/autopkgtest-xenial: total 8 -rw-r--r-- 1 root root 149 Feb 20 20:41 config drwxr-xr-x 2 root root 4096 Feb 20 20:41 rootfs /var/lib/lxc/autopkgtest-xenial/rootfs: total 0 This can only be cleaned up with `sudo rm -r`. autopkgtest-build-lxc uses this option to get performant containers out of the box. Arguably `-B best` is a sort of "unbreak my containers" option and should always implicitly be used, but is there something else that I should do here? ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: lxc 2.1.0-0ubuntu1 ProcVersionSignature: Ubuntu 4.13.0-32.35-generic 4.13.13 Uname: Linux 4.13.0-32-generic x86_64 NonfreeKernelModules: zfs zunicode zavl zcommon
[Touch-packages] [Bug 1751780] Re: lxc-snapshot crashes when removing non-existing snapshot
** Changed in: lxc (Ubuntu) Status: New => Won't Fix ** Changed in: lxc (Ubuntu) Status: Won't Fix => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1751780 Title: lxc-snapshot crashes when removing non-existing snapshot Status in lxc package in Ubuntu: Confirmed Bug description: Easy to reproduce: # lxc-snapshot --name foo -r snap0 Segmentation fault (core dumped) ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: lxc1 2.1.0-0ubuntu1 ProcVersionSignature: Ubuntu 4.13.0-36.40-generic 4.13.13 Uname: Linux 4.13.0-36-generic x86_64 ApportVersion: 2.20.7-0ubuntu3.7 Architecture: amd64 CurrentDesktop: X-Cinnamon Date: Mon Feb 26 15:12:20 2018 InstallationDate: Installed on 2017-03-29 (334 days ago) InstallationMedia: Ubuntu 17.04 "Zesty Zapus" - Beta amd64 (20170321) SourcePackage: lxc UpgradeStatus: Upgraded to artful on 2017-12-14 (74 days ago) defaults.conf: lxc.net.0.type = veth lxc.net.0.link = lxcbr0 lxc.net.0.flags = up lxc.net.0.hwaddr = 00:16:3e:xx:xx:xx To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1751780/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1751780] Re: lxc-snapshot crashes when removing non-existing snapshot
** Changed in: lxc (Ubuntu) Status: Confirmed => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1751780 Title: lxc-snapshot crashes when removing non-existing snapshot Status in lxc package in Ubuntu: Fix Committed Bug description: Easy to reproduce: # lxc-snapshot --name foo -r snap0 Segmentation fault (core dumped) ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: lxc1 2.1.0-0ubuntu1 ProcVersionSignature: Ubuntu 4.13.0-36.40-generic 4.13.13 Uname: Linux 4.13.0-36-generic x86_64 ApportVersion: 2.20.7-0ubuntu3.7 Architecture: amd64 CurrentDesktop: X-Cinnamon Date: Mon Feb 26 15:12:20 2018 InstallationDate: Installed on 2017-03-29 (334 days ago) InstallationMedia: Ubuntu 17.04 "Zesty Zapus" - Beta amd64 (20170321) SourcePackage: lxc UpgradeStatus: Upgraded to artful on 2017-12-14 (74 days ago) defaults.conf: lxc.net.0.type = veth lxc.net.0.link = lxcbr0 lxc.net.0.flags = up lxc.net.0.hwaddr = 00:16:3e:xx:xx:xx To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1751780/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
Re: [Touch-packages] [Bug 1783591] Re: lxc-user-nic allows unprivileged users to open arbitrary files
On Thu, Aug 30, 2018 at 08:02:56PM -, Salvatore Bonaccorso wrote:
> One can still test existence of files with those patches, but I guess
> this was explicitly not part of the fixes?
Is there a reproducer?
Yes, the open() can fail and we will report back to the user that the
open() failed but the user has no way of knowing why it failed since we
don't report the errno and stracing will strip the suid bit so you can't
get it from the strace and you also need to be root to strace this.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1783591
Title:
lxc-user-nic allows unprivileged users to open arbitrary files
Status in lxc package in Ubuntu:
Fix Released
Status in lxc source package in Xenial:
Triaged
Status in lxc source package in Bionic:
Fix Released
Status in lxc source package in Cosmic:
Fix Released
Status in lxc package in Debian:
Confirmed
Bug description:
Matthias Gerstner from SUSE reported the following:
```
Hello,
following the lxc security reporting guidelines [1] I am reporting a
finding in the lxc-user-nic setuid binary. I'm encrypting this mail as a
best practice and because I found valid GPG keys for all of your
adresses. Please find my public key attached to this mail.
In the context of an openSUSE security audit of the lxc-user-nic setuid
binary [2] (currently private bug) I came across an issue that should be
adressed. In the "delete" case the program runs the following piece of
code unconditionally with effective uid 0 (from lxc_user_nic.c):
```
} else if (request == LXC_USERNIC_DELETE) {
netns_fd = open(args.pid, O_RDONLY);
if (netns_fd < 0) {
usernic_error("Could not open \"%s\": %s\n", args.pid,
strerror(errno));
exit(EXIT_FAILURE);
}
}
```
`args.pid` is a user controlled parameter and can be an arbitrary path
at the moment. Nothing is done with this file descriptor later on in the
program except an attempt at `setns(fd, CLONE_NEWNET)` in
`is_privileged_over_netns()`. Still this allows the unprivileged caller
of the setuid binary to achieve the following:
- it can test for existence of files normally not accessible to the
caller (information leak). Example:
```
# this file is existing
$ /usr/lib/lxc/lxc-user-nic delete path name /root/.bash_history type
bridge nic
lxc_user_nic.c: 1017: is_privileged_over_netns: Failed to setns() to
network namespace Invalid argument
lxc_user_nic.c: 1161: main: Process is not privileged over network namespace
# this file is not existing
$ /usr/lib/lxc/lxc-user-nic delete path name /root/.zsh_history type bridge
nic
lxc_user_nic.c: 1130: main: Could not open "/root/.zsh_history": No such
file or directory
```
- it allows to trigger code paths in the kernel that are normally not
accessible to the caller. This can happen when opening special files
like character and block devices or files in /proc or /sys. Opening
some of these files can cause lock or alloc operations or even more
complex things to happen like when opening /dev/ptmx, which causes the
allocation of a new master/slave pseudo terminal. Therefore this can
lead to DoS like situations or have further unspecified impact.
For fixing this I suggest opening the file supplied in `args.pid` only
with the permissions of the real user, since this is already done in
`is_privileged_over_netns()` anyway. Another approach would be the
normalization of the input path and then only allowing a path of the
pattern /proc//ns/net.
[1] https://github.com/lxc/lxc/blob/master/README.md#reporting-security-issues
[2] https://bugzilla.suse.com/show_bug.cgi?id=988348
Best regards
Matthias
```
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1783591/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1783591] Re: lxc-user-nic allows unprivileged users to open arbitrary files
If you think that you have found an actual security bug please file it
as a new one to follow best security practices.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1783591
Title:
lxc-user-nic allows unprivileged users to open arbitrary files
Status in lxc package in Ubuntu:
Fix Released
Status in lxc source package in Xenial:
Triaged
Status in lxc source package in Bionic:
Fix Released
Status in lxc source package in Cosmic:
Fix Released
Status in lxc package in Debian:
Confirmed
Bug description:
Matthias Gerstner from SUSE reported the following:
```
Hello,
following the lxc security reporting guidelines [1] I am reporting a
finding in the lxc-user-nic setuid binary. I'm encrypting this mail as a
best practice and because I found valid GPG keys for all of your
adresses. Please find my public key attached to this mail.
In the context of an openSUSE security audit of the lxc-user-nic setuid
binary [2] (currently private bug) I came across an issue that should be
adressed. In the "delete" case the program runs the following piece of
code unconditionally with effective uid 0 (from lxc_user_nic.c):
```
} else if (request == LXC_USERNIC_DELETE) {
netns_fd = open(args.pid, O_RDONLY);
if (netns_fd < 0) {
usernic_error("Could not open \"%s\": %s\n", args.pid,
strerror(errno));
exit(EXIT_FAILURE);
}
}
```
`args.pid` is a user controlled parameter and can be an arbitrary path
at the moment. Nothing is done with this file descriptor later on in the
program except an attempt at `setns(fd, CLONE_NEWNET)` in
`is_privileged_over_netns()`. Still this allows the unprivileged caller
of the setuid binary to achieve the following:
- it can test for existence of files normally not accessible to the
caller (information leak). Example:
```
# this file is existing
$ /usr/lib/lxc/lxc-user-nic delete path name /root/.bash_history type
bridge nic
lxc_user_nic.c: 1017: is_privileged_over_netns: Failed to setns() to
network namespace Invalid argument
lxc_user_nic.c: 1161: main: Process is not privileged over network namespace
# this file is not existing
$ /usr/lib/lxc/lxc-user-nic delete path name /root/.zsh_history type bridge
nic
lxc_user_nic.c: 1130: main: Could not open "/root/.zsh_history": No such
file or directory
```
- it allows to trigger code paths in the kernel that are normally not
accessible to the caller. This can happen when opening special files
like character and block devices or files in /proc or /sys. Opening
some of these files can cause lock or alloc operations or even more
complex things to happen like when opening /dev/ptmx, which causes the
allocation of a new master/slave pseudo terminal. Therefore this can
lead to DoS like situations or have further unspecified impact.
For fixing this I suggest opening the file supplied in `args.pid` only
with the permissions of the real user, since this is already done in
`is_privileged_over_netns()` anyway. Another approach would be the
normalization of the input path and then only allowing a path of the
pattern /proc//ns/net.
[1] https://github.com/lxc/lxc/blob/master/README.md#reporting-security-issues
[2] https://bugzilla.suse.com/show_bug.cgi?id=988348
Best regards
Matthias
```
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1783591/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1791958] Re: iptables-restore is missing -w option
** Changed in: iptables (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1791958 Title: iptables-restore is missing -w option Status in iptables package in Ubuntu: Confirmed Bug description: For CRIU we need to have iptables version 1.6.2 which includes the '-w' option in iptables-restore. This is a request to update iptables to 1.6.2 in 18.10 and if possible backport the necessary changes to 18.04. The CRIU project gets right now many bug reports (mostly in the combination LXD + CRIU) due to the missing '-w' option in iptables- restore. Especially as 18.04 will be around for some time it would be good to have iptables-restore available with '-w'. This is one example bug report: https://github.com/checkpoint- restore/criu/issues/551 But not only CRIU would benefit from this change. It seems also problematic with Kubernetes: https://github.com/kubernetes/kubernetes/pull/60978 So if possible, please update iptables to 1.6.2 (or backport changes) to support -w in iptables-restore. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1791958/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1646462] Re: lxc-create cannot setgid
What's your LXC version? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1646462 Title: lxc-create cannot setgid Status in lxc: Unknown Status in lxc package in Ubuntu: Confirmed Bug description: LXC cannot download image, seems like a server error: ~# lxc-create -t download -n test Setting up the GPG keyring Downloading the image index ERROR: Failed to download http://images.linuxcontainers.org//meta/1.0/index-user lxc-create: lxccontainer.c: create_run_template: 1290 container creation template for test failed lxc-create: tools/lxc_create.c: main: 318 Error creating container test Trying to download the file with wget gets the file OK with minor complaints: ~# wget -O /dev/null 'http://images.linuxcontainers.org//meta/1.0/index-user' URL transformed to HTTPS due to an HSTS policy --2016-12-01 12:36:58-- https://images.linuxcontainers.org//meta/1.0/index-user Resolving images.linuxcontainers.org (images.linuxcontainers.org)... 91.189.88.37, 91.189.91.21 Connecting to images.linuxcontainers.org (images.linuxcontainers.org)|91.189.88.37|:443... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: https://uk.images.linuxcontainers.org/meta/1.0/index-user [following] --2016-12-01 12:36:58-- https://uk.images.linuxcontainers.org/meta/1.0/index-user Resolving uk.images.linuxcontainers.org (uk.images.linuxcontainers.org)... 91.189.88.37 Connecting to uk.images.linuxcontainers.org (uk.images.linuxcontainers.org)|91.189.88.37|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 9102 (8.9K) Saving to: ‘/dev/null’ Seems like some SSL problem in the lxc-create binary, specifically the HSTS issue mentioned by wget. Maybe a newly introduced HSTS policy breaks the package? ProblemType: Bug DistroRelease: Ubuntu 16.10 Package: lxc 2.0.5-0ubuntu1.2 ProcVersionSignature: Ubuntu 4.8.0-28.30-generic 4.8.6 Uname: Linux 4.8.0-28-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.3-0ubuntu8 Architecture: amd64 Date: Thu Dec 1 12:28:28 2016 InstallationDate: Installed on 2016-10-14 (47 days ago) InstallationMedia: Ubuntu-Server 16.10 "Yakkety Yak" - Release amd64 (20161012.1) PackageArchitecture: all SourcePackage: lxc UpgradeStatus: No upgrade log present (probably fresh install) dnsmasq.conf: dhcp-host=vold,10.0.3.10 dhcp-host=sftp,10.0.3.11 To manage notifications about this bug go to: https://bugs.launchpad.net/lxc/+bug/1646462/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1783305] Re: apparmor DENIED when a systemd unit with DynamicUsers=yes is launched in a lxd container
*** This bug is a duplicate of bug 1780227 *** https://bugs.launchpad.net/bugs/1780227 This is an AppArmor bug that I reported and which is tracked here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1780227 So please close here in favor of that bug. Christian ** Changed in: lxd (Ubuntu) Status: New => Invalid ** Changed in: systemd (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1783305 Title: apparmor DENIED when a systemd unit with DynamicUsers=yes is launched in a lxd container Status in apparmor package in Ubuntu: New Status in lxd package in Ubuntu: Invalid Status in systemd package in Ubuntu: Invalid Bug description: $ lxc launch images:debian/sid test-dynamicusers $ lxc exec test-dynamicusers bash $ systemd-run --unit=testdynamic -p DynamicUser=yes --uid=xnox /bin/true $ systemctl status testdynamic.service # systemctl status testdynamic.service ● testdynamic.service - /bin/true Loaded: loaded (/run/systemd/transient/testdynamic.service; transient) Transient: yes Active: failed (Result: exit-code) since Tue 2018-07-24 10:16:13 UTC; 6s ago Process: 470 ExecStart=/bin/true (code=exited, status=217/USER) Main PID: 470 (code=exited, status=217/USER) Jul 24 10:16:13 systemd239 systemd[1]: testdynamic.service: Forked /bin/true as 470 Jul 24 10:16:13 systemd239 systemd[1]: testdynamic.service: Changed dead -> running Jul 24 10:16:13 systemd239 systemd[1]: testdynamic.service: Job testdynamic.service/start finished, result=done Jul 24 10:16:13 systemd239 systemd[1]: Started /bin/true. Jul 24 10:16:13 systemd239 systemd[1]: testdynamic.service: Failed to send unit change signal for testdynamic.service: Connection reset by peer Jul 24 10:16:13 systemd239 systemd[1]: testdynamic.service: Child 470 belongs to testdynamic.service. Jul 24 10:16:13 systemd239 systemd[1]: testdynamic.service: Main process exited, code=exited, status=217/USER Jul 24 10:16:13 systemd239 systemd[1]: testdynamic.service: Failed with result 'exit-code'. Jul 24 10:16:13 systemd239 systemd[1]: testdynamic.service: Changed running -> failed Jul 24 10:16:13 systemd239 systemd[1]: testdynamic.service: Unit entered failed state. and on the host side, in journal there is: Jul 24 11:16:13 sochi audit[14904]: AVC apparmor="DENIED" operation="file_lock" profile="lxd-systemd239_" pid=14904 comm="(true)" family="unix" sock_type="dgram" protocol=0 addr=none Jul 24 11:16:13 sochi audit[14904]: AVC apparmor="DENIED" operation="file_lock" profile="lxd-systemd239_" pid=14904 comm="(true)" family="unix" sock_type="dgram" protocol=0 addr=none Jul 24 11:16:13 sochi audit[14904]: AVC apparmor="DENIED" operation="file_lock" profile="lxd-systemd239_" pid=14904 comm="(true)" family="unix" sock_type="dgram" protocol=0 addr=none Jul 24 11:16:13 sochi audit[14904]: AVC apparmor="DENIED" operation="file_lock" profile="lxd-systemd239_" pid=14904 comm="(true)" family="unix" sock_type="dgram" protocol=0 addr=none Jul 24 11:16:13 sochi audit[3198]: AVC apparmor="DENIED" operation="file_lock" profile="lxd-systemd239_" pid=3198 comm="systemd" family="unix" sock_type="dgram" protocol=0 addr=none Jul 24 11:16:13 sochi kernel: audit: type=1400 audit(1532427373.697:934): apparmor="DENIED" operation="file_lock" profile="lxd-systemd239_" pid=14904 comm="(true)" family="unix" sock_type= Jul 24 11:16:13 sochi kernel: audit: type=1400 audit(1532427373.697:935): apparmor="DENIED" operation="file_lock" profile="lxd-systemd239_" pid=14904 comm="(true)" family="unix" sock_type= Jul 24 11:16:13 sochi kernel: audit: type=1400 audit(1532427373.697:936): apparmor="DENIED" operation="file_lock" profile="lxd-systemd239_" pid=14904 comm="(true)" family="unix" sock_type= Jul 24 11:16:13 sochi kernel: audit: type=1400 audit(1532427373.697:937): apparmor="DENIED" operation="file_lock" profile="lxd-systemd239_" pid=14904 comm="(true)" family="unix" sock_type= Jul 24 11:16:13 sochi kernel: audit: type=1400 audit(1532427373.697:938): apparmor="DENIED" operation="file_lock" profile="lxd-systemd239_" pid=3198 comm="systemd" family="unix" sock_type= Jul 24 11:16:13 sochi kernel: audit: type=1400 audit(1532427373.697:939): apparmor="DENIED" operation="file_lock" profile="lxd-systemd239_" pid=3198 comm="systemd" family="unix" sock_type= Jul 24 11:16:13 sochi kernel: audit: type=1400 audit(1532427373.697:940): apparmor="DENIED" operation="file_lock" profile="lxd-systemd239_" pid=3198 comm="systemd" family="unix" sock_type= Jul 24 11:16:13 sochi kernel: audit: type=1400 audit(1532427373.697:941): apparmor="DENIED" operation="file_lock" profile="lxd-systemd239_" pid=3198 comm="systemd" family="unix" sock_type= Jul 24 11:16:13 sochi audit[3198]: AVC apparmor="DENIED" operation="fil
[Touch-packages] [Bug 1575779] Re: hostnamectl fails under lxd unpriv container
** Changed in: apparmor (Ubuntu) Status: Fix Committed => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1575779 Title: hostnamectl fails under lxd unpriv container Status in apparmor package in Ubuntu: Confirmed Bug description: 1. % lsb_release -rd Description: Ubuntu 16.04 LTS Release: 16.04 2. % apt-cache policy apparmor apparmor: Installed: 2.10.95-0ubuntu2 Candidate: 2.10.95-0ubuntu2 Version table: *** 2.10.95-0ubuntu2 500 500 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages 100 /var/lib/dpkg/status % apt-cache policy lxd lxd: Installed: 2.0.0-0ubuntu4 Candidate: 2.0.0-0ubuntu4 Version table: *** 2.0.0-0ubuntu4 500 500 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages 100 /var/lib/dpkg/status 3. lxc launch ubuntu-daily:xenial x1 lxc exec x1 /bin/bash root@x1:~# hostnamectl status Static hostname: x1 Icon name: computer-container Chassis: container Machine ID: 833b8548c7ce4118b4c9c5c3ae4f133d Boot ID: 9d5fbb053cf7494589c0863a0a4cf0ca Virtualization: lxc Operating System: Ubuntu 16.04 LTS Kernel: Linux 4.4.0-18-generic Architecture: x86-64 4. hostnamectl status hangs indefinitely On the host, there are some audit messages for each invocation of hostnamectl [411617.032274] audit: type=1400 audit(1461695563.731:100): apparmor="DENIED" operation="file_lock" profile="lxd- x1_" pid=17100 comm="(ostnamed)" family="unix" sock_type="dgram" protocol=0 addr=none It's related to socket activation. One can workaround this by running systemd-hostnamed in the background first root@x1:~# /lib/systemd/systemd-hostnamed & [1] 2462 root@x1:~# hostnamectl status Static hostname: x1 Icon name: computer-container Chassis: container Machine ID: 833b8548c7ce4118b4c9c5c3ae4f133d Boot ID: 9d5fbb053cf7494589c0863a0a4cf0ca Virtualization: lxc Operating System: Ubuntu 16.04 LTS Kernel: Linux 4.4.0-18-generic Architecture: x86-64 ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: apparmor 2.10.95-0ubuntu2 ProcVersionSignature: Ubuntu 4.4.0-18.34-generic 4.4.6 Uname: Linux 4.4.0-18-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2 Architecture: amd64 CurrentDesktop: GNOME-Flashback:GNOME Date: Wed Apr 27 11:19:27 2016 InstallationDate: Installed on 2016-01-01 (117 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20151209) ProcKernelCmdline: BOOT_IMAGE=/boot/vmlinuz-4.4.0-18-generic root=UUID=e0b8b294-f364-4ef5-aa70-1916cdd37192 ro quiet splash vt.handoff=7 SourcePackage: apparmor Syslog: UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1575779/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1780227] Re: locking sockets broken due to missing AppArmor socket mediation patches
On Fri, Jul 27, 2018, 21:21 Stéphane Graber wrote: > Ok, thanks for the update. I've now updated the bug once again to move > all the tasks over to the kernel. Can you attach the kernel patch here > when you can, I'm sure some of the subscribers may want to test this > ahead of the Ubuntu kernel fixes :) > Might make sense to cc Lennart as he has a stake in this too. :) > ** Changed in: linux (Ubuntu) >Importance: Undecided => Critical > > ** Changed in: linux (Ubuntu Xenial) >Importance: Undecided => Critical > > ** Changed in: linux (Ubuntu Bionic) >Importance: Undecided => Critical > > ** Changed in: linux (Ubuntu) >Status: Invalid => Triaged > > ** Changed in: linux (Ubuntu Xenial) >Status: Invalid => Triaged > > ** Changed in: linux (Ubuntu Bionic) >Status: Invalid => Triaged > > ** Changed in: apparmor (Ubuntu) >Status: Triaged => Invalid > > ** Changed in: apparmor (Ubuntu Xenial) >Status: Triaged => Invalid > > ** Changed in: apparmor (Ubuntu Bionic) >Status: Triaged => Invalid > > ** Changed in: apparmor (Ubuntu) > Assignee: John Johansen (jjohansen) => (unassigned) > > ** Changed in: apparmor (Ubuntu Xenial) > Assignee: John Johansen (jjohansen) => (unassigned) > > ** Changed in: apparmor (Ubuntu Bionic) > Assignee: John Johansen (jjohansen) => (unassigned) > > ** Changed in: linux (Ubuntu) > Assignee: (unassigned) => John Johansen (jjohansen) > > ** Changed in: linux (Ubuntu Xenial) > Assignee: (unassigned) => John Johansen (jjohansen) > > ** Changed in: linux (Ubuntu Bionic) > Assignee: (unassigned) => John Johansen (jjohansen) > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1780227 > > Title: > locking sockets broken due to missing AppArmor socket mediation > patches > > Status in apparmor package in Ubuntu: > Invalid > Status in linux package in Ubuntu: > Triaged > Status in apparmor source package in Xenial: > Invalid > Status in linux source package in Xenial: > Triaged > Status in apparmor source package in Bionic: > Invalid > Status in linux source package in Bionic: > Triaged > > Bug description: > Hey, > > Newer systemd makes use of locks placed on AF_UNIX sockets created > with the socketpair() syscall to synchronize various bits and pieces > when isolating services. On kernels prior to 4.18 that do not have > backported the AppArmor socket mediation patchset this will cause the > locks to be denied with EACCESS. This causes systemd to be broken in > LXC and LXD containers that do not run unconfined which is a pretty > big deal. We have seen various bug reports related to this. See for > example [1] and [2]. > > If feasible it would be excellent if we could backport the socket > mediation patchset to all LTS kernels. Afaict, this should be 4.4 and > 4.15. This will unbreak a whole range of use-cases. > > The socket mediation patchset is available here: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=80a17a5f501ea048d86f81d629c94062b76610d4 > > > [1]: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1575779 > [2]: https://github.com/systemd/systemd/issues/9493 > > Thanks! > Christian > > To manage notifications about this bug go to: > > https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1780227/+subscriptions > ** Bug watch added: github.com/systemd/systemd/issues #9493 https://github.com/systemd/systemd/issues/9493 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1780227 Title: locking sockets broken due to missing AppArmor socket mediation patches Status in apparmor package in Ubuntu: Invalid Status in linux package in Ubuntu: Triaged Status in apparmor source package in Xenial: Invalid Status in linux source package in Xenial: Triaged Status in apparmor source package in Bionic: Invalid Status in linux source package in Bionic: Triaged Bug description: Hey, Newer systemd makes use of locks placed on AF_UNIX sockets created with the socketpair() syscall to synchronize various bits and pieces when isolating services. On kernels prior to 4.18 that do not have backported the AppArmor socket mediation patchset this will cause the locks to be denied with EACCESS. This causes systemd to be broken in LXC and LXD containers that do not run unconfined which is a pretty big deal. We have seen various bug reports related to this. See for example [1] and [2]. If feasible it would be excellent if we could backport the socket mediation patchset to all LTS kernels. Afaict, this should be 4.4 and 4.15. This will unbreak a whole range of use-cases. The socket mediation patchset is available here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.gi
[Touch-packages] [Bug 1783591] Re: lxc-user-nic allows unprivileged users to open arbitrary files
New version to apply cleanly to master.
** Patch added:
"0001-CVE-2018-6556-verify-netns-fd-in-lxc-user-nic-master.patch"
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1783591/+attachment/5172186/+files/0001-CVE-2018-6556-verify-netns-fd-in-lxc-user-nic-master.patch
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1783591
Title:
lxc-user-nic allows unprivileged users to open arbitrary files
Status in lxc package in Ubuntu:
Fix Released
Status in lxc source package in Xenial:
Triaged
Status in lxc source package in Bionic:
Fix Released
Status in lxc source package in Cosmic:
Fix Released
Bug description:
Matthias Gerstner from SUSE reported the following:
```
Hello,
following the lxc security reporting guidelines [1] I am reporting a
finding in the lxc-user-nic setuid binary. I'm encrypting this mail as a
best practice and because I found valid GPG keys for all of your
adresses. Please find my public key attached to this mail.
In the context of an openSUSE security audit of the lxc-user-nic setuid
binary [2] (currently private bug) I came across an issue that should be
adressed. In the "delete" case the program runs the following piece of
code unconditionally with effective uid 0 (from lxc_user_nic.c):
```
} else if (request == LXC_USERNIC_DELETE) {
netns_fd = open(args.pid, O_RDONLY);
if (netns_fd < 0) {
usernic_error("Could not open \"%s\": %s\n", args.pid,
strerror(errno));
exit(EXIT_FAILURE);
}
}
```
`args.pid` is a user controlled parameter and can be an arbitrary path
at the moment. Nothing is done with this file descriptor later on in the
program except an attempt at `setns(fd, CLONE_NEWNET)` in
`is_privileged_over_netns()`. Still this allows the unprivileged caller
of the setuid binary to achieve the following:
- it can test for existence of files normally not accessible to the
caller (information leak). Example:
```
# this file is existing
$ /usr/lib/lxc/lxc-user-nic delete path name /root/.bash_history type
bridge nic
lxc_user_nic.c: 1017: is_privileged_over_netns: Failed to setns() to
network namespace Invalid argument
lxc_user_nic.c: 1161: main: Process is not privileged over network namespace
# this file is not existing
$ /usr/lib/lxc/lxc-user-nic delete path name /root/.zsh_history type bridge
nic
lxc_user_nic.c: 1130: main: Could not open "/root/.zsh_history": No such
file or directory
```
- it allows to trigger code paths in the kernel that are normally not
accessible to the caller. This can happen when opening special files
like character and block devices or files in /proc or /sys. Opening
some of these files can cause lock or alloc operations or even more
complex things to happen like when opening /dev/ptmx, which causes the
allocation of a new master/slave pseudo terminal. Therefore this can
lead to DoS like situations or have further unspecified impact.
For fixing this I suggest opening the file supplied in `args.pid` only
with the permissions of the real user, since this is already done in
`is_privileged_over_netns()` anyway. Another approach would be the
normalization of the input path and then only allowing a path of the
pattern /proc//ns/net.
[1] https://github.com/lxc/lxc/blob/master/README.md#reporting-security-issues
[2] https://bugzilla.suse.com/show_bug.cgi?id=988348
Best regards
Matthias
```
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1783591/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1734410] Re: systemd: handle undelegated cgroup2 hierarchy
If the systemd version doesn't support hybrid cgroup layout on xenial then fine but I thought it did. But please make sure that Xenial doesn't have anything mounted on /sys/fs/cgroup/unified. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1734410 Title: systemd: handle undelegated cgroup2 hierarchy Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Incomplete Status in systemd source package in Zesty: Won't Fix Status in systemd source package in Artful: Fix Released Status in systemd source package in Bionic: Fix Released Bug description: [Impact] * When a container is presented with a unified cgroup hierarchy, which is not properly delegated, systemd should not attempt (and fail) to use. This improves compatibility of xenial containers running on unified cgroup hierarchy hosts. [Test Case] * Xenial containers should boot, with non-writable unified cgroup hierarchy hosts. [Regression Potential] * unified cgroup hierarchy is not in use by default on xenial hosts, thus this is forward compatibility improvment with e.g. bionic hosts running xenial containers. [Other Info] * Original bug report Hey everyone, Current systemd versions all fail when the unified cgroup hierarchy is not-writable. This is especially problematic in containers where the systemd administrator might decide to not delegate the unified hierarchy or when running with a liblxc driver that doesn't yet know how to handle the unified cgroup hierarchy. I've pushed patches to systemd upstream that let systemd ingnore the non-delegated unified hierarchy. The relevant commits are: e07aefbd675b651f8d45b5fb458f2747b04d6e04 2d56b80a1855836abf1d7458394c345ad9d55382 1ff654e28b7b8e7d0a0be33522a84069ac6b07c0 These patches will be in 236 but should be backported from xenial upwards. Christian To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1734410/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1799032] [NEW] Update to libcap 2.26
Public bug reported: Hey everyone, We recently pushed support for ambient capabilities and namespaces filesystem capabilities to libcap2 [1]. Together with Andrew Morgan, Serge Hallyn and I have released a version 2.26 of libcap2. Note that libcap2 has moved to a new location [2] The 2.26 release can be downloaded from [3]. Please update to the new version! [1]: https://sites.google.com/site/fullycapable/release-notes-for-libcap/pre-releasenotesfor226 [2]: https://git.kernel.org/pub/scm/libs/libcap/libcap.git/ [3]: https://git.kernel.org/pub/scm/libs/libcap/libcap.git/snapshot/libcap-2.26.tar.gz Thanks! Christian ** Affects: libcap2 (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libcap2 in Ubuntu. https://bugs.launchpad.net/bugs/1799032 Title: Update to libcap 2.26 Status in libcap2 package in Ubuntu: New Bug description: Hey everyone, We recently pushed support for ambient capabilities and namespaces filesystem capabilities to libcap2 [1]. Together with Andrew Morgan, Serge Hallyn and I have released a version 2.26 of libcap2. Note that libcap2 has moved to a new location [2] The 2.26 release can be downloaded from [3]. Please update to the new version! [1]: https://sites.google.com/site/fullycapable/release-notes-for-libcap/pre-releasenotesfor226 [2]: https://git.kernel.org/pub/scm/libs/libcap/libcap.git/ [3]: https://git.kernel.org/pub/scm/libs/libcap/libcap.git/snapshot/libcap-2.26.tar.gz Thanks! Christian To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libcap2/+bug/1799032/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1690125] Re: hybrid control goup mode breaks lxc adt tests
** Changed in: lxc (Ubuntu) Status: In Progress => Fix Released ** No longer affects: lxc -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1690125 Title: hybrid control goup mode breaks lxc adt tests Status in lxc package in Ubuntu: Fix Released Bug description: I will disably hybrid control groups by default for now, but will create a ppa with such systemd, for ease of testing. FAIL: lxc-tests: /usr/bin/lxc-test-apparmor-mount --- /usr/sbin/deluser: The user `lxcunpriv' does not exist. /usr/bin/lxc-test-apparmor-mount: 138: /usr/bin/lxc-test-apparmor-mount: cannot create /sys/fs/cgroup/unified/lxctest/tasks: Permission denied Container is not defined umount: /sys/kernel/security/apparmor/features/mount: not mounted --- FAIL: lxc-tests: /usr/bin/lxc-test-unpriv --- Removing user `lxcunpriv' ... Warning: group `lxcunpriv' has no more members. Done. /usr/bin/lxc-test-unpriv: line 154: /sys/fs/cgroup/unified/lxctest/tasks: Permission denied c2 is not running c1 is not running --- FAIL: lxc-tests: /usr/bin/lxc-test-usernic --- /usr/sbin/deluser: The user `usernic-user' does not exist. /usr/bin/lxc-test-usernic: line 111: /sys/fs/cgroup/unified/lxctest/tasks: Permission denied FAIL --- PASS: lxc-tests: /usr/bin/lxc-test-utils PASS: python3: API Removing 'local diversion of /usr/bin/dirmngr to /usr/bin/dirmngr.orig' CHANGES WITH 233: * The "hybrid" control group mode has been modified to improve compatibility with "legacy" cgroups-v1 setups. Specifically, the "hybrid" setup of /sys/fs/cgroup is now pretty much identical to "legacy" (including /sys/fs/cgroup/systemd as "name=systemd" named cgroups-v1 hierarchy), the only externally visible change being that the cgroups-v2 hierarchy is also mounted, to /sys/fs/cgroup/unified. This should provide a large degree of compatibility with "legacy" cgroups-v1, while taking benefit of the better management capabilities of cgroups-v2. * The default control group setup mode may be selected both a boot-time via a set of kernel command line parameters (specifically: systemd.unified_cgroup_hierarchy= and systemd.legacy_systemd_cgroup_controller=), as well as a compile-time default selected on the configure command line (--with-default-hierarchy=). The upstream default is "hybrid" (i.e. the cgroups-v1 + cgroups-v2 mixture discussed above) now, but this will change in a future systemd version to be "unified" (pure cgroups-v2 mode). The third option for the compile time option is "legacy", to enter pure cgroups-v1 mode. We recommend downstream distributions to default to "hybrid" mode for release distributions, starting with v233. We recommend "unified" for development distributions (specifically: distributions such as Fedora's rawhide) as that's where things are headed in the long run. Use "legacy" for greatest stability and compatibility only. * Note one current limitation of "unified" and "hybrid" control group setup modes: the kernel currently does not permit the systemd --user instance (i.e. unprivileged code) to migrate processes between two disconnected cgroup subtrees, even if both are managed and owned by the user. This effectively means "systemd-run --user --scope" doesn't work when invoked from outside of any "systemd --user" service or scope. Specifically, it is not supported from session scopes. We are working on fixing this in a future systemd version. (See #3388 for further details about this.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1690125/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1567037] Re: lxc-attach crashed with SIGSEGV in get_pty_on_host()
** Changed in: lxc (Ubuntu) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1567037 Title: lxc-attach crashed with SIGSEGV in get_pty_on_host() Status in lxc package in Ubuntu: Fix Released Bug description: Installed unity8-lxc, ran unity8-setup, then rebooted. Login to unity8 lxc session failed (somehow nothing happened), then I logged into Unity7 and the crash happened. ProblemType: Crash DistroRelease: Ubuntu 16.04 Package: lxc1 2.0.0~rc15-0ubuntu1 ProcVersionSignature: Ubuntu 4.4.0-17.33-generic 4.4.6 Uname: Linux 4.4.0-17-generic x86_64 ApportVersion: 2.20.1-0ubuntu1 Architecture: amd64 Date: Wed Apr 6 20:11:34 2016 ExecutablePath: /usr/bin/lxc-attach InstallationDate: Installed on 2015-12-03 (124 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20151203) ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-4.4.0-17-generic.efi.signed root=UUID=dccfbc3c-48bc-43ed-9881-36efaa2ef6c5 ro quiet splash vt.handoff=7 SegvAnalysis: Segfault happened at: 0x563ee5318994 : movl $0x1,0x1c(%r14) PC (0x563ee5318994) ok source "$0x1" ok destination "0x1c(%r14)" (0x001c) not located in a known VMA region (needed writable region)! SegvReason: writing NULL VMA Signal: 11 SourcePackage: lxc Stacktrace: #0 0x563ee5318994 in main () No symbol table info available. StacktraceTop: main () ThreadStacktrace: . Thread 1 (Thread 0x7fe20540f840 (LWP 2993)): #0 0x563ee5318994 in main () No symbol table info available. Title: lxc-attach crashed with SIGSEGV in main() UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: defaults.conf: lxc.network.type = veth lxc.network.link = lxcbr0 lxc.network.flags = up lxc.network.hwaddr = 00:16:3e:xx:xx:xx To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1567037/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1553097] Re: lxc-attach does not output stderr any more if stdout is redirected
** No longer affects: autopkgtest (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1553097 Title: lxc-attach does not output stderr any more if stdout is redirected Status in lxc package in Ubuntu: Fix Released Bug description: With lxc 2.0.0~rc5-0ubuntu1 the autopkgtest LXC runner is still broken (even with bug 1551960 fixed) when stderr is a terminal: $ adt-run gzip --- lxc -s adt-wily [...] adt-run [10:15:45]: ERROR: erroneous package: got 10 lines of results from extract where 4 expected: gpgv: Signature made Mon 27 Oct 2014 09:48:46 AM CET using RSA key ID BD4CA59E gpgv: Can't check signature: public key not found dpkg-source: warning: failed to verify signature on ./gzip_1.6-4ubuntu1.dsc Get:1 http://archive.ubuntu.com/ubuntu/ wily/main gzip 1.6-4ubuntu1 (dsc) [1,907 B] Get:2 http://archive.ubuntu.com/ubuntu/ wily/main gzip 1.6-4ubuntu1 (tar) [1,075 kB] Get:3 http://archive.ubuntu.com/ubuntu/ wily/main gzip 1.6-4ubuntu1 (diff) [14.9 kB] /tmp/adt-virt-lxc.shared.xklzp9z7/downtmp/build.ehH/gzip-1.6 gzip 1.6-4ubuntu1 1 Thie first couple of lines are supposed to go to stderr, not stdout. This works if stderr is not a terminal, but a pipe, with e. g. "adt- run -l /dev/null gzip --- lxc -s adt-wily" (where stderr is sent to a pipe which gets tee'ed to both the log file and the real stderr). This is probably a regression in LXC, and it doesn't happen with older LXC nor LXD nor any other backend. But it might also be some intentional change which autopkgtest needs to be adjusted to, so for now I keep tasks for both projects. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1553097/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1692111] Re: Unable to configure raw.id_map with multiple entries
** Changed in: lxd (Ubuntu) Status: In Progress => Fix Committed ** Also affects: lxc (Ubuntu) Importance: Undecided Status: New ** Changed in: lxc (Ubuntu) Status: New => Fix Committed ** Changed in: lxc (Ubuntu) Assignee: (unassigned) => Christian Brauner (cbrauner) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1692111 Title: Unable to configure raw.id_map with multiple entries Status in lxc package in Ubuntu: Fix Committed Status in lxd package in Ubuntu: Fix Committed Bug description: I am trying to map two users (999, 1001) to one of my containers. I added both IDs to /etc/subgid and /etc/subuid. I followed by setting raw.id_map property value (as instructed here https://lists.linuxcontainers.org/pipermail/lxc- users/2017-March/013034.html): "echo -e "both 999 999\nboth 1001 1001" | lxc config set mycontainer raw.idmap -" However upon starting the container, I get errors (log excerpt below). If, on the other hand, I set idmap to either "both 999 999" or "both 1001 1001" only - i.e. if I map only one user at the time, the container starts just fine and the user is mapped as expected. My subgid and subuid look as follows: lxd:10:65536 root:10:65536 root:1001:1 root:999:1 Log excerpt: Name: mycontainer Remote: unix:/var/lib/lxd/unix.socket Architecture: x86_64 Created: 2017/02/22 18:54 UTC Status: Stopped Type: persistent Profiles: default Log: lxc 20170519204102.895 ERRORlxc_cgfsng - cgroups/cgfsng.c:create_path_for_hierarchy:1306 - Path "/sys/fs/cgroup/systemd//lxc/mycontainer" already existed. lxc 20170519204102.896 ERRORlxc_cgfsng - cgroups/cgfsng.c:cgfsng_create:1363 - No such file or directory - Failed to create /sys/fs/cgroup/systemd//lxc/mycontainer: No such file or directory lxc 20170519204102.897 ERRORlxc_cgfsng - cgroups/cgfsng.c:create_path_for_hierarchy:1306 - Path "/sys/fs/cgroup/systemd//lxc/mycontainer-1" already existed. lxc 20170519204102.897 ERRORlxc_cgfsng - cgroups/cgfsng.c:cgfsng_create:1363 - No such file or directory - Failed to create /sys/fs/cgroup/systemd//lxc/mycontainer-1: No such file or directory lxc 20170519204102.897 ERRORlxc_cgfsng - cgroups/cgfsng.c:create_path_for_hierarchy:1306 - Path "/sys/fs/cgroup/systemd//lxc/mycontainer-2" already existed. lxc 20170519204102.898 ERRORlxc_cgfsng - cgroups/cgfsng.c:cgfsng_create:1363 - No such file or directory - Failed to create /sys/fs/cgroup/systemd//lxc/mycontainer-2: No such file or directory lxc 20170519204102.898 ERRORlxc_cgfsng - cgroups/cgfsng.c:create_path_for_hierarchy:1306 - Path "/sys/fs/cgroup/systemd//lxc/mycontainer-3" already existed. lxc 20170519204102.898 ERRORlxc_cgfsng - cgroups/cgfsng.c:cgfsng_create:1363 - No such file or directory - Failed to create /sys/fs/cgroup/systemd//lxc/mycontainer-3: No such file or directory lxc 20170519204102.898 ERRORlxc_cgfsng - cgroups/cgfsng.c:create_path_for_hierarchy:1306 - Path "/sys/fs/cgroup/systemd//lxc/mycontainer-4" already existed. lxc 20170519204102.898 ERRORlxc_cgfsng - cgroups/cgfsng.c:cgfsng_create:1363 - No such file or directory - Failed to create /sys/fs/cgroup/systemd//lxc/mycontainer-4: No such file or directory lxc 20170519204102.899 ERRORlxc_cgfsng - cgroups/cgfsng.c:create_path_for_hierarchy:1306 - Path "/sys/fs/cgroup/systemd//lxc/mycontainer-5" already existed. lxc 20170519204102.899 ERRORlxc_cgfsng - cgroups/cgfsng.c:cgfsng_create:1363 - No such file or directory - Failed to create /sys/fs/cgroup/systemd//lxc/mycontainer-5: No such file or directory lxc 20170519204102.899 ERRORlxc_cgfsng - cgroups/cgfsng.c:create_path_for_hierarchy:1306 - Path "/sys/fs/cgroup/systemd//lxc/mycontainer-6" already existed. lxc 20170519204102.899 ERRORlxc_cgfsng - cgroups/cgfsng.c:cgfsng_create:1363 - No such file or directory - Failed to create /sys/fs/cgroup/systemd//lxc/mycontainer-6: No such file or directory lxc 20170519204102.900 ERRORlxc_cgfsng - cgroups/cgfsng.c:create_path_for_hierarchy:1306 - Path "/sys/fs/cgroup/systemd//lxc/mycontainer-7" already existed. lxc 20170519204102.900 ERRORlxc_cgfsng - cgroups/cgfsng.c:cgfsng_create:1363 - No such file or directory - Failed to create /sys/fs/cgroup/systemd//lxc/mycontainer-7: No such file or directory lxc 20170519204102.900 ERRORlxc_cgfsng - cgroups/cgfsng.c:create_path_for_hierarchy:1306 - Path "/sys/fs/cgroup/systemd//lxc/myc
[Touch-packages] [Bug 1699759] Re: LXC Alpine template broken on ppc64le
** Changed in: lxc (Ubuntu) Status: New => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1699759 Title: LXC Alpine template broken on ppc64le Status in The Ubuntu-power-systems project: New Status in lxc package in Ubuntu: Fix Committed Bug description: == Comment: #0 - Breno Leitao - 2017-06-14 07:36:33 == LXC Alpine template is broken on Ubuntu 17.10, since it does not support ppc64le. It shows the following message: # Unknown architecture. == Comment: #1 - Breno Leitao - 2017-06-14 07:37:50 == Patch sent to upstream and accepted already: https://github.com/lxc/lxc/pull/1621#issuecomment-307887344 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1699759/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1699903] Re: lxc-sshd won't start with 2.0.8
Hi Miroslav, Yes, we've been hardening the console handling code quite a bit prior to this release. It seems that you are on a read-only file system which prevents LXC from removing the underlying "/dev/console" file that already exists. LXC wants to remove this file since it wants to prevent bind-mounting over a possible malicious file. Is the read-only filesystem intentional? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1699903 Title: lxc-sshd won't start with 2.0.8 Status in lxc package in Ubuntu: New Bug description: On a xenial system after an update to lxc, starting a container created with the lxc-sshd template fails consistently. This does not occur with 2.0.7. root@xenial:~# lxc-create -n mysshd -t /usr/share/lxc/templates/lxc-sshd Generating public/private rsa key pair. Your identification has been saved in /var/lib/lxc/mysshd/rootfs/etc/ssh/ssh_host_rsa_key. Your public key has been saved in /var/lib/lxc/mysshd/rootfs/etc/ssh/ssh_host_rsa_key.pub. The key fingerprint is: SHA256:eR4Kv8JpWxe+RvIudD8LTuOYSGmLdnmX1CgB3Y/IHP4 root@xenial The key's randomart image is: +---[RSA 2048]+ | . . | | . o . | | = o o | |*.. .| | . So+o | | ++=Eo.| | .+++BBo | |.+B+oO=+o| | ..o+++== .o | +[SHA256]-+ Generating public/private dsa key pair. Your identification has been saved in /var/lib/lxc/mysshd/rootfs/etc/ssh/ssh_host_dsa_key. Your public key has been saved in /var/lib/lxc/mysshd/rootfs/etc/ssh/ssh_host_dsa_key.pub. The key fingerprint is: SHA256:Jmet2LLZMtolKBhfDQ/Za4i3yr0/993umj4Hq0D8Qyg root@xenial The key's randomart image is: +---[DSA 1024]+ | | | o | |+ . | | . * o o | |. . + E S o | | + o + X + .| |. o o + = o o | | . + .+B.. ooo. | | o ++==..oo=*+ | +[SHA256]-+ root@xenial:~# lxc-start -n mysshd --logfile mysshd.log lxc-start: tools/lxc_start.c: main: 366 The container failed to start. lxc-start: tools/lxc_start.c: main: 368 To get more details, run the container in foreground mode. lxc-start: tools/lxc_start.c: main: 370 Additional information can be obtained by setting the --logfile and --logpriority options. root@xenial:~# cat mysshd.log lxc-start 20170622214710.829 ERRORlxc_conf - conf.c:lxc_setup_dev_console:1473 - Read-only file system - error unlinking /usr/lib/x86_64-linux-gnu/lxc/dev/console lxc-start 20170622214710.829 ERRORlxc_conf - conf.c:lxc_setup:4055 - failed to setup the console for 'mysshd' lxc-start 20170622214710.829 ERRORlxc_start - start.c:do_start:811 - Failed to setup container "mysshd". lxc-start 20170622214710.829 ERRORlxc_sync - sync.c:__sync_wait:57 - An error occurred in another process (expected sequence number 3) lxc-start 20170622214710.868 ERRORlxc_start - start.c:__lxc_start:1358 - Failed to spawn container "mysshd". lxc-start 20170622214715.901 ERRORlxc_start_ui - tools/lxc_start.c:main:366 - The container failed to start. lxc-start 20170622214715.901 ERRORlxc_start_ui - tools/lxc_start.c:main:368 - To get more details, run the container in foreground mode. lxc-start 20170622214715.901 ERRORlxc_start_ui - tools/lxc_start.c:main:370 - Additional information can be obtained by setting the --logfile and --logpriority options. root@xenial:~# dpkg -l '*lxc*' Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---== un liblxc0 (no description available) ii liblxc12.0.8-0ubuntu1~16.04.2 amd64 Linux Containers userspace tools (library) ii lxc2.0.8-0ubuntu1~16.04.2 all Transitional package for lxc1 ii lxc-common 2.0.8-0ubuntu1~16.04.2 amd64 Linux Containers userspace tools (common tools) ii lxc-templates 2.0.8-0ubuntu1~16.04.2 amd64 Linux Containers userspace tools (templates) ii lxc1 2.0.8-0ubuntu1~16.04.2 amd64 Linux Containers userspace tools ii lxcfs 2.0.6-0ubuntu1~16.04
Re: [Touch-packages] [Bug 1699903] Re: lxc-sshd won't start with 2.0.8
On Thu, Jun 22, 2017 at 11:11:59PM -, Miroslav Los wrote: > Our actual templates are based on the lxc-sshd template example that > comes with lxc-templates. There, basically all the lxc is is bind-mounts > for necessary paths from the host, obviously read-only: The /dev bind-mount is definitely not needed anymore since LXC will populate dev internally on its own. So you can remove this from your template and - if you want - you can send a PR against LXC master to remove this bind-mount from the template. We can however, make the code a little smarter in handling the /dev/console case by making it ignore unlink() failures. > > # grep mount.entry /usr/share/lxc/templates/lxc-sshd > lxc.mount.entry = /dev dev none ro,bind 0 0 > lxc.mount.entry = /lib lib none ro,bind 0 0 > lxc.mount.entry = /bin bin none ro,bind 0 0 > lxc.mount.entry = /usr usr none ro,bind 0 0 > lxc.mount.entry = /sbin sbin none ro,bind 0 0 > lxc.mount.entry = tmpfs run/sshd tmpfs mode=0644 0 0 > lxc.mount.entry = /usr/share/lxc/templates/lxc-sshd $init_path none ro,bind 0 > 0 > lxc.mount.entry = /etc/init.d etc/init.d none ro,bind 0 0 > lxc.mount.entry = /etc/sysconfig/network-scripts > etc/sysconfig/network-scripts none ro,bind 0 0 > lxc.mount.entry = /etc/rc.d etc/rc.d none ro,bind 0 0 > lxc.mount.entry = /lib64 lib64 none ro,bind 0 0 > > > Perhaps bind-mounting /dev isn't needed anymore, though then I'd like to know > why the example does that, and what the implications are of leaving the /dev > entry out. > > -- > You received this bug notification because you are a member of Ubuntu > containers team, which is subscribed to lxc in Ubuntu. > Matching subscriptions: lxc > https://bugs.launchpad.net/bugs/1699903 > > Title: > lxc-sshd won't start with 2.0.8 > > Status in lxc package in Ubuntu: > New > > Bug description: > On a xenial system after an update to lxc, starting a container > created with the lxc-sshd template fails consistently. This does not > occur with 2.0.7. > > root@xenial:~# lxc-create -n mysshd -t /usr/share/lxc/templates/lxc-sshd > Generating public/private rsa key pair. > Your identification has been saved in > /var/lib/lxc/mysshd/rootfs/etc/ssh/ssh_host_rsa_key. > Your public key has been saved in > /var/lib/lxc/mysshd/rootfs/etc/ssh/ssh_host_rsa_key.pub. > The key fingerprint is: > SHA256:eR4Kv8JpWxe+RvIudD8LTuOYSGmLdnmX1CgB3Y/IHP4 root@xenial > The key's randomart image is: > +---[RSA 2048]+ > | . . | > | . o . | > | = o o | > |*.. .| > | . So+o | > | ++=Eo.| > | .+++BBo | > |.+B+oO=+o| > | ..o+++== .o | > +[SHA256]-+ > Generating public/private dsa key pair. > Your identification has been saved in > /var/lib/lxc/mysshd/rootfs/etc/ssh/ssh_host_dsa_key. > Your public key has been saved in > /var/lib/lxc/mysshd/rootfs/etc/ssh/ssh_host_dsa_key.pub. > The key fingerprint is: > SHA256:Jmet2LLZMtolKBhfDQ/Za4i3yr0/993umj4Hq0D8Qyg root@xenial > The key's randomart image is: > +---[DSA 1024]+ > | | > | o | > |+ . | > | . * o o | > |. . + E S o | > | + o + X + .| > |. o o + = o o | > | . + .+B.. ooo. | > | o ++==..oo=*+ | > +[SHA256]-+ > > > root@xenial:~# lxc-start -n mysshd --logfile mysshd.log > lxc-start: tools/lxc_start.c: main: 366 The container failed to start. > lxc-start: tools/lxc_start.c: main: 368 To get more details, run the > container in foreground mode. > lxc-start: tools/lxc_start.c: main: 370 Additional information can be > obtained by setting the --logfile and --logpriority options. > > > root@xenial:~# cat mysshd.log > lxc-start 20170622214710.829 ERRORlxc_conf - > conf.c:lxc_setup_dev_console:1473 - Read-only file system - error unlinking > /usr/lib/x86_64-linux-gnu/lxc/dev/console > lxc-start 20170622214710.829 ERRORlxc_conf - > conf.c:lxc_setup:4055 - failed to setup the console for 'mysshd' > lxc-start 20170622214710.829 ERRORlxc_start - > start.c:do_start:811 - Failed to setup container "mysshd". > lxc-start 20170622214710.829 ERRORlxc_sync - > sync.c:__sync_wait:57 - An error occurred in another process (expected > sequence number 3) > lxc-start 20170622214710.868 ERRORlxc_start - > start.c:__lxc_start:1358 - Failed to spawn container "mysshd". > lxc-start 20170622214715.901 ERRORlxc_start_ui - > tools/lxc_start.c:main:366 - The container failed to start. > lxc-start 20170622214715.901 ERRORlxc_start_ui - > tools/lxc_start.c:main:368 - To get more details, run the container in > foreground mode. > lxc-start 20170622214715.901 ERRORlxc_start_ui - > tools/lxc_start.c:main:370 - Additional information can be obtained by > setting the --logfile and --logpriority options. > > > root@xenial:~# dpkg -l
[Touch-packages] [Bug 1699919] Re: lxc copy between hosts preserves original uid/gid
Hi, I'm not sure what the problem here is. LXD will copy the filesystem
mapped and will remap on demand if there's another sub{g,u}id range
allocated for LXD on the new host.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1699919
Title:
lxc copy between hosts preserves original uid/gid
Status in lxc package in Ubuntu:
New
Bug description:
I tried to copy an lxc container between two hosts. All worked as
expected, but when I looked at the underlying filesystem I realised
that the container that has been copied onto the new machine retained
its original uid/gid (running unprivileged):
root@ii:/var/lib/lxd/containers# ls -al
total 24
drwx--x--x 1 root root 58 Jun 23 12:01 .
drwxr-xr-x 1 root root182 Jun 23 12:04 ..
drwxr-xr-x+ 1 10 10 56 Jun 23 10:38 backend
-rw-r--r-- 1 root root 4446 Jun 23 12:04 lxc-monitord.log
drwxr-xr-x+ 1 10 10 56 Jun 23 12:01 putils
(putils has been copied from a different host).
I'd expect a new uid/gid to be allocated for the copied host.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1699919/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
Re: [Touch-packages] [Bug 1699919] Re: lxc copy between hosts preserves original uid/gid
On Fri, Jun 23, 2017 at 10:19:46AM -, PshemK wrote:
> The thing is - it didn't get remapped. Now I have two containers mapping
> to the same range, both live:
>
> pshemk@ii:~$ lxc list
> +-+-+-+--++---+
> | NAME | STATE |IPV4 | IPV6 |TYPE| SNAPSHOTS |
> +-+-+-+--++---+
> | backend | RUNNING | 10.221.22.92 (eth0) | | PERSISTENT | 0 |
> +-+-+-+--++---+
> | putils | RUNNING | 10.221.22.91 (eth0) | | PERSISTENT | 1 |
> +-+-+-+--++---+
>
> pshemk@ii:~$ lxc config show putils
> architecture: x86_64
> config:
> volatile.base_image:
> 8fa08537ae51c880966626561987153e72d073cbe19dfe5abc062713d929254d
> volatile.eth0.hwaddr: 00:16:3e:e3:20:21
> volatile.idmap.base: "0"
> volatile.idmap.next:
> '[{"Isuid":true,"Isgid":false,"Hostid":10,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":10,"Nsid":0,"Maprange":65536}]'
> volatile.last_state.idmap:
> '[{"Isuid":true,"Isgid":false,"Hostid":10,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":10,"Nsid":0,"Maprange":65536}]'
> volatile.last_state.power: RUNNING
> devices:
> root:
> path: /
> type: disk
> ephemeral: false
> profiles:
> - default
> stateful: false
> pshemk@ii:~$ lxc config show backend
> architecture: x86_64
> config:
> volatile.base_image:
> 7a7ff654cbd8f5f09bec03aa19d8d7d92649127d18659036a963b1ea63f90d25
> volatile.eth0.hwaddr: 00:16:3e:ec:03:84
> volatile.idmap.base: "0"
> volatile.idmap.next:
> '[{"Isuid":true,"Isgid":false,"Hostid":10,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":10,"Nsid":0,"Maprange":65536}]'
> volatile.last_state.idmap:
> '[{"Isuid":true,"Isgid":false,"Hostid":10,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":10,"Nsid":0,"Maprange":65536}]'
> volatile.last_state.power: RUNNING
> devices:
> root:
> path: /
> type: disk
> ephemeral: false
> profiles:
> - default
> stateful: false
>
> both have the same hostid, and get mapped to the same range.
>
> Should the files on the file system belong to the same uid:gid for 2
> different containers?
Yes, that is expected and is the default behavior.
What you want is to set
security.idmap.isolated
for the container. For example,
lxc config set putils security.idmap.isolated true
this will kick-off an algorithm that will try to find an isolated idmapping for
the container with that property. If you wanted to isolate each container then
you could set
security.idmap.isolated
to true in an appropriate profile (e.g. the default profile). Note however, that
the number of container with isolated idmaps is restriced by the available
range.
In general, isolating container idmappings makes a lot of sense for security
critical containers. It likely doesn't need to be the default for most of your
workload.
>
> --
> You received this bug notification because you are a member of Ubuntu
> containers team, which is subscribed to lxc in Ubuntu.
> Matching subscriptions: lxc
> https://bugs.launchpad.net/bugs/1699919
>
> Title:
> lxc copy between hosts preserves original uid/gid
>
> Status in lxc package in Ubuntu:
> New
>
> Bug description:
> I tried to copy an lxc container between two hosts. All worked as
> expected, but when I looked at the underlying filesystem I realised
> that the container that has been copied onto the new machine retained
> its original uid/gid (running unprivileged):
>
> root@ii:/var/lib/lxd/containers# ls -al
> total 24
> drwx--x--x 1 root root 58 Jun 23 12:01 .
> drwxr-xr-x 1 root root182 Jun 23 12:04 ..
> drwxr-xr-x+ 1 10 10 56 Jun 23 10:38 backend
> -rw-r--r-- 1 root root 4446 Jun 23 12:04 lxc-monitord.log
> drwxr-xr-x+ 1 10 10 56 Jun 23 12:01 putils
>
> (putils has been copied from a different host).
>
> I'd expect a new uid/gid to be allocated for the copied host.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1699919/+subscriptions
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1699919
Title:
lxc copy between hosts preserves original uid/gid
Status in lxc package in Ubuntu:
New
Bug description:
I tried to copy an lxc container between two hosts. All worked as
expected, but when I looked at the underlying filesystem I realised
that the container that has been copied onto the new machine retained
its original uid/gid (running unprivileged):
root@ii:/var/lib/lxd/containers# ls -al
total 24
drwx--x--x 1 root root 58 Jun 23 12:01 .
drwxr
[Touch-packages] [Bug 1680330] Re: lxc-execute can run commands in current namespace
This is expected. lxc-execute allows you to run commands without a
rootfs. Other isolation mechanisms are still available. Say, you have
sub{u,g}ids defined and you want to run a shell in a set of new
namespaces including user namespaces you can do:
sudo lxc-execute -n ns1 -l debug -o AAA -s "lxc.id_map = u 0 165536
65536" -s "lxc.id_map = g 0 165536 65536" -- bash
Which in the hosts process tree shows up as:
root 21209 0.0 0.0 56916 3840 pts/14 S+ 12:22 0:00 \_
sudo lxc-execute -n ns1 -s lxc.id_map = u 0 165536 65536 -s lxc.id_map = g 0
165536 65536 --
bash
root 21210 0.0 0.0 46264 4552 pts/14 S+ 12:22 0:00
\_ lxc-execute -n ns1 -s lxc.id_map = u 0 165536 65536 -s lxc.id_map = g 0
165536 65536 -- bash
165536 21212 0.0 0.0 46140 4192 ?Ss 12:22 0:00
\_ /usr/sbin/init.lxc --name ns1 --lxcpath /var/lib/lxc --logpriority ERROR
-- bash
165536 21246 0.0 0.0 18348 3236 ?S12:22 0:00
\_ bash
And as you can see the {u,g}ids are mapped. And looking at the log I
appended you can see that other isolation mechanisms are still in place.
So not a bug.
** Attachment added: "AAA"
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1680330/+attachment/4856068/+files/AAA
** Changed in: lxc (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1680330
Title:
lxc-execute can run commands in current namespace
Status in lxc package in Ubuntu:
Invalid
Bug description:
If lxc-execute is passed a non-existent container name, then the
command given is run in the current namespace.
I believe it should failed with a "container not found" error, as
otherwise it can lead to unexpected consequences in the host
environment.
example:
# lxc-ls
files foreman ns01proxy
## Example typo on the -n option
# lxc-execute -n ns1 -- touch /tmp/ns01
# ls -l /tmp/ns01
-rw-r--r-- 1 root root 0 Apr 6 16:07 /tmp/ns01
## Command ran outside of container!
# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.10
DISTRIB_CODENAME=yakkety
DISTRIB_DESCRIPTION="Ubuntu 16.10"
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1680330/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1684481] Re: KVM guest execution start apparmor blocks on /dev/ptmx now (regression?)
Hi John, hi Christian, Sent a branch to lxc that should fix this issue: https://github.com/lxc/lxc/pull/1519 ** Changed in: lxc (Ubuntu) Status: Triaged => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1684481 Title: KVM guest execution start apparmor blocks on /dev/ptmx now (regression?) Status in apparmor package in Ubuntu: New Status in linux package in Ubuntu: Confirmed Status in lxc package in Ubuntu: In Progress Status in lxd package in Ubuntu: Invalid Bug description: Setup: - Xenial host - lxd guests with Trusty, Xenial, ... - add a LXD profile to allow kvm [3] (inspired by stgraber) - spawn KVM guests in the LXD guests using the different distro release versions - guests are based on the uvtool default template which has a serial console [4] Issue: - guest starting with serial device gets blocked by apparmor and killed on creation - This affects at least ppc64el and x86 (s390x has no serial concept that would match) - This appeared in our usual checks on -proposed releases so maybe we can/should stop something? Last good was "Apr 5, 2017 10:40:50 AM" first bad one "Apr 8, 2017 5:11:22 AM" Background: We use this setup for a while and it was working without a change on our end. Also the fact that it still works in the Trusty LXD makes it somewhat suspicious. Therefore I'd assume an SRUed change in LXD/Kernel/Apparmor might be the reason and open this bug to get your opinion on it. You can look into [1] and search for uvt-kvm create in it. Deny in dmesg: [652759.606218] audit: type=1400 audit(1492671353.134:4520): apparmor="DENIED" operation="open" namespace="root//lxd-testkvm-xenial-from_" profile="libvirt-668e21f1-fa55-4a30-b325-0ed5cfd55e5b" name="/dev/pts/ptmx" pid=27162 comm="qemu-system-ppc" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0 Qemu-log: 2017-04-20T06:55:53.139450Z qemu-system-ppc64: -chardev pty,id=charserial0: Failed to create PTY: No such file or directory There was a similar issue on qmeu namespacing (which we don't use on any of these releases) [2]. While we surely don't have the "same" issue the debugging on the namespacing might be worth as it could be related. Workaround for now: - drop serial section from guest xml [1]: https://jenkins.ubuntu.com/server/view/Virt/job/virt-migration-cross-release-amd64/78/consoleFull [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1421036 [3]: https://git.launchpad.net/~ubuntu-server/ubuntu/+source/qemu-migration-test/tree/kvm_profile.yaml [4]: https://libvirt.org/formatdomain.html#elementsCharPTY --- ApportVersion: 2.20.1-0ubuntu2.5 Architecture: ppc64el DistroRelease: Ubuntu 16.04 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl Package: lxd PackageArchitecture: ppc64el ProcKernelCmdline: root=UUID=902eaad1-2164-4f9a-bec4-7ff3abc15804 ro console=hvc0 ProcLoadAvg: 3.15 3.02 3.83 1/3056 79993 ProcSwaps: Filename TypeSizeUsedPriority /swap.img file 8388544 0 -1 ProcVersion: Linux version 4.4.0-72-generic (buildd@bos01-ppc64el-022) (gcc version 5.4.0 20160609 (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.4) ) #93-Ubuntu SMP Fri Mar 31 14:05:15 UTC 2017 ProcVersionSignature: Ubuntu 4.4.0-72.93-generic 4.4.49 Syslog: Tags: xenial uec-images Uname: Linux 4.4.0-72-generic ppc64le UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: utah _MarkForUpload: True cpu_cores: Number of cores present = 20 cpu_coreson: Number of cores online = 20 cpu_smt: SMT is off --- ApportVersion: 2.20.1-0ubuntu2.5 Architecture: ppc64el DistroRelease: Ubuntu 16.04 NonfreeKernelModules: cfg80211 ebtable_broute ebtable_nat binfmt_misc veth nbd openvswitch vhost_net vhost macvtap macvlan xt_conntrack ipt_REJECT nf_reject_ipv4 ebtable_filter ebtables ip6t_MASQUERADE nf_nat_masquerade_ipv6 ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_filter ip6_tables xt_comment xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack xt_tcpudp bridge stp llc iptable_filter ip_tables x_tables zfs zunicode zcommon znvpair spl zavl kvm_hv kvm ipmi_powernv ipmi_msghandler uio_pdrv_genirq vmx_crypto powernv_rng ibmpowernv leds_powernv uio ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear ses enclosure mlx4_en vxlan ip6_udp_tunnel udp_tunnel mlx4_core ipr Package: lxd PackageArchitecture: ppc64el ProcEnviron: TERM=xterm PATH=(custom, no user) LANG=
[Touch-packages] [Bug 1684481] Re: KVM guest execution start apparmor blocks on /dev/ptmx now (regression?)
** Changed in: lxc (Ubuntu) Status: In Progress => Fix Committed ** Changed in: lxc (Ubuntu) Assignee: (unassigned) => Christian Brauner (cbrauner) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1684481 Title: KVM guest execution start apparmor blocks on /dev/ptmx now (regression?) Status in apparmor package in Ubuntu: New Status in linux package in Ubuntu: Confirmed Status in lxc package in Ubuntu: Fix Committed Status in lxd package in Ubuntu: Invalid Bug description: Setup: - Xenial host - lxd guests with Trusty, Xenial, ... - add a LXD profile to allow kvm [3] (inspired by stgraber) - spawn KVM guests in the LXD guests using the different distro release versions - guests are based on the uvtool default template which has a serial console [4] Issue: - guest starting with serial device gets blocked by apparmor and killed on creation - This affects at least ppc64el and x86 (s390x has no serial concept that would match) - This appeared in our usual checks on -proposed releases so maybe we can/should stop something? Last good was "Apr 5, 2017 10:40:50 AM" first bad one "Apr 8, 2017 5:11:22 AM" Background: We use this setup for a while and it was working without a change on our end. Also the fact that it still works in the Trusty LXD makes it somewhat suspicious. Therefore I'd assume an SRUed change in LXD/Kernel/Apparmor might be the reason and open this bug to get your opinion on it. You can look into [1] and search for uvt-kvm create in it. Deny in dmesg: [652759.606218] audit: type=1400 audit(1492671353.134:4520): apparmor="DENIED" operation="open" namespace="root//lxd-testkvm-xenial-from_" profile="libvirt-668e21f1-fa55-4a30-b325-0ed5cfd55e5b" name="/dev/pts/ptmx" pid=27162 comm="qemu-system-ppc" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0 Qemu-log: 2017-04-20T06:55:53.139450Z qemu-system-ppc64: -chardev pty,id=charserial0: Failed to create PTY: No such file or directory There was a similar issue on qmeu namespacing (which we don't use on any of these releases) [2]. While we surely don't have the "same" issue the debugging on the namespacing might be worth as it could be related. Workaround for now: - drop serial section from guest xml [1]: https://jenkins.ubuntu.com/server/view/Virt/job/virt-migration-cross-release-amd64/78/consoleFull [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1421036 [3]: https://git.launchpad.net/~ubuntu-server/ubuntu/+source/qemu-migration-test/tree/kvm_profile.yaml [4]: https://libvirt.org/formatdomain.html#elementsCharPTY --- ApportVersion: 2.20.1-0ubuntu2.5 Architecture: ppc64el DistroRelease: Ubuntu 16.04 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl Package: lxd PackageArchitecture: ppc64el ProcKernelCmdline: root=UUID=902eaad1-2164-4f9a-bec4-7ff3abc15804 ro console=hvc0 ProcLoadAvg: 3.15 3.02 3.83 1/3056 79993 ProcSwaps: Filename TypeSizeUsedPriority /swap.img file 8388544 0 -1 ProcVersion: Linux version 4.4.0-72-generic (buildd@bos01-ppc64el-022) (gcc version 5.4.0 20160609 (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.4) ) #93-Ubuntu SMP Fri Mar 31 14:05:15 UTC 2017 ProcVersionSignature: Ubuntu 4.4.0-72.93-generic 4.4.49 Syslog: Tags: xenial uec-images Uname: Linux 4.4.0-72-generic ppc64le UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: utah _MarkForUpload: True cpu_cores: Number of cores present = 20 cpu_coreson: Number of cores online = 20 cpu_smt: SMT is off --- ApportVersion: 2.20.1-0ubuntu2.5 Architecture: ppc64el DistroRelease: Ubuntu 16.04 NonfreeKernelModules: cfg80211 ebtable_broute ebtable_nat binfmt_misc veth nbd openvswitch vhost_net vhost macvtap macvlan xt_conntrack ipt_REJECT nf_reject_ipv4 ebtable_filter ebtables ip6t_MASQUERADE nf_nat_masquerade_ipv6 ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_filter ip6_tables xt_comment xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack xt_tcpudp bridge stp llc iptable_filter ip_tables x_tables zfs zunicode zcommon znvpair spl zavl kvm_hv kvm ipmi_powernv ipmi_msghandler uio_pdrv_genirq vmx_crypto powernv_rng ibmpowernv leds_powernv uio ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear ses enclosure mlx4_en vxlan ip6_udp_tunnel udp_tunnel
[Touch-packages] [Bug 1686036] Re: strange behavior after restore snapshot
This is very likely not a LXD bug. I suspect this is
https://github.com/zfsonlinux/zfs/issues/5796 again which I reported to
ZFS upstream. I'll ping them about this again tomorrow and if I don't
hear back will take a look at this myself.
** Bug watch added: Github Issue Tracker for ZFS #5796
https://github.com/zfsonlinux/zfs/issues/5796
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1686036
Title:
strange behavior after restore snapshot
Status in lxc package in Ubuntu:
New
Bug description:
uname -a
Linux lxd2-chel1 4.4.0-72-generic #93-Ubuntu SMP Fri Mar 31 14:07:41 UTC 2017
x86_64 x86_64 x86_64 GNU/Linux
lxd: 2.12-0ubuntu3~ubuntu16.04.1~ppa1
zfsutils-linux: 0.6.5.6-0ubuntu16
# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 16.04.2 LTS
Release:16.04
Codename: xenial
after restore container from shapshot cannot add new snapshot or restore again
until restart container
example:
# lxc image list
+---+--++--++-+--+
| ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION
| ARCH | SIZE | UPLOAD DATE |
+---+--++--++-+--+
| debian/jessie | ba43812c4cb9 | no | Debian jessie amd64
(20170423_22:42) | x86_64 | 94.14MB | Apr 24, 2017 at 9:07am (UTC) |
+---+--++--++-+--+
# lxc launch debian/jessie
Creating popular-kitten
The container you are starting doesn't have any network attached to it.
To create a new network, use: lxc network create
To attach a network to a container, use: lxc network attach
Starting popular-kitten
# lxc info popular-kitten
Name: popular-kitten
Remote: unix:/var/lib/lxd/unix.socket
Architecture: x86_64
Created: 2017/04/25 07:17 UTC
Status: Running
Type: persistent
Profiles: default
Pid: 6965
Ips:
lo: inet127.0.0.1
lo: inet6 ::1
Resources:
Processes: 7
Disk usage:
root: 1.48MB
CPU usage:
CPU usage (in seconds): 25
Memory usage:
Memory (current): 16.22MB
Memory (peak): 23.01MB
Network usage:
lo:
Bytes received: 0B
Bytes sent: 0B
Packets received: 0
Packets sent: 0
# lxc profile show default
config: {}
description: Default LXD profile
devices:
root:
path: /
pool: main-pool
type: disk
name: default
used_by:
- /1.0/containers/popular-kitten
# lxc snapshot popular-kitten
# zfs get mounted main-pool/containers/popular-kitten
NAME PROPERTY VALUESOURCE
main-pool/containers/popular-kitten mounted yes -
# zfs get mounted main-pool/snapshots/popular-kitten
NAMEPROPERTY VALUESOURCE
main-pool/snapshots/popular-kitten mounted yes -
# lxc restore popular-kitten snap0
# zfs get mounted main-pool/snapshots/popular-kitten
NAMEPROPERTY VALUESOURCE
main-pool/snapshots/popular-kitten mounted yes -
# zfs get mounted main-pool/containers/popular-kitten
NAME PROPERTY VALUESOURCE
main-pool/containers/popular-kitten mounted no -
# lxc snapshot popular-kitten
error: Failed to mount ZFS filesystem: filesystem
'main-pool/containers/popular-kitten' is already mounted
cannot mount 'main-pool/containers/popular-kitten': mountpoint or dataset is
busy
# lxc restore popular-kitten snap0
error: Failed to mount ZFS filesystem: filesystem
'main-pool/containers/popular-kitten' is already mounted
cannot mount 'main-pool/containers/popular-kitten': mountpoint or dataset is
busy
but container still work:
# lxc info popular-kitten
Name: popular-kitten
Remote: unix:/var/lib/lxd/unix.socket
Architecture: x86_64
Created: 2017/04/25 07:17 UTC
Status: Running
...
# lxc exec popular-kitten bash
root@popular-kitten:~# uptime
07:34:06 up 8 min, 0 users, load average: 0.00, 0.02, 0.03
after restart container:
# lxc restart popular-kitten
# zfs get mounted main-pool/containers/popular-kitten
NAME PROPERTY VALUESOURCE
main-pool/containers/popular-kitten mounted yes -
on another server this problem missmatch:
# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 16.10
Release:16.10
Codename: yakkety
# lxd --version
2.4.1
zfsutils-linux: 0.6.5.8-0ubuntu4.1
To manag
[Touch-packages] [Bug 1686036] Re: strange behavior after restore snapshot
Reproducible. Can you please open this bug on github.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1686036
Title:
strange behavior after restore snapshot
Status in lxc package in Ubuntu:
New
Bug description:
uname -a
Linux lxd2-chel1 4.4.0-72-generic #93-Ubuntu SMP Fri Mar 31 14:07:41 UTC 2017
x86_64 x86_64 x86_64 GNU/Linux
lxd: 2.12-0ubuntu3~ubuntu16.04.1~ppa1
zfsutils-linux: 0.6.5.6-0ubuntu16
# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 16.04.2 LTS
Release:16.04
Codename: xenial
after restore container from shapshot cannot add new snapshot or restore again
until restart container
example:
# lxc image list
+---+--++--++-+--+
| ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION
| ARCH | SIZE | UPLOAD DATE |
+---+--++--++-+--+
| debian/jessie | ba43812c4cb9 | no | Debian jessie amd64
(20170423_22:42) | x86_64 | 94.14MB | Apr 24, 2017 at 9:07am (UTC) |
+---+--++--++-+--+
# lxc launch debian/jessie
Creating popular-kitten
The container you are starting doesn't have any network attached to it.
To create a new network, use: lxc network create
To attach a network to a container, use: lxc network attach
Starting popular-kitten
# lxc info popular-kitten
Name: popular-kitten
Remote: unix:/var/lib/lxd/unix.socket
Architecture: x86_64
Created: 2017/04/25 07:17 UTC
Status: Running
Type: persistent
Profiles: default
Pid: 6965
Ips:
lo: inet127.0.0.1
lo: inet6 ::1
Resources:
Processes: 7
Disk usage:
root: 1.48MB
CPU usage:
CPU usage (in seconds): 25
Memory usage:
Memory (current): 16.22MB
Memory (peak): 23.01MB
Network usage:
lo:
Bytes received: 0B
Bytes sent: 0B
Packets received: 0
Packets sent: 0
# lxc profile show default
config: {}
description: Default LXD profile
devices:
root:
path: /
pool: main-pool
type: disk
name: default
used_by:
- /1.0/containers/popular-kitten
# lxc snapshot popular-kitten
# zfs get mounted main-pool/containers/popular-kitten
NAME PROPERTY VALUESOURCE
main-pool/containers/popular-kitten mounted yes -
# zfs get mounted main-pool/snapshots/popular-kitten
NAMEPROPERTY VALUESOURCE
main-pool/snapshots/popular-kitten mounted yes -
# lxc restore popular-kitten snap0
# zfs get mounted main-pool/snapshots/popular-kitten
NAMEPROPERTY VALUESOURCE
main-pool/snapshots/popular-kitten mounted yes -
# zfs get mounted main-pool/containers/popular-kitten
NAME PROPERTY VALUESOURCE
main-pool/containers/popular-kitten mounted no -
# lxc snapshot popular-kitten
error: Failed to mount ZFS filesystem: filesystem
'main-pool/containers/popular-kitten' is already mounted
cannot mount 'main-pool/containers/popular-kitten': mountpoint or dataset is
busy
# lxc restore popular-kitten snap0
error: Failed to mount ZFS filesystem: filesystem
'main-pool/containers/popular-kitten' is already mounted
cannot mount 'main-pool/containers/popular-kitten': mountpoint or dataset is
busy
but container still work:
# lxc info popular-kitten
Name: popular-kitten
Remote: unix:/var/lib/lxd/unix.socket
Architecture: x86_64
Created: 2017/04/25 07:17 UTC
Status: Running
...
# lxc exec popular-kitten bash
root@popular-kitten:~# uptime
07:34:06 up 8 min, 0 users, load average: 0.00, 0.02, 0.03
after restart container:
# lxc restart popular-kitten
# zfs get mounted main-pool/containers/popular-kitten
NAME PROPERTY VALUESOURCE
main-pool/containers/popular-kitten mounted yes -
on another server this problem missmatch:
# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 16.10
Release:16.10
Codename: yakkety
# lxd --version
2.4.1
zfsutils-linux: 0.6.5.8-0ubuntu4.1
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1686036/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https
[Touch-packages] [Bug 1686361] [NEW] systemd does not respect nofile ulimit when running in container
Public bug reported: When systemd currently starts in a container that has RLIMIT_NOFILE set to e.g. 10 systemd will lower it to 65536 since this value is hard-coded into systemd. I've pushed a patch to systemd upstream that will try to set the nofile limit to the allowed kernel maximum. If this fails, it will compute the minimum of the current set value (the limit that is set on the container) and the maximum value as soft limit and the currently set maximum value as the maximum value. This way it retains the limit set on the container. It would be great if we could backport this patch to have system adhere to nofile limits set for the container. This is especially important since user namespaces will allow you to lower the limit but not raise it back up afterwards. The upstream patch is appended. ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Patch added: "0001-main-improve-RLIMIT_NOFILE-handling-5795.patch" https://bugs.launchpad.net/bugs/1686361/+attachment/4868175/+files/0001-main-improve-RLIMIT_NOFILE-handling-5795.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1686361 Title: systemd does not respect nofile ulimit when running in container Status in systemd package in Ubuntu: New Bug description: When systemd currently starts in a container that has RLIMIT_NOFILE set to e.g. 10 systemd will lower it to 65536 since this value is hard-coded into systemd. I've pushed a patch to systemd upstream that will try to set the nofile limit to the allowed kernel maximum. If this fails, it will compute the minimum of the current set value (the limit that is set on the container) and the maximum value as soft limit and the currently set maximum value as the maximum value. This way it retains the limit set on the container. It would be great if we could backport this patch to have system adhere to nofile limits set for the container. This is especially important since user namespaces will allow you to lower the limit but not raise it back up afterwards. The upstream patch is appended. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1686361/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
Re: [Touch-packages] [Bug 1686361] Re: systemd does not respect nofile ulimit when running in container
Would be good if we could also SRU that to Xenial as well since this is likely what users will be using most of the time as image in their container. Adding stgraber to this thread. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1686361 Title: systemd does not respect nofile ulimit when running in container Status in systemd package in Ubuntu: Confirmed Bug description: When systemd currently starts in a container that has RLIMIT_NOFILE set to e.g. 10 systemd will lower it to 65536 since this value is hard-coded into systemd. I've pushed a patch to systemd upstream that will try to set the nofile limit to the allowed kernel maximum. If this fails, it will compute the minimum of the current set value (the limit that is set on the container) and the maximum value as soft limit and the currently set maximum value as the maximum value. This way it retains the limit set on the container. It would be great if we could backport this patch to have system adhere to nofile limits set for the container. This is especially important since user namespaces will allow you to lower the limit but not raise it back up afterwards. The upstream patch is appended. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1686361/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1686036] Re: strange behavior after restore snapshot
** Changed in: lxc (Ubuntu)
Status: New => In Progress
** Changed in: lxc (Ubuntu)
Assignee: (unassigned) => Christian Brauner (cbrauner)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1686036
Title:
strange behavior after restore snapshot
Status in lxc package in Ubuntu:
In Progress
Bug description:
uname -a
Linux lxd2-chel1 4.4.0-72-generic #93-Ubuntu SMP Fri Mar 31 14:07:41 UTC 2017
x86_64 x86_64 x86_64 GNU/Linux
lxd: 2.12-0ubuntu3~ubuntu16.04.1~ppa1
zfsutils-linux: 0.6.5.6-0ubuntu16
# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 16.04.2 LTS
Release:16.04
Codename: xenial
after restore container from shapshot cannot add new snapshot or restore again
until restart container
example:
# lxc image list
+---+--++--++-+--+
| ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION
| ARCH | SIZE | UPLOAD DATE |
+---+--++--++-+--+
| debian/jessie | ba43812c4cb9 | no | Debian jessie amd64
(20170423_22:42) | x86_64 | 94.14MB | Apr 24, 2017 at 9:07am (UTC) |
+---+--++--++-+--+
# lxc launch debian/jessie
Creating popular-kitten
The container you are starting doesn't have any network attached to it.
To create a new network, use: lxc network create
To attach a network to a container, use: lxc network attach
Starting popular-kitten
# lxc info popular-kitten
Name: popular-kitten
Remote: unix:/var/lib/lxd/unix.socket
Architecture: x86_64
Created: 2017/04/25 07:17 UTC
Status: Running
Type: persistent
Profiles: default
Pid: 6965
Ips:
lo: inet127.0.0.1
lo: inet6 ::1
Resources:
Processes: 7
Disk usage:
root: 1.48MB
CPU usage:
CPU usage (in seconds): 25
Memory usage:
Memory (current): 16.22MB
Memory (peak): 23.01MB
Network usage:
lo:
Bytes received: 0B
Bytes sent: 0B
Packets received: 0
Packets sent: 0
# lxc profile show default
config: {}
description: Default LXD profile
devices:
root:
path: /
pool: main-pool
type: disk
name: default
used_by:
- /1.0/containers/popular-kitten
# lxc snapshot popular-kitten
# zfs get mounted main-pool/containers/popular-kitten
NAME PROPERTY VALUESOURCE
main-pool/containers/popular-kitten mounted yes -
# zfs get mounted main-pool/snapshots/popular-kitten
NAMEPROPERTY VALUESOURCE
main-pool/snapshots/popular-kitten mounted yes -
# lxc restore popular-kitten snap0
# zfs get mounted main-pool/snapshots/popular-kitten
NAMEPROPERTY VALUESOURCE
main-pool/snapshots/popular-kitten mounted yes -
# zfs get mounted main-pool/containers/popular-kitten
NAME PROPERTY VALUESOURCE
main-pool/containers/popular-kitten mounted no -
# lxc snapshot popular-kitten
error: Failed to mount ZFS filesystem: filesystem
'main-pool/containers/popular-kitten' is already mounted
cannot mount 'main-pool/containers/popular-kitten': mountpoint or dataset is
busy
# lxc restore popular-kitten snap0
error: Failed to mount ZFS filesystem: filesystem
'main-pool/containers/popular-kitten' is already mounted
cannot mount 'main-pool/containers/popular-kitten': mountpoint or dataset is
busy
but container still work:
# lxc info popular-kitten
Name: popular-kitten
Remote: unix:/var/lib/lxd/unix.socket
Architecture: x86_64
Created: 2017/04/25 07:17 UTC
Status: Running
...
# lxc exec popular-kitten bash
root@popular-kitten:~# uptime
07:34:06 up 8 min, 0 users, load average: 0.00, 0.02, 0.03
after restart container:
# lxc restart popular-kitten
# zfs get mounted main-pool/containers/popular-kitten
NAME PROPERTY VALUESOURCE
main-pool/containers/popular-kitten mounted yes -
on another server this problem missmatch:
# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 16.10
Release:16.10
Codename: yakkety
# lxd --version
2.4.1
zfsutils-linux: 0.6.5.8-0ubuntu4.1
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1686036/+subscriptions
--
Mailing
[Touch-packages] [Bug 1686036] Re: strange behavior after restore snapshot
** Changed in: lxc (Ubuntu)
Importance: Undecided => High
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1686036
Title:
strange behavior after restore snapshot
Status in lxc package in Ubuntu:
In Progress
Bug description:
uname -a
Linux lxd2-chel1 4.4.0-72-generic #93-Ubuntu SMP Fri Mar 31 14:07:41 UTC 2017
x86_64 x86_64 x86_64 GNU/Linux
lxd: 2.12-0ubuntu3~ubuntu16.04.1~ppa1
zfsutils-linux: 0.6.5.6-0ubuntu16
# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 16.04.2 LTS
Release:16.04
Codename: xenial
after restore container from shapshot cannot add new snapshot or restore again
until restart container
example:
# lxc image list
+---+--++--++-+--+
| ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION
| ARCH | SIZE | UPLOAD DATE |
+---+--++--++-+--+
| debian/jessie | ba43812c4cb9 | no | Debian jessie amd64
(20170423_22:42) | x86_64 | 94.14MB | Apr 24, 2017 at 9:07am (UTC) |
+---+--++--++-+--+
# lxc launch debian/jessie
Creating popular-kitten
The container you are starting doesn't have any network attached to it.
To create a new network, use: lxc network create
To attach a network to a container, use: lxc network attach
Starting popular-kitten
# lxc info popular-kitten
Name: popular-kitten
Remote: unix:/var/lib/lxd/unix.socket
Architecture: x86_64
Created: 2017/04/25 07:17 UTC
Status: Running
Type: persistent
Profiles: default
Pid: 6965
Ips:
lo: inet127.0.0.1
lo: inet6 ::1
Resources:
Processes: 7
Disk usage:
root: 1.48MB
CPU usage:
CPU usage (in seconds): 25
Memory usage:
Memory (current): 16.22MB
Memory (peak): 23.01MB
Network usage:
lo:
Bytes received: 0B
Bytes sent: 0B
Packets received: 0
Packets sent: 0
# lxc profile show default
config: {}
description: Default LXD profile
devices:
root:
path: /
pool: main-pool
type: disk
name: default
used_by:
- /1.0/containers/popular-kitten
# lxc snapshot popular-kitten
# zfs get mounted main-pool/containers/popular-kitten
NAME PROPERTY VALUESOURCE
main-pool/containers/popular-kitten mounted yes -
# zfs get mounted main-pool/snapshots/popular-kitten
NAMEPROPERTY VALUESOURCE
main-pool/snapshots/popular-kitten mounted yes -
# lxc restore popular-kitten snap0
# zfs get mounted main-pool/snapshots/popular-kitten
NAMEPROPERTY VALUESOURCE
main-pool/snapshots/popular-kitten mounted yes -
# zfs get mounted main-pool/containers/popular-kitten
NAME PROPERTY VALUESOURCE
main-pool/containers/popular-kitten mounted no -
# lxc snapshot popular-kitten
error: Failed to mount ZFS filesystem: filesystem
'main-pool/containers/popular-kitten' is already mounted
cannot mount 'main-pool/containers/popular-kitten': mountpoint or dataset is
busy
# lxc restore popular-kitten snap0
error: Failed to mount ZFS filesystem: filesystem
'main-pool/containers/popular-kitten' is already mounted
cannot mount 'main-pool/containers/popular-kitten': mountpoint or dataset is
busy
but container still work:
# lxc info popular-kitten
Name: popular-kitten
Remote: unix:/var/lib/lxd/unix.socket
Architecture: x86_64
Created: 2017/04/25 07:17 UTC
Status: Running
...
# lxc exec popular-kitten bash
root@popular-kitten:~# uptime
07:34:06 up 8 min, 0 users, load average: 0.00, 0.02, 0.03
after restart container:
# lxc restart popular-kitten
# zfs get mounted main-pool/containers/popular-kitten
NAME PROPERTY VALUESOURCE
main-pool/containers/popular-kitten mounted yes -
on another server this problem missmatch:
# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 16.10
Release:16.10
Codename: yakkety
# lxd --version
2.4.1
zfsutils-linux: 0.6.5.8-0ubuntu4.1
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1686036/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More
[Touch-packages] [Bug 1686036] Re: strange behavior after restore snapshot
** Changed in: lxc (Ubuntu)
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1686036
Title:
strange behavior after restore snapshot
Status in lxc package in Ubuntu:
Fix Committed
Bug description:
uname -a
Linux lxd2-chel1 4.4.0-72-generic #93-Ubuntu SMP Fri Mar 31 14:07:41 UTC 2017
x86_64 x86_64 x86_64 GNU/Linux
lxd: 2.12-0ubuntu3~ubuntu16.04.1~ppa1
zfsutils-linux: 0.6.5.6-0ubuntu16
# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 16.04.2 LTS
Release:16.04
Codename: xenial
after restore container from shapshot cannot add new snapshot or restore again
until restart container
example:
# lxc image list
+---+--++--++-+--+
| ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION
| ARCH | SIZE | UPLOAD DATE |
+---+--++--++-+--+
| debian/jessie | ba43812c4cb9 | no | Debian jessie amd64
(20170423_22:42) | x86_64 | 94.14MB | Apr 24, 2017 at 9:07am (UTC) |
+---+--++--++-+--+
# lxc launch debian/jessie
Creating popular-kitten
The container you are starting doesn't have any network attached to it.
To create a new network, use: lxc network create
To attach a network to a container, use: lxc network attach
Starting popular-kitten
# lxc info popular-kitten
Name: popular-kitten
Remote: unix:/var/lib/lxd/unix.socket
Architecture: x86_64
Created: 2017/04/25 07:17 UTC
Status: Running
Type: persistent
Profiles: default
Pid: 6965
Ips:
lo: inet127.0.0.1
lo: inet6 ::1
Resources:
Processes: 7
Disk usage:
root: 1.48MB
CPU usage:
CPU usage (in seconds): 25
Memory usage:
Memory (current): 16.22MB
Memory (peak): 23.01MB
Network usage:
lo:
Bytes received: 0B
Bytes sent: 0B
Packets received: 0
Packets sent: 0
# lxc profile show default
config: {}
description: Default LXD profile
devices:
root:
path: /
pool: main-pool
type: disk
name: default
used_by:
- /1.0/containers/popular-kitten
# lxc snapshot popular-kitten
# zfs get mounted main-pool/containers/popular-kitten
NAME PROPERTY VALUESOURCE
main-pool/containers/popular-kitten mounted yes -
# zfs get mounted main-pool/snapshots/popular-kitten
NAMEPROPERTY VALUESOURCE
main-pool/snapshots/popular-kitten mounted yes -
# lxc restore popular-kitten snap0
# zfs get mounted main-pool/snapshots/popular-kitten
NAMEPROPERTY VALUESOURCE
main-pool/snapshots/popular-kitten mounted yes -
# zfs get mounted main-pool/containers/popular-kitten
NAME PROPERTY VALUESOURCE
main-pool/containers/popular-kitten mounted no -
# lxc snapshot popular-kitten
error: Failed to mount ZFS filesystem: filesystem
'main-pool/containers/popular-kitten' is already mounted
cannot mount 'main-pool/containers/popular-kitten': mountpoint or dataset is
busy
# lxc restore popular-kitten snap0
error: Failed to mount ZFS filesystem: filesystem
'main-pool/containers/popular-kitten' is already mounted
cannot mount 'main-pool/containers/popular-kitten': mountpoint or dataset is
busy
but container still work:
# lxc info popular-kitten
Name: popular-kitten
Remote: unix:/var/lib/lxd/unix.socket
Architecture: x86_64
Created: 2017/04/25 07:17 UTC
Status: Running
...
# lxc exec popular-kitten bash
root@popular-kitten:~# uptime
07:34:06 up 8 min, 0 users, load average: 0.00, 0.02, 0.03
after restart container:
# lxc restart popular-kitten
# zfs get mounted main-pool/containers/popular-kitten
NAME PROPERTY VALUESOURCE
main-pool/containers/popular-kitten mounted yes -
on another server this problem missmatch:
# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 16.10
Release:16.10
Codename: yakkety
# lxd --version
2.4.1
zfsutils-linux: 0.6.5.8-0ubuntu4.1
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1686036/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-
[Touch-packages] [Bug 1686036] Re: strange behavior after restore snapshot
LXD 2.13 doesn't include my fix
https://github.com/lxc/lxd/commit/6c6af18b4ab4720c802a61fa932179562446a4df
yet.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1686036
Title:
strange behavior after restore snapshot
Status in lxc package in Ubuntu:
Fix Committed
Bug description:
uname -a
Linux lxd2-chel1 4.4.0-72-generic #93-Ubuntu SMP Fri Mar 31 14:07:41 UTC 2017
x86_64 x86_64 x86_64 GNU/Linux
lxd: 2.12-0ubuntu3~ubuntu16.04.1~ppa1
zfsutils-linux: 0.6.5.6-0ubuntu16
# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 16.04.2 LTS
Release:16.04
Codename: xenial
after restore container from shapshot cannot add new snapshot or restore again
until restart container
example:
# lxc image list
+---+--++--++-+--+
| ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION
| ARCH | SIZE | UPLOAD DATE |
+---+--++--++-+--+
| debian/jessie | ba43812c4cb9 | no | Debian jessie amd64
(20170423_22:42) | x86_64 | 94.14MB | Apr 24, 2017 at 9:07am (UTC) |
+---+--++--++-+--+
# lxc launch debian/jessie
Creating popular-kitten
The container you are starting doesn't have any network attached to it.
To create a new network, use: lxc network create
To attach a network to a container, use: lxc network attach
Starting popular-kitten
# lxc info popular-kitten
Name: popular-kitten
Remote: unix:/var/lib/lxd/unix.socket
Architecture: x86_64
Created: 2017/04/25 07:17 UTC
Status: Running
Type: persistent
Profiles: default
Pid: 6965
Ips:
lo: inet127.0.0.1
lo: inet6 ::1
Resources:
Processes: 7
Disk usage:
root: 1.48MB
CPU usage:
CPU usage (in seconds): 25
Memory usage:
Memory (current): 16.22MB
Memory (peak): 23.01MB
Network usage:
lo:
Bytes received: 0B
Bytes sent: 0B
Packets received: 0
Packets sent: 0
# lxc profile show default
config: {}
description: Default LXD profile
devices:
root:
path: /
pool: main-pool
type: disk
name: default
used_by:
- /1.0/containers/popular-kitten
# lxc snapshot popular-kitten
# zfs get mounted main-pool/containers/popular-kitten
NAME PROPERTY VALUESOURCE
main-pool/containers/popular-kitten mounted yes -
# zfs get mounted main-pool/snapshots/popular-kitten
NAMEPROPERTY VALUESOURCE
main-pool/snapshots/popular-kitten mounted yes -
# lxc restore popular-kitten snap0
# zfs get mounted main-pool/snapshots/popular-kitten
NAMEPROPERTY VALUESOURCE
main-pool/snapshots/popular-kitten mounted yes -
# zfs get mounted main-pool/containers/popular-kitten
NAME PROPERTY VALUESOURCE
main-pool/containers/popular-kitten mounted no -
# lxc snapshot popular-kitten
error: Failed to mount ZFS filesystem: filesystem
'main-pool/containers/popular-kitten' is already mounted
cannot mount 'main-pool/containers/popular-kitten': mountpoint or dataset is
busy
# lxc restore popular-kitten snap0
error: Failed to mount ZFS filesystem: filesystem
'main-pool/containers/popular-kitten' is already mounted
cannot mount 'main-pool/containers/popular-kitten': mountpoint or dataset is
busy
but container still work:
# lxc info popular-kitten
Name: popular-kitten
Remote: unix:/var/lib/lxd/unix.socket
Architecture: x86_64
Created: 2017/04/25 07:17 UTC
Status: Running
...
# lxc exec popular-kitten bash
root@popular-kitten:~# uptime
07:34:06 up 8 min, 0 users, load average: 0.00, 0.02, 0.03
after restart container:
# lxc restart popular-kitten
# zfs get mounted main-pool/containers/popular-kitten
NAME PROPERTY VALUESOURCE
main-pool/containers/popular-kitten mounted yes -
on another server this problem missmatch:
# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 16.10
Release:16.10
Codename: yakkety
# lxd --version
2.4.1
zfsutils-linux: 0.6.5.8-0ubuntu4.1
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1686036/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Uns
[Touch-packages] [Bug 1653725] Re: lxc-android-config not starting on ubuntu-touch/staging/* xenial-based images after lxc upgrade
** Changed in: lxc (Ubuntu) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1653725 Title: lxc-android-config not starting on ubuntu-touch/staging/* xenial-based images after lxc upgrade Status in Canonical System Image: Confirmed Status in lxc package in Ubuntu: In Progress Status in lxc-android-config package in Ubuntu: New Bug description: As in topic. Since the 20161217 rootfs, after upgrade of lxc from 2.0.5-0ubuntu1~ubuntu16.04.3 to 2.0.6-0ubuntu1~ubuntu16.04.1 the lxc- android-config service does not start - making the devices unbootable. The syslog only states this: Jan 3 10:50:30 ubuntu-phablet systemd[1]: Starting LXC Android Config and Container Initialization... Jan 3 10:50:30 ubuntu-phablet kernel: [5.790810] (3)[1:systemd]SLEEP_EN = 0x1 Jan 3 10:50:30 ubuntu-phablet systemd[1]: Starting Light Display Manager... Jan 3 10:50:30 ubuntu-phablet systemd-udevd[672]: Could not generate persistent MAC address for ifb0: No such file or directory Jan 3 10:50:30 ubuntu-phablet systemd-udevd[684]: Could not generate persistent MAC address for ifb1: No such file or directory Jan 3 10:50:30 ubuntu-phablet lxc-start[1220]: You lack access to /var/lib/lxc Jan 3 10:50:30 ubuntu-phablet systemd[1]: lxc-android-config.service: Control process exited, code=exited status=1 Jan 3 10:50:30 ubuntu-phablet systemd[1]: Failed to start LXC Android Config and Container Initialization. Jan 3 10:50:30 ubuntu-phablet systemd[1]: Dependency failed for force-mtp.service. Jan 3 10:50:30 ubuntu-phablet systemd[1]: force-mtp.service: Job force-mtp.service/start failed with result 'dependency'. Jan 3 10:50:30 ubuntu-phablet systemd[1]: lxc-android-config.service: Unit entered failed state. Jan 3 10:50:30 ubuntu-phablet systemd[1]: lxc-android-config.service: Failed with result 'exit-code'. This makes all of our frieza and cooler devices useless for testing purposes. To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1653725/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1653725] Re: lxc-android-config not starting on ubuntu-touch/staging/* xenial-based images after lxc upgrade
** Changed in: lxc (Ubuntu) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1653725 Title: lxc-android-config not starting on ubuntu-touch/staging/* xenial-based images after lxc upgrade Status in Canonical System Image: Confirmed Status in lxc package in Ubuntu: Fix Committed Status in lxc-android-config package in Ubuntu: New Bug description: As in topic. Since the 20161217 rootfs, after upgrade of lxc from 2.0.5-0ubuntu1~ubuntu16.04.3 to 2.0.6-0ubuntu1~ubuntu16.04.1 the lxc- android-config service does not start - making the devices unbootable. The syslog only states this: Jan 3 10:50:30 ubuntu-phablet systemd[1]: Starting LXC Android Config and Container Initialization... Jan 3 10:50:30 ubuntu-phablet kernel: [5.790810] (3)[1:systemd]SLEEP_EN = 0x1 Jan 3 10:50:30 ubuntu-phablet systemd[1]: Starting Light Display Manager... Jan 3 10:50:30 ubuntu-phablet systemd-udevd[672]: Could not generate persistent MAC address for ifb0: No such file or directory Jan 3 10:50:30 ubuntu-phablet systemd-udevd[684]: Could not generate persistent MAC address for ifb1: No such file or directory Jan 3 10:50:30 ubuntu-phablet lxc-start[1220]: You lack access to /var/lib/lxc Jan 3 10:50:30 ubuntu-phablet systemd[1]: lxc-android-config.service: Control process exited, code=exited status=1 Jan 3 10:50:30 ubuntu-phablet systemd[1]: Failed to start LXC Android Config and Container Initialization. Jan 3 10:50:30 ubuntu-phablet systemd[1]: Dependency failed for force-mtp.service. Jan 3 10:50:30 ubuntu-phablet systemd[1]: force-mtp.service: Job force-mtp.service/start failed with result 'dependency'. Jan 3 10:50:30 ubuntu-phablet systemd[1]: lxc-android-config.service: Unit entered failed state. Jan 3 10:50:30 ubuntu-phablet systemd[1]: lxc-android-config.service: Failed with result 'exit-code'. This makes all of our frieza and cooler devices useless for testing purposes. To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1653725/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
Re: [Touch-packages] [Bug 1646462] Re: lxc container download error (possibly HSTS related)
Hi, Have you tried again after a while. I don't think that this is related to the uid/gid mappings. In order for the download template to work you should have a default lxc config for your unprivileged user configured which would list the uid/gid mapping you want to use, e.g. # Container specific configuration lxc.id_map = u 0 165536 65536 lxc.id_map = g 0 165536 65536 and that's the mapping lxc would use so it shouldn't get confused by overlapping mappings for one and the same user. Also, I can't reproduce this by using overlapping mappings. Christian On Thu, Jan 05, 2017 at 10:08:31AM -, Luke wrote: > I have a suspicion that the error is related to the uid/gid mappings. I > need several mappings for different containers. It all starts to creep > up on any machine configured like so: > > /etc/subuid > > root:10:65536 > root:33:1 > root:100034:65503 > root:503:1 > root:100504:65033 > > > /etc/subgid > > root:10:65536 > root:33:1 > root:100034:65503 > root:109:1 > root:100110:65427 > > > My hunch is that the download script fails to recognize which mapping it > should use for the container filesystem it is extracting onto the disk. > > -- > You received this bug notification because you are a member of Ubuntu > containers team, which is subscribed to lxc in Ubuntu. > Matching subscriptions: lxc > https://bugs.launchpad.net/bugs/1646462 > > Title: > lxc container download error (possibly HSTS related) > > Status in lxc package in Ubuntu: > Confirmed > > Bug description: > LXC cannot download image, seems like a server error: > > ~# lxc-create -t download -n test > Setting up the GPG keyring > Downloading the image index > ERROR: Failed to download > http://images.linuxcontainers.org//meta/1.0/index-user > lxc-create: lxccontainer.c: create_run_template: 1290 container creation > template for test failed > lxc-create: tools/lxc_create.c: main: 318 Error creating container test > > Trying to download the file with wget gets the file OK with minor > complaints: > > ~# wget -O /dev/null > 'http://images.linuxcontainers.org//meta/1.0/index-user' > URL transformed to HTTPS due to an HSTS policy > --2016-12-01 12:36:58-- > https://images.linuxcontainers.org//meta/1.0/index-user > Resolving images.linuxcontainers.org (images.linuxcontainers.org)... > 91.189.88.37, 91.189.91.21 > Connecting to images.linuxcontainers.org > (images.linuxcontainers.org)|91.189.88.37|:443... connected. > HTTP request sent, awaiting response... 301 Moved Permanently > Location: https://uk.images.linuxcontainers.org/meta/1.0/index-user > [following] > --2016-12-01 12:36:58-- > https://uk.images.linuxcontainers.org/meta/1.0/index-user > Resolving uk.images.linuxcontainers.org (uk.images.linuxcontainers.org)... > 91.189.88.37 > Connecting to uk.images.linuxcontainers.org > (uk.images.linuxcontainers.org)|91.189.88.37|:443... connected. > HTTP request sent, awaiting response... 200 OK > Length: 9102 (8.9K) > Saving to: ‘/dev/null’ > > Seems like some SSL problem in the lxc-create binary, specifically the > HSTS issue mentioned by wget. Maybe a newly introduced HSTS policy > breaks the package? > > ProblemType: Bug > DistroRelease: Ubuntu 16.10 > Package: lxc 2.0.5-0ubuntu1.2 > ProcVersionSignature: Ubuntu 4.8.0-28.30-generic 4.8.6 > Uname: Linux 4.8.0-28-generic x86_64 > NonfreeKernelModules: zfs zunicode zcommon znvpair zavl > ApportVersion: 2.20.3-0ubuntu8 > Architecture: amd64 > Date: Thu Dec 1 12:28:28 2016 > InstallationDate: Installed on 2016-10-14 (47 days ago) > InstallationMedia: Ubuntu-Server 16.10 "Yakkety Yak" - Release amd64 > (20161012.1) > PackageArchitecture: all > SourcePackage: lxc > UpgradeStatus: No upgrade log present (probably fresh install) > dnsmasq.conf: > dhcp-host=vold,10.0.3.10 > dhcp-host=sftp,10.0.3.11 > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1646462/+subscriptions -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1646462 Title: lxc container download error (possibly HSTS related) Status in lxc package in Ubuntu: Confirmed Bug description: LXC cannot download image, seems like a server error: ~# lxc-create -t download -n test Setting up the GPG keyring Downloading the image index ERROR: Failed to download http://images.linuxcontainers.org//meta/1.0/index-user lxc-create: lxccontainer.c: create_run_template: 1290 container creation template for test failed lxc-create: tools/lxc_create.c: main: 318 Error creating container test Trying to download the file with wget gets the file OK with minor complaints: ~# wget -O /dev/null 'http://images.linuxcontainers.org//meta/1.0/index-u
[Touch-packages] [Bug 1657437] Re: Unprivileged containers run by non-root fail to start if trying to bind-mount a directory that contains a mounted ecryptfs
Hi, this is not a bug. What you want is to recursively bind-mount: lxc.mount.entry = /home home none rbind,create=dir 0 0 Christian -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1657437 Title: Unprivileged containers run by non-root fail to start if trying to bind-mount a directory that contains a mounted ecryptfs Status in lxc package in Ubuntu: New Bug description: Not sure if this is an lxc bug or an ecryptfs bug. Please reassign if necessary. I have an unprivileged container that is defined in the default location, ~/.share/local/lxc. It bind-mounts the host's /home directory to /home inside the container, like so: lxc.mount.entry = /home home none bind 0 0 My /home directory contains an ecryptfs at ~/.Private, which is mounted to ~/Private with default options, at login, via pam_ecryptfs. lxc-start then results in the following error showing up in the log file: lxc-start 20170118124950.117 ERRORlxc_utils - utils.c:safe_mount:1746 - Invalid argument - Failed to mount /home onto /usr/lib/x86_64-linux-gnu/lxc/home lxc-start 20170118124950.117 ERRORlxc_conf - conf.c:mount_entry:1650 - Invalid argument - failed to mount '/home' on '/usr/lib/x86_64-linux-gnu/lxc/home' lxc-start 20170118124950.117 ERRORlxc_conf - conf.c:lxc_setup:3790 - failed to setup the mount entries for 'trusty-edx-devstack' lxc-start 20170118124950.117 ERRORlxc_start - start.c:do_start:826 - Failed to setup container "trusty-edx-devstack". lxc-start 20170118124950.117 ERRORlxc_sync - sync.c:__sync_wait:57 - An error occurred in another process (expected sequence number 3) lxc-start 20170118124950.118 ERRORlxc_start - start.c:__lxc_start:1338 - Failed to spawn container "trusty-edx-devstack". lxc-start 20170118124955.668 ERRORlxc_start_ui - tools/lxc_start.c:main:360 - The container failed to start. Unmounting the ecryptfs allows the container to start normally. After the container has been started, the ecryptfs can be remounted with ecryptfs-mount-private, which appears to have no ill effect on the container. I don't quite see why the mounted ecryptfs would prevent /home from being bind-mounted into the container. After all, bind-mounting /home to some other mount point in the host works just fine — with the Private directory simply being empty, save for the Access-Your- Private-Data.desktop and README.txt symlinks, in the bind mount location. This is also what happens in privileged containers whose configuration has the same lxc.mount.entry. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1657437/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
Re: [Touch-packages] [Bug 1641236] Re: Confined processes inside container cannot fully access host pty device passed in by lxc exec
I've reproduced this on a fresh standard xenial instance with LXD
2.0.8 and also on a xenial instance with a patched glibc that reports
ENODEV on ttyname{_r}() on a pty fd that does not exist:
root@x:~# ./enodev_on_pty_in_different_namespace
ttyname(): The pty device might exist in a different namespace: No such device
ttyname_r(): The pty device might exist in a different namespace: No such device
** Attachment added: "enodev_on_pty_in_different_namespace.c"
https://bugs.launchpad.net/bugs/1641236/+attachment/4811239/+files/enodev_on_pty_in_different_namespace.c
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1641236
Title:
Confined processes inside container cannot fully access host pty
device passed in by lxc exec
Status in apparmor package in Ubuntu:
New
Status in lxd package in Ubuntu:
Invalid
Bug description:
Now that AppArmor policy namespaces and profile stacking is in place,
I noticed odd stdout buffering behavior when running confined
processes via lxc exec. Much more data stdout data is buffered before
getting flushed when the program is confined by an AppArmor profile
inside of the container.
I see that lxd is calling openpty(3) in the host environment, using
the returned fd as stdout, and then executing the command inside of
the container. This results in an AppArmor denial because the file
descriptor returned by openpty(3) originates outside of the namespace
used by the container.
The denial is likely from glibc calling fstat(), from inside the
container, on the file descriptor associated with stdout to make a
decision on how much buffering to use. The fstat() is denied by
AppArmor and glibc ends up handling the buffering differently than it
would if the fstat() would have been successful.
Steps to reproduce (using an up-to-date 16.04 amd64 VM):
Create a 16.04 container
$ lxc launch ubuntu-daily:16.04 x
Run tcpdump in one terminal and generate traffic in another terminal (wget
google.com)
$ lxc exec x -- tcpdump -i eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
47 packets captured
48 packets received by filter
1 packet dropped by kernel
Note that everything above was printed immediately
because it was printed to stderr. , which is printed to
stdout, was not printed until you pressed ctrl-c and the buffers were
flushed thanks to the program terminating. Also, this AppArmor denial
shows up in the logs:
audit: type=1400 audit(1478902710.025:440): apparmor="DENIED"
operation="getattr" info="Failed name lookup - disconnected path"
error=-13 namespace="root//lxd-x_"
profile="/usr/sbin/tcpdump" name="dev/pts/12" pid=15530 comm="tcpdump"
requested_mask="r" denied_mask="r" fsuid=165536 ouid=165536
Now run tcpdump unconfined and take note that is printed
immediately, before you terminate tcpdump. Also, there are no AppArmor denials.
$ lxc exec x -- aa-exec -p unconfined -- tcpdump -i eth0
...
Now run tcpdump confined but in lxc exec's non-interactive mode and note that
is printed immediately and no AppArmor denials are present.
(Looking at the lxd code in lxd/container_exec.go, openpty(3) is only called in
interactive mode)
$ lxc exec x --mode=non-interactive -- tcpdump -i eth0
...
Applications that manually call fflush(stdout) are not affected by
this as manually flushing stdout works fine. The problem seems to be
caused by glibc not being able to fstat() the /dev/pts/12 fd from the
host's namespace.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1641236/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
Re: [Touch-packages] [Bug 1641236] Re: Confined processes inside container cannot fully access host pty device passed in by lxc exec
On Tue, Jan 31, 2017 at 11:34:43AM +0100, Christian Brauner wrote:
> I've reproduced this on a fresh standard xenial instance with LXD
> 2.0.8 and also on a xenial instance with a patched glibc that reports
> ENODEV on ttyname{_r}() on a pty fd that does not exist:
>
> root@x:~# ./enodev_on_pty_in_different_namespace
> ttyname(): The pty device might exist in a different namespace: No such device
> ttyname_r(): The pty device might exist in a different namespace: No such
> device
So to make this a little more elaborate:
- I managed to reproduce this with an unpatched glibc inside and outside the
container just like @Tyler outlined.
- I managed to reproduce this with a patched glibc inside the container and an
unpatched glibc outside the container.
- I managed to reproduce this with a patched glibc inside and outside the
container.
So a patched glibc which returns ENODEV in case a symlink like /proc/self/fd/0
points to a pts device that lives in another namespace does not improve the
situation. The problem that @Tyler outlined still exists.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1641236
Title:
Confined processes inside container cannot fully access host pty
device passed in by lxc exec
Status in apparmor package in Ubuntu:
New
Status in lxd package in Ubuntu:
Invalid
Bug description:
Now that AppArmor policy namespaces and profile stacking is in place,
I noticed odd stdout buffering behavior when running confined
processes via lxc exec. Much more data stdout data is buffered before
getting flushed when the program is confined by an AppArmor profile
inside of the container.
I see that lxd is calling openpty(3) in the host environment, using
the returned fd as stdout, and then executing the command inside of
the container. This results in an AppArmor denial because the file
descriptor returned by openpty(3) originates outside of the namespace
used by the container.
The denial is likely from glibc calling fstat(), from inside the
container, on the file descriptor associated with stdout to make a
decision on how much buffering to use. The fstat() is denied by
AppArmor and glibc ends up handling the buffering differently than it
would if the fstat() would have been successful.
Steps to reproduce (using an up-to-date 16.04 amd64 VM):
Create a 16.04 container
$ lxc launch ubuntu-daily:16.04 x
Run tcpdump in one terminal and generate traffic in another terminal (wget
google.com)
$ lxc exec x -- tcpdump -i eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
47 packets captured
48 packets received by filter
1 packet dropped by kernel
Note that everything above was printed immediately
because it was printed to stderr. , which is printed to
stdout, was not printed until you pressed ctrl-c and the buffers were
flushed thanks to the program terminating. Also, this AppArmor denial
shows up in the logs:
audit: type=1400 audit(1478902710.025:440): apparmor="DENIED"
operation="getattr" info="Failed name lookup - disconnected path"
error=-13 namespace="root//lxd-x_"
profile="/usr/sbin/tcpdump" name="dev/pts/12" pid=15530 comm="tcpdump"
requested_mask="r" denied_mask="r" fsuid=165536 ouid=165536
Now run tcpdump unconfined and take note that is printed
immediately, before you terminate tcpdump. Also, there are no AppArmor denials.
$ lxc exec x -- aa-exec -p unconfined -- tcpdump -i eth0
...
Now run tcpdump confined but in lxc exec's non-interactive mode and note that
is printed immediately and no AppArmor denials are present.
(Looking at the lxd code in lxd/container_exec.go, openpty(3) is only called in
interactive mode)
$ lxc exec x --mode=non-interactive -- tcpdump -i eth0
...
Applications that manually call fflush(stdout) are not affected by
this as manually flushing stdout works fine. The problem seems to be
caused by glibc not being able to fstat() the /dev/pts/12 fd from the
host's namespace.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1641236/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1690125] Re: hybrid control goup mode breaks lxc adt tests
Hey everyone, Uust as an fyi: I sent a branch https://github.com/lxc/lxc/pull/1713 which is now merged that makes LXC handle the hybrid cgroup case provided the cgroup v2 mount does not bind any controllers (Which is the current default). It will be included in the next LXC release. Thanks! Christian -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1690125 Title: hybrid control goup mode breaks lxc adt tests Status in lxc: New Status in apparmor package in Ubuntu: Incomplete Status in lxc package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Incomplete Bug description: I will disably hybrid control groups by default for now, but will create a ppa with such systemd, for ease of testing. FAIL: lxc-tests: /usr/bin/lxc-test-apparmor-mount --- /usr/sbin/deluser: The user `lxcunpriv' does not exist. /usr/bin/lxc-test-apparmor-mount: 138: /usr/bin/lxc-test-apparmor-mount: cannot create /sys/fs/cgroup/unified/lxctest/tasks: Permission denied Container is not defined umount: /sys/kernel/security/apparmor/features/mount: not mounted --- FAIL: lxc-tests: /usr/bin/lxc-test-unpriv --- Removing user `lxcunpriv' ... Warning: group `lxcunpriv' has no more members. Done. /usr/bin/lxc-test-unpriv: line 154: /sys/fs/cgroup/unified/lxctest/tasks: Permission denied c2 is not running c1 is not running --- FAIL: lxc-tests: /usr/bin/lxc-test-usernic --- /usr/sbin/deluser: The user `usernic-user' does not exist. /usr/bin/lxc-test-usernic: line 111: /sys/fs/cgroup/unified/lxctest/tasks: Permission denied FAIL --- PASS: lxc-tests: /usr/bin/lxc-test-utils PASS: python3: API Removing 'local diversion of /usr/bin/dirmngr to /usr/bin/dirmngr.orig' CHANGES WITH 233: * The "hybrid" control group mode has been modified to improve compatibility with "legacy" cgroups-v1 setups. Specifically, the "hybrid" setup of /sys/fs/cgroup is now pretty much identical to "legacy" (including /sys/fs/cgroup/systemd as "name=systemd" named cgroups-v1 hierarchy), the only externally visible change being that the cgroups-v2 hierarchy is also mounted, to /sys/fs/cgroup/unified. This should provide a large degree of compatibility with "legacy" cgroups-v1, while taking benefit of the better management capabilities of cgroups-v2. * The default control group setup mode may be selected both a boot-time via a set of kernel command line parameters (specifically: systemd.unified_cgroup_hierarchy= and systemd.legacy_systemd_cgroup_controller=), as well as a compile-time default selected on the configure command line (--with-default-hierarchy=). The upstream default is "hybrid" (i.e. the cgroups-v1 + cgroups-v2 mixture discussed above) now, but this will change in a future systemd version to be "unified" (pure cgroups-v2 mode). The third option for the compile time option is "legacy", to enter pure cgroups-v1 mode. We recommend downstream distributions to default to "hybrid" mode for release distributions, starting with v233. We recommend "unified" for development distributions (specifically: distributions such as Fedora's rawhide) as that's where things are headed in the long run. Use "legacy" for greatest stability and compatibility only. * Note one current limitation of "unified" and "hybrid" control group setup modes: the kernel currently does not permit the systemd --user instance (i.e. unprivileged code) to migrate processes between two disconnected cgroup subtrees, even if both are managed and owned by the user. This effectively means "systemd-run --user --scope" doesn't work when invoked from outside of any "systemd --user" service or scope. Specifically, it is not supported from session scopes. We are working on fixing this in a future systemd version. (See #3388 for further details about this.) To manage notifications about this bug go to: https://bugs.launchpad.net/lxc/+bug/1690125/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1713726] Re: lxc 2.0.8-0ubuntu6 ADT test failure with linux 4.13.0-7.8
Has the `/etc/init/` directory and associated files been removed from artful I remember @xnox removing old init scripts. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1713726 Title: lxc 2.0.8-0ubuntu6 ADT test failure with linux 4.13.0-7.8 Status in lxc package in Ubuntu: New Bug description: Testing failed on: amd64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-canonical-kernel-team-unstable/artful/amd64/l/lxc/20170829_024349_c4b5f@/log.gz i386: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-canonical-kernel-team-unstable/artful/i386/l/lxc/20170829_025427_c4b5f@/log.gz ppc64el: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-canonical-kernel-team-unstable/artful/ppc64el/l/lxc/20170829_024824_c4b5f@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1713726/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1692111] Re: Unable to configure raw.id_map with multiple entries
** Changed in: lxc (Ubuntu) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1692111 Title: Unable to configure raw.id_map with multiple entries Status in lxc package in Ubuntu: Fix Released Status in lxd package in Ubuntu: Invalid Bug description: I am trying to map two users (999, 1001) to one of my containers. I added both IDs to /etc/subgid and /etc/subuid. I followed by setting raw.id_map property value (as instructed here https://lists.linuxcontainers.org/pipermail/lxc- users/2017-March/013034.html): "echo -e "both 999 999\nboth 1001 1001" | lxc config set mycontainer raw.idmap -" However upon starting the container, I get errors (log excerpt below). If, on the other hand, I set idmap to either "both 999 999" or "both 1001 1001" only - i.e. if I map only one user at the time, the container starts just fine and the user is mapped as expected. My subgid and subuid look as follows: lxd:10:65536 root:10:65536 root:1001:1 root:999:1 Log excerpt: Name: mycontainer Remote: unix:/var/lib/lxd/unix.socket Architecture: x86_64 Created: 2017/02/22 18:54 UTC Status: Stopped Type: persistent Profiles: default Log: lxc 20170519204102.895 ERRORlxc_cgfsng - cgroups/cgfsng.c:create_path_for_hierarchy:1306 - Path "/sys/fs/cgroup/systemd//lxc/mycontainer" already existed. lxc 20170519204102.896 ERRORlxc_cgfsng - cgroups/cgfsng.c:cgfsng_create:1363 - No such file or directory - Failed to create /sys/fs/cgroup/systemd//lxc/mycontainer: No such file or directory lxc 20170519204102.897 ERRORlxc_cgfsng - cgroups/cgfsng.c:create_path_for_hierarchy:1306 - Path "/sys/fs/cgroup/systemd//lxc/mycontainer-1" already existed. lxc 20170519204102.897 ERRORlxc_cgfsng - cgroups/cgfsng.c:cgfsng_create:1363 - No such file or directory - Failed to create /sys/fs/cgroup/systemd//lxc/mycontainer-1: No such file or directory lxc 20170519204102.897 ERRORlxc_cgfsng - cgroups/cgfsng.c:create_path_for_hierarchy:1306 - Path "/sys/fs/cgroup/systemd//lxc/mycontainer-2" already existed. lxc 20170519204102.898 ERRORlxc_cgfsng - cgroups/cgfsng.c:cgfsng_create:1363 - No such file or directory - Failed to create /sys/fs/cgroup/systemd//lxc/mycontainer-2: No such file or directory lxc 20170519204102.898 ERRORlxc_cgfsng - cgroups/cgfsng.c:create_path_for_hierarchy:1306 - Path "/sys/fs/cgroup/systemd//lxc/mycontainer-3" already existed. lxc 20170519204102.898 ERRORlxc_cgfsng - cgroups/cgfsng.c:cgfsng_create:1363 - No such file or directory - Failed to create /sys/fs/cgroup/systemd//lxc/mycontainer-3: No such file or directory lxc 20170519204102.898 ERRORlxc_cgfsng - cgroups/cgfsng.c:create_path_for_hierarchy:1306 - Path "/sys/fs/cgroup/systemd//lxc/mycontainer-4" already existed. lxc 20170519204102.898 ERRORlxc_cgfsng - cgroups/cgfsng.c:cgfsng_create:1363 - No such file or directory - Failed to create /sys/fs/cgroup/systemd//lxc/mycontainer-4: No such file or directory lxc 20170519204102.899 ERRORlxc_cgfsng - cgroups/cgfsng.c:create_path_for_hierarchy:1306 - Path "/sys/fs/cgroup/systemd//lxc/mycontainer-5" already existed. lxc 20170519204102.899 ERRORlxc_cgfsng - cgroups/cgfsng.c:cgfsng_create:1363 - No such file or directory - Failed to create /sys/fs/cgroup/systemd//lxc/mycontainer-5: No such file or directory lxc 20170519204102.899 ERRORlxc_cgfsng - cgroups/cgfsng.c:create_path_for_hierarchy:1306 - Path "/sys/fs/cgroup/systemd//lxc/mycontainer-6" already existed. lxc 20170519204102.899 ERRORlxc_cgfsng - cgroups/cgfsng.c:cgfsng_create:1363 - No such file or directory - Failed to create /sys/fs/cgroup/systemd//lxc/mycontainer-6: No such file or directory lxc 20170519204102.900 ERRORlxc_cgfsng - cgroups/cgfsng.c:create_path_for_hierarchy:1306 - Path "/sys/fs/cgroup/systemd//lxc/mycontainer-7" already existed. lxc 20170519204102.900 ERRORlxc_cgfsng - cgroups/cgfsng.c:cgfsng_create:1363 - No such file or directory - Failed to create /sys/fs/cgroup/systemd//lxc/mycontainer-7: No such file or directory lxc 20170519204102.900 ERRORlxc_cgfsng - cgroups/cgfsng.c:create_path_for_hierarchy:1306 - Path "/sys/fs/cgroup/systemd//lxc/mycontainer-8" already existed. lxc 20170519204102.900 ERRORlxc_cgfsng - cgroups/cgfsng.c:cgfsng_create:1363 - No such file or directory - Failed to create /sys/fs/cgroup/systemd//lxc/mycontainer-8: No such file or directory lxc 20170519204102.901 ERRORlxc_cgfsng - cgroups/cgfsng.c:create_path_for_hierarchy:1306 - Path "/sys/fs/cgro
[Touch-packages] [Bug 1668049] Re: lxd cannot shutdown container
Note, that since a while LXC is sending SIGRTMIN+3 to systemd. So unless systemd has changed it's shutdown/halt signal again LXC should send the right signal. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1668049 Title: lxd cannot shutdown container Status in systemd package in Ubuntu: New Bug description: I found this issue when working with lxd and submitted a ticket there but the lxc people said it was related to systemd, not lxc. The issue is: I have a container running under lxc/lxd. lxc stop of the container does not work whereas if I execute "shutdown now" inside the container it does stop as expected. The associated lxd ticket is here: https://github.com/lxc/lxd/issues/2947 The output of journalctl -a is at the end of this message The syslog of that same run can be found here: http://paste.ubuntu.com/24071244/ and this is the output of ps aux: USERPID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.1 37808 4576 ?Ss 11:19 0:00 /sbin/init root 48 0.0 0.0 35276 3004 ?Ss 11:19 0:00 /lib/systemd/systemd-journald root 49 0.0 0.0 41724 1912 ?Ss 11:19 0:00 /lib/systemd/systemd-udevd message+514 0.0 0.0 42900 2460 ?Ss 11:19 0:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation root704 0.0 0.0 18252 2508 ?Ss 11:55 0:00 bash root720 0.0 0.0 34556 1992 ?R+ 11:59 0:00 ps aux Note that this may be timing related. If I stop the container immediately after starting things work. If I stop after a minute or so, the stop will not get through. (even not on a 2nd or 3rd attempt). However if I leave the container for a while then a new lxc stop will terminate the container. (this happened after an hour or so). The issue is reproducible but seems to be dependend on what is running inside the container. container runs ubuntu 16.04 on a 16.04 host. systemd --version says: systemd 229 +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN lxc sends SIGRTMIN+3 to systemd to stop. This was apparently discussed here: https://github.com/lxc/lxc/issues/1085 Let me know if more info is needed. Frans -- Logs begin at Sun 2017-02-26 11:19:12 UTC, end at Sun 2017-02-26 11:23:05 UTC. -- Feb 26 11:19:12 D-wan-61-1 systemd-journald[48]: Runtime journal (/run/log/journal/) is 8.0M, max 196.7M, 188.7M free. Feb 26 11:19:12 D-wan-61-1 systemd-journald[48]: Journal started Feb 26 11:19:12 D-wan-61-1 systemd-sysctl[42]: Couldn't write '4 4 1 7' to 'kernel/printk', ignoring: Permission denied Feb 26 11:19:12 D-wan-61-1 systemd-sysctl[42]: Couldn't write '176' to 'kernel/sysrq', ignoring: Permission denied Feb 26 11:19:12 D-wan-61-1 systemd-sysctl[42]: Couldn't write '1' to 'fs/protected_symlinks', ignoring: Permission denied Feb 26 11:19:12 D-wan-61-1 systemd-sysctl[42]: Couldn't write '1' to 'net/ipv4/tcp_syncookies', ignoring: No such file or directory Feb 26 11:19:12 D-wan-61-1 systemd-sysctl[42]: Couldn't write '1' to 'kernel/kptr_restrict', ignoring: Permission denied Feb 26 11:19:12 D-wan-61-1 systemd-sysctl[42]: Couldn't write '1' to 'fs/protected_hardlinks', ignoring: Permission denied Feb 26 11:19:12 D-wan-61-1 systemd-sysctl[42]: Couldn't write '1' to 'kernel/yama/ptrace_scope', ignoring: Permission denied Feb 26 11:19:12 D-wan-61-1 systemd-sysctl[42]: Couldn't write '65536' to 'vm/mmap_min_addr', ignoring: Permission denied Feb 26 11:19:12 D-wan-61-1 systemd[1]: systemd-sysctl.service: Main process exited, code=exited, status=1/FAILURE Feb 26 11:19:12 D-wan-61-1 systemd[1]: Failed to start Apply Kernel Variables. Feb 26 11:19:12 D-wan-61-1 systemd[1]: systemd-sysctl.service: Unit entered failed state. Feb 26 11:19:12 D-wan-61-1 systemd[1]: systemd-sysctl.service: Failed with result 'exit-code'. Feb 26 11:19:12 D-wan-61-1 systemd-journald[48]: Forwarding to syslog missed 1 messages. Feb 26 11:19:12 D-wan-61-1 systemd[1]: Started Uncomplicated firewall. Feb 26 11:19:12 D-wan-61-1 systemd[1]: Failed to reset devices.list on /system.slice/ufw.service: Operation not permitted Feb 26 11:19:12 D-wan-61-1 systemd[1]: Started udev Kernel Device Manager. Feb 26 11:19:12 D-wan-61-1 mount[45]: mount: permission denied Feb 26 11:19:12 D-wan-61-1 systemd[1]: Started Nameserver information manager. Feb 26 11:19:12 D-wan-61-1 systemd[1]: dev-hugepages.mount: Mount process exited, code=exited status=32 Feb 26 11:19:12 D-wan-61-1 systemd[1]: Failed to mount Huge Pages File System. Feb 26 11:19:12 D-wan-61-1 systemd[1]: dev-hugepages.mount: Unit entered failed state. Feb 26 1
[Touch-packages] [Bug 1654676] Re: lxc-user-nic does not ensure that target netns is caller-owned
** Changed in: lxc (Ubuntu) Assignee: (unassigned) => Christian Brauner (cbrauner) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1654676 Title: lxc-user-nic does not ensure that target netns is caller-owned Status in lxc package in Ubuntu: Fix Released Bug description: The documentation for lxc-user-nic claims: It ensures that the calling user is privileged over the network namespace to which the interface will be attached. Actually, the code only verifies that a process of the calling user is running in the network namespace to which the interface will be attached. To verify this: - As root, create a new bridge "lxcbr0". - As root, add an entry like "user veth lxcbr0 10" to /etc/lxc/lxc-usernet. - As the user specified in /etc/lxc/lxc-usernet, run the following command: /usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic a b $$ veth lxcbr0 foobar - Run "ip link show foobar". The output shows that a network interface with the name "foobar" was created in the init namespace (in which the user is not privileged). I suspect that it would also be possible to trick lxc-user-nic into operating on namespaces the caller can't access by reassigning the PID while lxc-user-nic is running, between the access check and the netlink calls - this is probably quite hard to fix, considering that the netlink interface just uses a PID to identify the target namespace. I haven't found any way to actually exploit this; however, it seems interesting that this can e.g. be used to create network interfaces whose names contain special characters like dollar, semicolon and backtick. I'm not sure how dangerous that is - I'm reporting it as a security bug for now, but if you feel that this has no security impact, feel free to derestrict it. One way to fix this might be to temporarily drop privileges (setresuid(ruid, ruid, 0)) in rename_in_ns() after the first setns() call. This way, the renaming could only succeed if the caller is actually privileged in the network namespace. release: Ubuntu 16.10 version: lxc-common: 2.0.6-0ubuntu1~ubuntu16.10.1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1654676/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1690822] Re: GPU device in lxc profile ignored?
I couldn't reproduce this behavior locally. - We'd need the logs for the daemon and the corresponding containers in question from /var/log/lxd/*, please. - Please also show cat /proc/1/mountinfo from inside one of those containers that doesn't mount the gpu device. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1690822 Title: GPU device in lxc profile ignored? Status in lxc package in Ubuntu: New Bug description: I am trying to add the gpu device in an profile so that new containers come up with gpu available. Even though the gpu device is in the profile it seems it is ignored. In this pastebin http://pastebin.ubuntu.com/24579662/ you can see the profile with the gpu device. We add a new container (juju add-unit) and we check if the device is there. It is not, so we add it (lxc config device add) after the container comes up. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1690822/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1690822] Re: GPU device in lxc profile ignored?
chb@conventiont|~ > lxc profile show dummy config: security.nesting: "true" security.privileged: "true" description: "" devices: gpu: type: gpu name: dummy used_by: - /1.0/containers/alp1 - /1.0/containers/alpgpu -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1690822 Title: GPU device in lxc profile ignored? Status in lxc package in Ubuntu: New Bug description: I am trying to add the gpu device in an profile so that new containers come up with gpu available. Even though the gpu device is in the profile it seems it is ignored. In this pastebin http://pastebin.ubuntu.com/24579662/ you can see the profile with the gpu device. We add a new container (juju add-unit) and we check if the device is there. It is not, so we add it (lxc config device add) after the container comes up. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1690822/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1690822] Re: GPU device in lxc profile ignored?
I've used your exact profile now: https://paste.ubuntu.com/24586449/ -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1690822 Title: GPU device in lxc profile ignored? Status in lxc package in Ubuntu: New Bug description: I am trying to add the gpu device in an profile so that new containers come up with gpu available. Even though the gpu device is in the profile it seems it is ignored. In this pastebin http://pastebin.ubuntu.com/24579662/ you can see the profile with the gpu device. We add a new container (juju add-unit) and we check if the device is there. It is not, so we add it (lxc config device add) after the container comes up. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1690822/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1690822] Re: GPU device in lxc profile ignored?
On Thu, May 18, 2017 at 08:09:05AM -, Konstantinos Tsakalozos wrote: > I can confirm that "ls -al /dev/dri/" within the lxc container shows the > devices you expect. However, "lxc config show xen2" shows the devices > section being empty. This isn't a bug at all. :) You're adding a device to a profile the container is attached to. By definition it will thus not be in the container's config file. The container will just gather all the devices it needs to create and setup from the profile it is attached to. It will never show up in the container's config file unless you explicitly add it. ** Changed in: lxc (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1690822 Title: GPU device in lxc profile ignored? Status in lxc package in Ubuntu: Invalid Bug description: I am trying to add the gpu device in an profile so that new containers come up with gpu available. Even though the gpu device is in the profile it seems it is ignored. In this pastebin http://pastebin.ubuntu.com/24579662/ you can see the profile with the gpu device. We add a new container (juju add-unit) and we check if the device is there. It is not, so we add it (lxc config device add) after the container comes up. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1690822/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1824812] Re: apparmor does not start in Disco LXD containers
Okay, I have a fix for the shiftfs side I think. Attached here. ** Patch added: "UBUNTU: SAUCE: shiftfs: use correct llseek method for" https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1824812/+attachment/5256074/+files/0001-UBUNTU-SAUCE-shiftfs-use-correct-llseek-method-for-d.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1824812 Title: apparmor does not start in Disco LXD containers Status in AppArmor: Triaged Status in apparmor package in Ubuntu: In Progress Status in libvirt package in Ubuntu: Invalid Status in linux package in Ubuntu: Confirmed Bug description: In LXD apparmor now skips starting. Steps to reproduce: 1. start LXD container $ lxc launch ubuntu-daily:d d-testapparmor (disco to trigger the issue, cosmic as reference) 2. check the default profiles loaded $ aa-status => This will in cosmic and up to recently disco list plenty of profiles active even in the default install. Cosmic: 25 profiles are loaded. 25 profiles are in enforce mode. Disco: 15 profiles are loaded. 15 profiles are in enforce mode. All those 15 remaining are from snaps. The service of apparmor.service actually states that it refuses to start. $ systemctl status apparmor ... Apr 15 13:56:12 testkvm-disco-to apparmor.systemd[101]: Not starting AppArmor in container I can get those profiles (the default installed ones) loaded, for example: $ sudo apparmor_parser -r /etc/apparmor.d/sbin.dhclient makes it appear 22 profiles are in enforce mode. /sbin/dhclient I was wondering as in my case I found my guest with no (=0) profiles loaded. But as shown above after "apparmor_parser -r" and package install profiles seemed fine. Then the puzzle was solved, on package install they will call apparmor_parser via the dh_apparmor snippet and it is fine. To fully disable all of them: $ lxc stop $ lxc start $ lxc exec d-testapparmor aa-status apparmor module is loaded. 0 profiles are loaded. 0 profiles are in enforce mode. 0 profiles are in complain mode. 0 processes have profiles defined. 0 processes are in enforce mode. 0 processes are in complain mode. 0 processes are unconfined but have a profile defined. That would match the service doing an early exit as shown in systemctl status output above. The package install or manual load works, but none are loaded by the service automatically e.g. on container restart. --- --- --- This bug started as: Migrations to Disco trigger "Unable to find security driver for model apparmor" This most likely is related to my KVM-in-LXD setup but it worked fine for years and I'd like to sort out what broke. I have migrated to Disco's qemu 3.1 already which makes me doubts generic issues in qemu 3.1 in general. The virt tests that run cross release work fine starting from X/B/C but all those chains fail at mirgating to Disco now with: $ lxc exec testkvm-cosmic-from -- virsh migrate --unsafe --live kvmguest-bionic-normal qemu+ssh://10.21.151.207/system error: unsupported configuration: Unable to find security driver for model apparmor I need to analyze what changed To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1824812/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1825155] Re: lxc-start crashed with SIGSEGV in cgfsng_payload_create()
** Changed in: lxc (Ubuntu) Status: Confirmed => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1825155 Title: lxc-start crashed with SIGSEGV in cgfsng_payload_create() Status in lxc package in Ubuntu: Fix Committed Bug description: https://errors.ubuntu.com/problem/8e0f1b9682f08bab5dedd4100e42f59cfe2cc004 Steps to reproduce: 1) Prepare creating unprivileged containers as described here: https://linuxcontainers.org/lxc/getting-started/ 2) Create a new container (e.g. "lxc-create -n container -t download" and then "debian", "stretch" and "amd64"). 3) Start the created container in foreground using "lxc-start -n container -F" ProblemType: Crash DistroRelease: Ubuntu 18.10 Package: lxc-utils 3.0.3-0ubuntu1~18.10.1 ProcVersionSignature: Ubuntu 4.18.0-17.18-generic 4.18.20 Uname: Linux 4.18.0-17-generic x86_64 ApportVersion: 2.20.10-0ubuntu13.2 Architecture: amd64 CrashCounter: 1 CurrentDesktop: KDE Date: Wed Apr 17 12:03:37 2019 ExecutablePath: /usr/bin/lxc-start InstallationDate: Installed on 2019-04-15 (1 days ago) InstallationMedia: Kubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.2) ProcCmdline: BOOT_IMAGE=/vmlinuz-4.18.0-17-generic root=UUID=0739f905-33c9-4de3-9ba9-a63b8d69e5e5 ro quiet splash vt.handoff=1 SegvAnalysis: Segfault happened at: 0x7f6292c5dbbd:mov(%rax),%r15 PC (0x7f6292c5dbbd) ok source "(%rax)" (0x) not located in a known VMA region (needed readable region)! destination "%r15" ok SegvReason: reading NULL VMA Signal: 11 SourcePackage: lxc StacktraceTop: ?? () from /usr/lib/x86_64-linux-gnu/liblxc.so.1 __lxc_start () from /usr/lib/x86_64-linux-gnu/liblxc.so.1 lxc_start () from /usr/lib/x86_64-linux-gnu/liblxc.so.1 ?? () from /usr/lib/x86_64-linux-gnu/liblxc.so.1 ?? () from /usr/lib/x86_64-linux-gnu/liblxc.so.1 Title: lxc-start crashed with SIGSEGV in __lxc_start() UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo defaults.conf: lxc.net.0.type = veth lxc.net.0.link = lxcbr0 lxc.net.0.flags = up lxc.net.0.hwaddr = 00:16:3e:xx:xx:xx mtime.conffile..etc.apport.crashdb.conf: 2019-04-17T11:58:15.556166 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1825155/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1884635] Re: lxc 1:4.0.2-0ubuntu1 ADT test failure with linux-5.8 5.8.0-1.2
This is a regression in overlayfs for the 5.8 kernel. The same test works fine on an earlier kernel with the same lxc version. ** Changed in: lxc (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1884635 Title: lxc 1:4.0.2-0ubuntu1 ADT test failure with linux-5.8 5.8.0-1.2 Status in lxc package in Ubuntu: Invalid Bug description: Testing failed on: amd64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy-canonical-kernel-team-bootstrap/groovy/amd64/l/lxc/20200619_210334_814e1@/log.gz arm64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy-canonical-kernel-team-bootstrap/groovy/arm64/l/lxc/20200619_213805_39c53@/log.gz ppc64el: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy-canonical-kernel-team-bootstrap/groovy/ppc64el/l/lxc/20200619_210431_b275f@/log.gz s390x: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy-canonical-kernel-team-bootstrap/groovy/s390x/l/lxc/20200619_210417_54a16@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1884635/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1884635] Re: lxc 1:4.0.2-0ubuntu1 ADT test failure with linux-5.8 5.8.0-1.2
** Also affects: linux (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1884635 Title: lxc 1:4.0.2-0ubuntu1 ADT test failure with linux-5.8 5.8.0-1.2 Status in linux package in Ubuntu: Incomplete Status in lxc package in Ubuntu: Invalid Bug description: Testing failed on: amd64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy-canonical-kernel-team-bootstrap/groovy/amd64/l/lxc/20200619_210334_814e1@/log.gz arm64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy-canonical-kernel-team-bootstrap/groovy/arm64/l/lxc/20200619_213805_39c53@/log.gz ppc64el: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy-canonical-kernel-team-bootstrap/groovy/ppc64el/l/lxc/20200619_210431_b275f@/log.gz s390x: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy-canonical-kernel-team-bootstrap/groovy/s390x/l/lxc/20200619_210417_54a16@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1884635/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1884635] Re: lxc 1:4.0.2-0ubuntu1 ADT test failure with linux-5.8 5.8.0-1.2
** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed ** Changed in: linux (Ubuntu) Status: Confirmed => In Progress ** Changed in: linux (Ubuntu) Assignee: (unassigned) => Christian Brauner (cbrauner) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1884635 Title: lxc 1:4.0.2-0ubuntu1 ADT test failure with linux-5.8 5.8.0-1.2 Status in linux package in Ubuntu: In Progress Status in lxc package in Ubuntu: Invalid Bug description: Testing failed on: amd64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy-canonical-kernel-team-bootstrap/groovy/amd64/l/lxc/20200619_210334_814e1@/log.gz arm64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy-canonical-kernel-team-bootstrap/groovy/arm64/l/lxc/20200619_213805_39c53@/log.gz ppc64el: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy-canonical-kernel-team-bootstrap/groovy/ppc64el/l/lxc/20200619_210431_b275f@/log.gz s390x: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy-canonical-kernel-team-bootstrap/groovy/s390x/l/lxc/20200619_210417_54a16@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1884635/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1886790] Re: lxc 3.0.3-0ubuntu1~18.04.1 ADT test failure with 5.4 kernels in Bionic
This is a bug we fixed in our stable-3.0 branch and is fixed in the Ubuntu lxc 3.0.4 packages. See https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1848587 and specifically this commit: commit 11fc6882f7bfd40fbcda6a3a7f7c1bca50df3f2b Author: Christian Brauner Date: Mon Nov 18 15:08:22 2019 +0100 tests: use /dev/loop-control instead of /dev/network_latency BugLink: https://bugs.launchpad.net/bugs/1848587 The latter device has been removed apparently. Bionic didn't get the 3.0.4 upgrade? That seems odd. ** Changed in: lxc (Ubuntu) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1886790 Title: lxc 3.0.3-0ubuntu1~18.04.1 ADT test failure with 5.4 kernels in Bionic Status in lxc package in Ubuntu: Fix Released Status in lxc source package in Bionic: Confirmed Bug description: Testing failed on: amd64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/l/lxc/20200706_183234_ca65f@/log.gz arm64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/arm64/l/lxc/20200706_172136_71b68@/log.gz ppc64el: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/ppc64el/l/lxc/20200706_191938_cedac@/log.gz s390x: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/s390x/l/lxc/20200706_163359_98d4d@/log.gz The failing test seems to be: FAIL: lxc-tests: lxc-test-device-add-remove (0s) --- Adding /dev/network_latency to the container (device_add_remove_test) failed... --- This is a regression from the 4.15/5.3 to 5.4 kernels in Bionic. Note that this testcase is successful on Focal with the same kernel version. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1886790/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1888705] Re: lxc ftbfs against libselinux 3.1
https://github.com/lxc/lxc/pull/3498 ** Changed in: lxc (Ubuntu) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1888705 Title: lxc ftbfs against libselinux 3.1 Status in lxc package in Ubuntu: In Progress Bug description: lxc fails to build from source against libselinux 3.1 in groovy- proposed, as seen in the autopkgtests which do a rebuild as part of the test: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../src -fPIC -DPIC -DLXCROOTFSMOUNT=\"/usr/lib/x86_64-linux-gnu/lxc\" -DLXCPATH=\"/var/lib/lxc\" -DLXC_GLOBAL_CONF=\"/etc/lxc/lxc.conf\" -DLXCINITDIR=\"/usr/lib/x86_64-linux-gnu\" -DLIBEXECDIR=\"/usr/lib/x86_64-linux-gnu\" -DLXCTEMPLATEDIR=\"/usr/share/lxc/templates\" -DLXCTEMPLATECONFIG=\"/usr/share/lxc/config\" -DLOGPATH=\"/var/log/lxc\" -DLXC_DEFAULT_CONFIG=\"/etc/lxc/default.conf\" -DLXC_USERNIC_DB=\"/run/lxc/nics\" -DLXC_USERNIC_CONF=\"/etc/lxc/lxc-usernet\" -DDEFAULT_CGROUP_PATTERN=\"\" -DRUNTIME_PATH=\"/run\" -DSBINDIR=\"/usr/sbin\" -DAPPARMOR_CACHE_DIR=\"/var/cache/lxc/apparmor\" -I ../../src -I ../../src/lxc -I ../../src/lxc/storage -I ../../src/lxc/cgroups -DHAVE_APPARMOR -DHAVE_SECCOMP -DHAVE_SELINUX -pthread -g -O2 -fdiagnostics-color -Wimplicit-fallthrough=5 -Wcast-align -fno-strict-aliasing -fstack-clash-protection -fstack-protector-strong --param=ssp-buffer-size=4 -g -Werror=implicit-function-declaration -Wlogical-op -Wmissing-include-dirs -Winit-self -Wunused-but-set-variable -Wfloat-equal -Wsuggest-attribute=noreturn -Werror=return-type -Werror=incompatible-pointer-types -Wformat=2 -Wshadow -Wendif-labels -Werror=overflow -fdiagnostics-show-option -Werror=shift-count-overflow -Werror=shift-overflow=2 -Wdate-time -Wnested-externs -fasynchronous-unwind-tables -pipe -fexceptions -Wvla -std=gnu11 -Werror -MT lsm/liblxc_la-selinux.lo -MD -MP -MF lsm/.deps/liblxc_la-selinux.Tpo -c lsm/selinux.c -fPIC -DPIC -o lsm/.libs/liblxc_la-selinux.o lsm/selinux.c: In function ‘selinux_process_label_get’: lsm/selinux.c:35:2: error: ‘security_context_t’ is deprecated [-Werror=deprecated-declarations] 35 | security_context_t ctx; | ^~ cc1: all warnings being treated as errors Because this is a universe package, I intend to force libselinux into the release, overriding this test failure. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1888705/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1888705] Re: lxc ftbfs against libselinux 3.1
** Changed in: lxc (Ubuntu) Status: In Progress => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1888705 Title: lxc ftbfs against libselinux 3.1 Status in lxc package in Ubuntu: Fix Released Bug description: lxc fails to build from source against libselinux 3.1 in groovy- proposed, as seen in the autopkgtests which do a rebuild as part of the test: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../src -fPIC -DPIC -DLXCROOTFSMOUNT=\"/usr/lib/x86_64-linux-gnu/lxc\" -DLXCPATH=\"/var/lib/lxc\" -DLXC_GLOBAL_CONF=\"/etc/lxc/lxc.conf\" -DLXCINITDIR=\"/usr/lib/x86_64-linux-gnu\" -DLIBEXECDIR=\"/usr/lib/x86_64-linux-gnu\" -DLXCTEMPLATEDIR=\"/usr/share/lxc/templates\" -DLXCTEMPLATECONFIG=\"/usr/share/lxc/config\" -DLOGPATH=\"/var/log/lxc\" -DLXC_DEFAULT_CONFIG=\"/etc/lxc/default.conf\" -DLXC_USERNIC_DB=\"/run/lxc/nics\" -DLXC_USERNIC_CONF=\"/etc/lxc/lxc-usernet\" -DDEFAULT_CGROUP_PATTERN=\"\" -DRUNTIME_PATH=\"/run\" -DSBINDIR=\"/usr/sbin\" -DAPPARMOR_CACHE_DIR=\"/var/cache/lxc/apparmor\" -I ../../src -I ../../src/lxc -I ../../src/lxc/storage -I ../../src/lxc/cgroups -DHAVE_APPARMOR -DHAVE_SECCOMP -DHAVE_SELINUX -pthread -g -O2 -fdiagnostics-color -Wimplicit-fallthrough=5 -Wcast-align -fno-strict-aliasing -fstack-clash-protection -fstack-protector-strong --param=ssp-buffer-size=4 -g -Werror=implicit-function-declaration -Wlogical-op -Wmissing-include-dirs -Winit-self -Wunused-but-set-variable -Wfloat-equal -Wsuggest-attribute=noreturn -Werror=return-type -Werror=incompatible-pointer-types -Wformat=2 -Wshadow -Wendif-labels -Werror=overflow -fdiagnostics-show-option -Werror=shift-count-overflow -Werror=shift-overflow=2 -Wdate-time -Wnested-externs -fasynchronous-unwind-tables -pipe -fexceptions -Wvla -std=gnu11 -Werror -MT lsm/liblxc_la-selinux.lo -MD -MP -MF lsm/.deps/liblxc_la-selinux.Tpo -c lsm/selinux.c -fPIC -DPIC -o lsm/.libs/liblxc_la-selinux.o lsm/selinux.c: In function ‘selinux_process_label_get’: lsm/selinux.c:35:2: error: ‘security_context_t’ is deprecated [-Werror=deprecated-declarations] 35 | security_context_t ctx; | ^~ cc1: all warnings being treated as errors Because this is a universe package, I intend to force libselinux into the release, overriding this test failure. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1888705/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1869661] Re: lxc 3.23 (?) breaks nested lxd with snaps
I think that's already fixed in the edge snap but we haven't yet rolled that out to stable. Can you test with edge? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1869661 Title: lxc 3.23 (?) breaks nested lxd with snaps Status in lxc package in Ubuntu: New Bug description: It looks like the latest release of lxd broke our snapd lxd test. The failure looks like it's lxd itself that can no longer run a nested lxd. The full log is available on e.g. https://api.travis-ci.org/v3/job/668138958/log.txt, search for """ Starting my-inner-ubuntu + MATCH from-the-INSIDE-inside + lxd.lxc exec my-nesting-ubuntu -- lxd.lxc exec my-inner-ubuntu -- echo from-the-INSIDE-inside Error: EOF grep error: pattern not found, got: """ The relevant part of the test is: https://github.com/snapcore/snapd/blob/master/tests/main/lxd/task.yaml#L153 I.e. this test creates an lxd container and sets up lxd inside this container. Happy to help with debugging (if needed), it really easy to reproduce with the above spread script. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1869661/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1857046] Re: lxc 3.0.4-0ubuntu2 ADT test failure with linux 5.5.0-2.3
No, but might have been an allocation error which we fixed in the meantime. The error can only come from: ENOMEM The kernel could not allocate a free page to copy filenames or data into. That's the only reason mount() can fail with ENOMEM from just glancing at the manpage. I'll take another close look at the codepath now, to make sure that there's not an obvious bug in there but otherwise I'd close and see if this happens again. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1857046 Title: lxc 3.0.4-0ubuntu2 ADT test failure with linux 5.5.0-2.3 Status in lxc package in Ubuntu: New Bug description: Testing failed on: amd64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal-canonical-kernel-team-bootstrap/focal/amd64/l/lxc/20191218_145013_76e0c@/log.gz arm64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal-canonical-kernel-team-bootstrap/focal/arm64/l/lxc/20191218_165648_a3f34@/log.gz ppc64el: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal-canonical-kernel-team-bootstrap/focal/ppc64el/l/lxc/20191218_151902_0998c@/log.gz s390x: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal-canonical-kernel-team-bootstrap/focal/s390x/l/lxc/20191218_152251_9101b@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1857046/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1645037] Re: apparmor_parser hangs indefinitely when called by multiple threads
This does not seem to be reproducible on a 4.4.0-45 kernel without
AppArmor stacking support.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1645037
Title:
apparmor_parser hangs indefinitely when called by multiple threads
Status in apparmor package in Ubuntu:
Triaged
Status in linux package in Ubuntu:
Triaged
Status in linux source package in Xenial:
Triaged
Status in linux source package in Yakkety:
Triaged
Status in linux source package in Zesty:
Triaged
Bug description:
This bug surfaced when starting ~50 LXC container with LXD in parallel
multiple times:
# Create the containers
for c in c foo{1..50}; do lxc launch images:ubuntu/xenial $c; done
# Exectute this loop multiple times until you observe errors.
for c in c foo{1..50}; do lxc restart $c & done
After this you can
ps aux | grep apparmor
and you should see output similar to:
root 19774 0.0 0.0 12524 1116 pts/1S+ 20:14 0:00
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache
/var/lib/lxd/security/apparmor/profiles/lxd-foo30
root 19775 0.0 0.0 12524 1208 pts/1S+ 20:14 0:00
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache
/var/lib/lxd/security/apparmor/profiles/lxd-foo26
root 19776 0.0 0.0 13592 3224 pts/1D+ 20:14 0:00
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache
/var/lib/lxd/security/apparmor/profiles/lxd-foo30
root 19778 0.0 0.0 13592 3384 pts/1D+ 20:14 0:00
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache
/var/lib/lxd/security/apparmor/profiles/lxd-foo26
root 19780 0.0 0.0 12524 1208 pts/1S+ 20:14 0:00
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache
/var/lib/lxd/security/apparmor/profiles/lxd-foo43
root 19782 0.0 0.0 12524 1208 pts/1S+ 20:14 0:00
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache
/var/lib/lxd/security/apparmor/profiles/lxd-foo34
root 19783 0.0 0.0 13592 3388 pts/1D+ 20:14 0:00
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache
/var/lib/lxd/security/apparmor/profiles/lxd-foo43
root 19784 0.0 0.0 13592 3252 pts/1D+ 20:14 0:00
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache
/var/lib/lxd/security/apparmor/profiles/lxd-foo34
root 19794 0.0 0.0 12524 1208 pts/1S+ 20:14 0:00
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache
/var/lib/lxd/security/apparmor/profiles/lxd-foo25
root 19795 0.0 0.0 13592 3256 pts/1D+ 20:14 0:00
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache
/var/lib/lxd/security/apparmor/profiles/lxd-foo25
apparmor_parser remains stuck even after all LXC/LXD commands have
exited.
dmesg output yields lines like:
[41902.815174] audit: type=1400 audit(1480191089.678:43):
apparmor="STATUS" operation="profile_load" profile="unconfined" name
="lxd-foo30_" pid=12545 comm="apparmor_parser"
and cat /proc/12545/stack shows:
[] aa_remove_profiles+0x88/0x270
21:19 brauner [] profile_remove+0x144/0x2e0
21:19 brauner [] __vfs_write+0x18/0x40
21:19 brauner [] vfs_write+0xb8/0x1b0
21:19 brauner [] SyS_write+0x55/0xc0
21:19 brauner [] entry_SYSCALL_64_fastpath+0x1e/0xa8
21:19 brauner [] 0x
This looks like a potential kernel bug.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1645037/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1646462] Re: lxc container download error (possibly HSTS related)
lxc-create does not handle any web requests so this cannot be the cause. Upgrading this to a secure connection is also perfectly fine. Is this reliably reproducible still or was this maybe just a temporary server problem? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1646462 Title: lxc container download error (possibly HSTS related) Status in lxc package in Ubuntu: New Bug description: LXC cannot download image, seems like a server error: ~# lxc-create -t download -n test Setting up the GPG keyring Downloading the image index ERROR: Failed to download http://images.linuxcontainers.org//meta/1.0/index-user lxc-create: lxccontainer.c: create_run_template: 1290 container creation template for test failed lxc-create: tools/lxc_create.c: main: 318 Error creating container test Trying to download the file with wget gets the file OK with minor complaints: ~# wget -O /dev/null 'http://images.linuxcontainers.org//meta/1.0/index-user' URL transformed to HTTPS due to an HSTS policy --2016-12-01 12:36:58-- https://images.linuxcontainers.org//meta/1.0/index-user Resolving images.linuxcontainers.org (images.linuxcontainers.org)... 91.189.88.37, 91.189.91.21 Connecting to images.linuxcontainers.org (images.linuxcontainers.org)|91.189.88.37|:443... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: https://uk.images.linuxcontainers.org/meta/1.0/index-user [following] --2016-12-01 12:36:58-- https://uk.images.linuxcontainers.org/meta/1.0/index-user Resolving uk.images.linuxcontainers.org (uk.images.linuxcontainers.org)... 91.189.88.37 Connecting to uk.images.linuxcontainers.org (uk.images.linuxcontainers.org)|91.189.88.37|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 9102 (8.9K) Saving to: ‘/dev/null’ Seems like some SSL problem in the lxc-create binary, specifically the HSTS issue mentioned by wget. Maybe a newly introduced HSTS policy breaks the package? ProblemType: Bug DistroRelease: Ubuntu 16.10 Package: lxc 2.0.5-0ubuntu1.2 ProcVersionSignature: Ubuntu 4.8.0-28.30-generic 4.8.6 Uname: Linux 4.8.0-28-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.3-0ubuntu8 Architecture: amd64 Date: Thu Dec 1 12:28:28 2016 InstallationDate: Installed on 2016-10-14 (47 days ago) InstallationMedia: Ubuntu-Server 16.10 "Yakkety Yak" - Release amd64 (20161012.1) PackageArchitecture: all SourcePackage: lxc UpgradeStatus: No upgrade log present (probably fresh install) dnsmasq.conf: dhcp-host=vold,10.0.3.10 dhcp-host=sftp,10.0.3.11 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1646462/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
Re: [Touch-packages] [Bug 1645037] Re: apparmor_parser hangs indefinitely when called by multiple threads
On Sat, Dec 03, 2016 at 12:58:54PM -, John Johansen wrote:
> How reliable/repeatable is this for you?
>
> I have been hammering a machine for multiple days and not been able to
> trip this once.
>
> I have been using the 4.8 ubuntu kernel the ubuntu-lxc/daily and the
> ubuntu-lxc/stable ppas. Any more info you can provide?
I could reproduce it quite reliably. The trick is to have concurrent restarts
just in the loop I showed. I'll try to verify again in the next few days.
Did you observe any hanging lxc restart commands or multiple hanging LXD
processes?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1645037
Title:
apparmor_parser hangs indefinitely when called by multiple threads
Status in apparmor package in Ubuntu:
Triaged
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Xenial:
In Progress
Status in linux source package in Yakkety:
In Progress
Status in linux source package in Zesty:
In Progress
Bug description:
This bug surfaced when starting ~50 LXC container with LXD in parallel
multiple times:
# Create the containers
for c in c foo{1..50}; do lxc launch images:ubuntu/xenial $c; done
# Exectute this loop multiple times until you observe errors.
for c in c foo{1..50}; do lxc restart $c & done
After this you can
ps aux | grep apparmor
and you should see output similar to:
root 19774 0.0 0.0 12524 1116 pts/1S+ 20:14 0:00
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache
/var/lib/lxd/security/apparmor/profiles/lxd-foo30
root 19775 0.0 0.0 12524 1208 pts/1S+ 20:14 0:00
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache
/var/lib/lxd/security/apparmor/profiles/lxd-foo26
root 19776 0.0 0.0 13592 3224 pts/1D+ 20:14 0:00
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache
/var/lib/lxd/security/apparmor/profiles/lxd-foo30
root 19778 0.0 0.0 13592 3384 pts/1D+ 20:14 0:00
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache
/var/lib/lxd/security/apparmor/profiles/lxd-foo26
root 19780 0.0 0.0 12524 1208 pts/1S+ 20:14 0:00
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache
/var/lib/lxd/security/apparmor/profiles/lxd-foo43
root 19782 0.0 0.0 12524 1208 pts/1S+ 20:14 0:00
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache
/var/lib/lxd/security/apparmor/profiles/lxd-foo34
root 19783 0.0 0.0 13592 3388 pts/1D+ 20:14 0:00
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache
/var/lib/lxd/security/apparmor/profiles/lxd-foo43
root 19784 0.0 0.0 13592 3252 pts/1D+ 20:14 0:00
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache
/var/lib/lxd/security/apparmor/profiles/lxd-foo34
root 19794 0.0 0.0 12524 1208 pts/1S+ 20:14 0:00
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache
/var/lib/lxd/security/apparmor/profiles/lxd-foo25
root 19795 0.0 0.0 13592 3256 pts/1D+ 20:14 0:00
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache
/var/lib/lxd/security/apparmor/profiles/lxd-foo25
apparmor_parser remains stuck even after all LXC/LXD commands have
exited.
dmesg output yields lines like:
[41902.815174] audit: type=1400 audit(1480191089.678:43):
apparmor="STATUS" operation="profile_load" profile="unconfined" name
="lxd-foo30_" pid=12545 comm="apparmor_parser"
and cat /proc/12545/stack shows:
[] aa_remove_profiles+0x88/0x270
21:19 brauner [] profile_remove+0x144/0x2e0
21:19 brauner [] __vfs_write+0x18/0x40
21:19 brauner [] vfs_write+0xb8/0x1b0
21:19 brauner [] SyS_write+0x55/0xc0
21:19 brauner [] entry_SYSCALL_64_fastpath+0x1e/0xa8
21:19 brauner [] 0x
This looks like a potential kernel bug.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1645037/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
Re: [Touch-packages] [Bug 1645037] Re: apparmor_parser hangs indefinitely when called by multiple threads
On Thu, Dec 08, 2016 at 11:37:52AM -, John Johansen wrote:
> Christian,
>
> could you please try against my test kernel? It has fixed the issue with
> my local reproducer
Sure, I'm currently testing!
Thanks!
Christian
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1645037
Title:
apparmor_parser hangs indefinitely when called by multiple threads
Status in apparmor package in Ubuntu:
Triaged
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Xenial:
In Progress
Status in linux source package in Yakkety:
In Progress
Status in linux source package in Zesty:
In Progress
Bug description:
This bug surfaced when starting ~50 LXC container with LXD in parallel
multiple times:
# Create the containers
for c in c foo{1..50}; do lxc launch images:ubuntu/xenial $c; done
# Exectute this loop multiple times until you observe errors.
for c in c foo{1..50}; do lxc restart $c & done
After this you can
ps aux | grep apparmor
and you should see output similar to:
root 19774 0.0 0.0 12524 1116 pts/1S+ 20:14 0:00
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache
/var/lib/lxd/security/apparmor/profiles/lxd-foo30
root 19775 0.0 0.0 12524 1208 pts/1S+ 20:14 0:00
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache
/var/lib/lxd/security/apparmor/profiles/lxd-foo26
root 19776 0.0 0.0 13592 3224 pts/1D+ 20:14 0:00
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache
/var/lib/lxd/security/apparmor/profiles/lxd-foo30
root 19778 0.0 0.0 13592 3384 pts/1D+ 20:14 0:00
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache
/var/lib/lxd/security/apparmor/profiles/lxd-foo26
root 19780 0.0 0.0 12524 1208 pts/1S+ 20:14 0:00
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache
/var/lib/lxd/security/apparmor/profiles/lxd-foo43
root 19782 0.0 0.0 12524 1208 pts/1S+ 20:14 0:00
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache
/var/lib/lxd/security/apparmor/profiles/lxd-foo34
root 19783 0.0 0.0 13592 3388 pts/1D+ 20:14 0:00
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache
/var/lib/lxd/security/apparmor/profiles/lxd-foo43
root 19784 0.0 0.0 13592 3252 pts/1D+ 20:14 0:00
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache
/var/lib/lxd/security/apparmor/profiles/lxd-foo34
root 19794 0.0 0.0 12524 1208 pts/1S+ 20:14 0:00
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache
/var/lib/lxd/security/apparmor/profiles/lxd-foo25
root 19795 0.0 0.0 13592 3256 pts/1D+ 20:14 0:00
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache
/var/lib/lxd/security/apparmor/profiles/lxd-foo25
apparmor_parser remains stuck even after all LXC/LXD commands have
exited.
dmesg output yields lines like:
[41902.815174] audit: type=1400 audit(1480191089.678:43):
apparmor="STATUS" operation="profile_load" profile="unconfined" name
="lxd-foo30_" pid=12545 comm="apparmor_parser"
and cat /proc/12545/stack shows:
[] aa_remove_profiles+0x88/0x270
21:19 brauner [] profile_remove+0x144/0x2e0
21:19 brauner [] __vfs_write+0x18/0x40
21:19 brauner [] vfs_write+0xb8/0x1b0
21:19 brauner [] SyS_write+0x55/0xc0
21:19 brauner [] entry_SYSCALL_64_fastpath+0x1e/0xa8
21:19 brauner [] 0x
This looks like a potential kernel bug.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1645037/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
