[Touch-packages] [Bug 2039873] Re: liblxc-dev was built with LXC_DEVEL=1 in Ubuntu 22.04 and later releases
My two cents here are that we should: - Rapidly fix the LXC_DEVEL situation across all supported Ubuntu releases. - Separately prepare a new package for noble which performs the Debian merge and introduces the needed transitional packages to get users from the current Ubuntu-specific naming over to the Debian names, those can then go away in noble+1 at which point LXC should be automatically syncable from Debian. -- 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/2039873 Title: liblxc-dev was built with LXC_DEVEL=1 in Ubuntu 22.04 and later releases Status in lxc package in Ubuntu: Confirmed Bug description: [ Impact ] LXC 5.0.0 was built with LXC_DEVEL=1 set for Jammy. But for release build we should have LXC_DEVEL=0. LXC_DEVEL is a variable that appears in the /usr/include/lxc/version.h and then can be (and actually it is) used by other projects to detect if liblxc-dev is a development build or stable. Having LXC_DEVEL=1 makes problems for the users who want to build projects those are depend on liblxc from source (for example, LXD, go-lxc: https://github.com/canonical/lxd/pull/12420). Q: Why it was not a problem for so long? A: Because LXC API was stable for a long time, but recently we have extended liblxc API (https://github.com/lxc/lxc/pull/4260) and dependant package go-lxc was updated too (https://github.com/lxc/go-lxc/pull/166). This change was developed properly to be backward compatible with the old versions of liblxc. But, there is a problem. If LXC_DEVEL=1 then the macro check VERSION_AT_LEAST (https://github.com/lxc/go-lxc/blob/ccae595aa49e779f7ecc9250329967aa546acd31/lxc-binding.h#L7) is disabled. That's why we should *not* have LXC_DEVEL=1 for *any* release build of LXC. [ Test Plan ] Install liblxc-dev package and check /usr/include/lxc/version.h file LXC_DEVEL should be 0 [ Where problems could occur ] Theoretically, build of a software which depends on liblxc-dev may start to fail if it assumes that LXC_DEVEL is 1. [ Other Info ] - To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/2039873/+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 2039873] Re: liblxc-dev was built with LXC_DEVEL=1 in Ubuntu Jammy/Kinetic
This was definitely a mistake made when preparing the original LXC 5.0 snapshot for upload in Ubuntu. LXC_DEVEL=1 should only ever be set when dealing with current snapshots of the upstream codebase. Shipping an older snapshot with LXC_DEVEL=1 set will cause any tool that consumes liblxc and which needs to do feature detection to incorrectly expect that the liblxc version present on the system has that feature supported, at best causing build failures, at worst causing runtime crashes. I can certainly see how this mess was created with 5.0.0 as we had to push a pre-release snapshot to the archive and keep the build on autotools due to issues with meson at the time (resolved in 5.0.1). Using an upstream snapshot rather than a release tarball, caused the inclusion of the problematic LXC_DEVEL=1. What's quite puzzling is how we ended up with the 5.0.1 upload also having that LXC_DEVEL=1 bit be applied as a patch on top of it... Looking at the changelog, it appears that Serge simply pulled all changes following 5.0.1 from git, which he likely did mistakenly looking at the master branch rather than the stable-5.0 branch which wouldn't have had that particular change. My opinion is that we really need to: - Drop the LXC_DEVEL=1 cherry-pick from noble, ideally merge with Debian to pull in the more current 5.0.3 too. - Drop the LXC_DEVEL=1 cherry-pick from both mantic and lunar - Add a batch to drop LXC_DEVEL=1 from the git snapshot of 5.0 that's in jammy Additionally, I'd very strongly recommend that an autopkgtest test is added to validate that no liblxc package ever ship with LXC_DEVEL=1 ever 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/2039873 Title: liblxc-dev was built with LXC_DEVEL=1 in Ubuntu Jammy/Kinetic Status in lxc package in Ubuntu: Confirmed Bug description: [ Impact ] LXC 5.0.0 was built with LXC_DEVEL=1 set for Jammy. But for release build we should have LXC_DEVEL=0. LXC_DEVEL is a variable that appears in the /usr/include/lxc/version.h and then can be (and actually it is) used by other projects to detect if liblxc-dev is a development build or stable. Having LXC_DEVEL=1 makes problems for the users who want to build projects those are depend on liblxc from source (for example, LXD, go-lxc: https://github.com/canonical/lxd/pull/12420). Q: Why it was not a problem for so long? A: Because LXC API was stable for a long time, but recently we have extended liblxc API (https://github.com/lxc/lxc/pull/4260) and dependant package go-lxc was updated too (https://github.com/lxc/go-lxc/pull/166). This change was developed properly to be backward compatible with the old versions of liblxc. But, there is a problem. If LXC_DEVEL=1 then the macro check VERSION_AT_LEAST (https://github.com/lxc/go-lxc/blob/ccae595aa49e779f7ecc9250329967aa546acd31/lxc-binding.h#L7) is disabled. That's why we should *not* have LXC_DEVEL=1 for *any* release build of LXC. [ Test Plan ] Install liblxc-dev package and check /usr/include/lxc/version.h file LXC_DEVEL should be 0 [ Where problems could occur ] Theoretically, build of a software which depends on liblxc-dev may start to fail if it assumes that LXC_DEVEL is 1. [ Other Info ] - To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/2039873/+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 2009738] Re: no lxc manpage
We don't track snap bugs on Launchpad, nor is this something we can fix as it's indeed a missing feature of snaps. If snapd ever grows support for landing manpages on the system (similar to what it does with bash completion profiles), we'll be able to use our manpage generate showed above to populate those man pages. ** Changed in: lxc (Ubuntu) Status: New => Won't Fix -- 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/2009738 Title: no lxc manpage Status in lxc package in Ubuntu: Won't Fix Bug description: Hello, I don't have an lxc manpage on my focal system: $ man lxc No manual entry for lxc $ dpkg -l lxd | grep lxd ; snap info lxd | grep installed un lxd (no description available) installed: 5.11-ad0b61e (24483) 149MB - It looks a bit like none are packaged: $ find /snap/lxd -name '*.1.gz' -o -name '*.7.gz' -o -name '*.8.gz' $ While I appreciate the online --help output, I also like having longer-form documentation available on a system without needing to use a web browser. Thanks ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: lxc (not installed) ProcVersionSignature: Ubuntu 5.4.0-139.156-generic 5.4.224 Uname: Linux 5.4.0-139-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu27.25 Architecture: amd64 CasperMD5CheckResult: skip Date: Wed Mar 8 18:21:08 2023 SourcePackage: lxc UpgradeStatus: Upgraded to focal on 2020-01-24 (1138 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/2009738/+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 1987625] Re: lxc: FTBFS against glibc 2.36.0
We've fixed those upstream already and will be in the next upstream point release. -- 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/1987625 Title: lxc: FTBFS against glibc 2.36.0 Status in lxc package in Ubuntu: Confirmed Bug description: Hi, lxc currently fails to build against glibc 2.36, which also affects its autopkgtests. Here's an excerpt of the failed build logs containing the first error detected: gcc -DHAVE_CONFIG_H -I. -I../../src -Wdate-time -D_FORTIFY_SOURCE=2 -fPIE -Wvla -std=gnu11 -fms-extensions -fdiagnostics-color -Wimplicit-fallthrough=5 -Wcast-align -Wstrict-prototypes -fno-strict-aliasing -fstack-clash-protection -fstack-protector-strong --param=ssp-buffer-size=4 -g -fcf-protection -Werror=implicit-function-declaration -Wlogical-op -Wmissing-include-dirs -Wold-style-definition -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 -Warray-bounds -Wrestrict -Wreturn-local-addr -Wstringop-overflow -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/include -I ../../src/lxc -I ../../src/lxc/storage -I ../../src/lxc/cgroups -DHAVE_APPARMOR -DHAVE_SECCOMP -DHAVE_SELINUX -g -O2 -ffile-prefix-map=/<>=. -flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -Wvla -std=gnu11 -fms-extensions -Werror -c -o conf.o conf.c conf.c: In function ‘__lxc_idmapped_mounts_child’: conf.c:2993:37: error: passing argument 4 of ‘mount_setattr’ from incompatible pointer type [-Werror=incompatible-pointer-types] 2993 | , | ^ | | | struct lxc_mount_attr * In file included from conf.c:22: /usr/include/x86_64-linux-gnu/sys/mount.h:317:46: note: expected ‘struct mount_attr *’ but argument is of type ‘struct lxc_mount_attr *’ 317 | struct mount_attr *__uattr, size_t __usize) | ~~~^~~ conf.c:3016:41: error: passing argument 4 of ‘mount_setattr’ from incompatible pointer type [-Werror=incompatible-pointer-types] 3016 | , | ^ | | | struct lxc_mount_attr * /usr/include/x86_64-linux-gnu/sys/mount.h:317:46: note: expected ‘struct mount_attr *’ but argument is of type ‘struct lxc_mount_attr *’ 317 | struct mount_attr *__uattr, size_t __usize) | ~~~^~~ conf.c: In function ‘lxc_idmapped_mounts_parent’: conf.c:4130:37: error: passing argument 4 of ‘mount_setattr’ from incompatible pointer type [-Werror=incompatible-pointer-types] 4130 | , sizeof(attr)); | ^ | | | struct lxc_mount_attr * /usr/include/x86_64-linux-gnu/sys/mount.h:317:46: note: expected ‘struct mount_attr *’ but argument is of type ‘struct lxc_mount_attr *’ 317 | struct mount_attr *__uattr, size_t __usize) | ~~~^~~ I believe the following upstream PR should fix the issue: https://github.com/lxc/lxc/pull/4181 I'll be testing a patched version shortly and will post a debdiff if it pans out. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1987625/+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 1959993] Re: SRU of LXC 4.0.12 to focal (upstream bugfix release)
Have confirmed the packages to be functional on both focal and impish. Tried installation, upgrade and basic container creation, deletion and normal operations. ** Tags removed: verification-needed-focal verification-needed-impish ** Tags added: verification-done-focal verification-done-impish -- 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/1959993 Title: SRU of LXC 4.0.12 to focal (upstream bugfix release) Status in lxc package in Ubuntu: In Progress Status in lxc source package in Focal: Fix Committed Status in lxc source package in Impish: Fix Committed Bug description: LXC released 4.0.12 as a bugfix release and is now in jammy. We'd like to line things up in focal. [Impact] The proposed SRU will bump from 4.0.6 all the way to 4.0.12, lining it up with what's currently in jammy. We've been skipping a few of the bugfix releases in focal so far, mostly catching up when we're starting to see problems with the older version. In this case, we've seen a number of issues when running with the HWE kernels as well as autopkgtest issues on foreign architectures (arm64 and s390x), all those will go away with this bump as we've confirmed everything is clean in jammy. Changelog: * Cherry-pick upstream bugfixes (stable-4.0): - 0002-lxc-checkconfig-Fix-bashism.patch - 0003-doc-Fix-reverse-allowlist-denylist.patch * New upstream bugfix release (4.0.12): (https://discuss.linuxcontainers.org/t/lxc-4-0-12-has-been-released/13288) - Fixed CRIU restoration of containers with pre-created veth interfaces - Fixed issue with kernels lacking SMT support - Extended cgroup2 config options in lxc.mount.auto (cgroup2) - lxc-download now relies on HTTPS for validation (avoids GPG issues) * New upstream bugfix release (4.0.11): (https://discuss.linuxcontainers.org/t/lxc-4-0-11-has-been-released/12427) - Core scheduling support (lxc.sched.core) - riscv64 support in lxc.arch - Significantly improved bash completion profile - Greater use of the new VFS mount API (when supported by the kernel) - Fix containers with empty network namespaces - Handle kernels that lack TIOCGPTPEER - Improve CPU bitmask/id handling (handle skipped CPU numbers) - Reworked the tests to run offline * New upstream bugfix release (4.0.10): (https://discuss.linuxcontainers.org/t/lxc-4-0-10-has-been-released/11618) - Fix issues with less common architectures - Support for additional idmap mounts - nft support in lxc-net - Cleaner mount entries for sys:mixed - Switched GPG server to keyserver.ubuntu.com * New upstream bugfix release (4.0.9): (https://discuss.linuxcontainers.org/t/lxc-4-0-9-has-been-released/10999) - Fix incorrect personality setting when running 32bit containers on 64bit * New upstream bugfix release (4.0.8): - Fix CGroup attach against older running containers * New upstream bugfix release (4.0.7): - Testing improvements including fixes from oss-fuzz - Rework of the attach codepath - Cgroup handling rework * Bump to debhelper 12 (allows focal SRUs) * Bump standards to 4.6.0.1 * Add lintian overrides for incorrect bashism detection * Remove bash completion install logic (now done upstream) Just like Ubuntu itself, upstream releases long term support releases, e.g. 4.0, and then periodic point releases including all the accumulated bugfixes. Only the latest upstream release gets full support from the upstream developers, everyone else is expected to first update to it before receiving any kind of support. This should qualify under the minor/micro upstream bugfix release allowance of the SRU policy, letting us SRU this without paperwork for every single change included in this upstream release. [Test Plan] lxc has autopkgtests which will assert that the binaries built in -proposed are functional. [Where problems could occur] This is catching up a fair bit on recent kernel API changes, including cgroup1/cgroup2 support, handling of nftables, riscv64 and core scheduling which were all needed to properly handle the most recent HWE kernels especially as we're getting ready for Ubuntu 22.04's 5.15 to get pushed to focal. We've had all that code running on well over a million of LXD snap users for a few months now without seeing any issues (or more precisely, those issues we found have been all been resolved as of 4.0.12). However what LXD exercises isn't 100% of LXC and it's certainly possible that we missed a corner case in one of those changes. The good news is that this would most likely be triggered by a HWE kernel, so a viable workaround in many cases would be to temporarily go back to the original kernel (5.4) while the issue is
[Touch-packages] [Bug 1967620] [NEW] [FFe] LXC 5.0 LTS
Public bug reported: LXC 5.0 LTS will very soon be released. The upstream release has been held up due to an incomplete port to meson (and deprecation of autotools), it's otherwise been ready to go for a few months. As far as LXC releases go, it's a very light one. Comparing it to current 4.0.12, we have: - No liblxc API changes at all (no new symbols or changes to headers) - Addition of a few configuration keys: - lxc.cgroup.dir.monitor.pivot - lxc.cgroup.dir.monitor - lxc.cgroup.dir.container.inner - lxc.cgroup.dir.container - lxc.time.offset.boot - lxc.time.offset.monotonic - veth.n_rxqueues - veth.n_txqueues - veth.vlan.id - veth.vlan.tagged.id - Port to meson (replacing autotools) Diffstat: ``` stgraber@dakara:~/data/code/lxc/lxc (lxc/master)$ git diff lxc-4.0.12.. . | diffstat .gitignore |1 config/init/systemd/Makefile.am| 10 + config/init/systemd/lxc-net.service.in |1 configure.ac |5 doc/api-extensions.md |9 + doc/ja/lxc.container.conf.sgml.in | 129 - doc/lxc.container.conf.sgml.in | 98 lxc.spec.in|1 meson.build|4 src/lxc/api_extensions.h |3 src/lxc/cgroups/cgfsng.c | 93 +++ src/lxc/cmd/lxc-checkconfig.in |6 - src/lxc/cmd/lxc_monitord.c | 59 + src/lxc/cmd/lxc_user_nic.c |2 src/lxc/conf.c | 11 + src/lxc/confile.c | 664 +--- src/lxc/network.c | 18 ++- src/lxc/network.h |4 src/lxc/terminal.c |1 src/lxc/terminal.h |3 src/lxc/tools/lxc_autostart.c |8 + src/lxc/utils.c|3 src/tests/aa.c |2 src/tests/config_jump_table.c |2 src/tests/containertests.c |2 src/tests/get_item.c | 90 ++- src/tests/getkeys.c|2 src/tests/locktests.c |2 src/tests/lxc-test-utils.c | 16 +- src/tests/meson.build | 534 ++ src/tests/mount_injection.c|2 src/tests/parse_config_file.c | 17 ++ src/tests/reboot.c |2 src/tests/share_ns.c |4 src/tests/snapshot.c |2 35 files changed, 1676 insertions(+), 134 deletions(-) ``` LXC 4.0.12 which we released on Feb 1st has all the bugfixes and other non-feature changes from LXC 5.0, making this quite a small and generally safe delta. The new features can be roughly categorized as: - Improve flexibility in cgroup configuration (make naming of /sys/fs/cgroup directories configurable) - Add support for the time namespace (clock offset) - Add support for configuring (basic sysctl) the number of veth queues - Add support for bridge VLAN filtering on veth devices LXC 5.0 will be an upstream LTS with a support duration matching that of Ubuntu 22.04 or until June 2027. Jammy currently ships LXC 4.0.12 which is only supported until June 2025 and will not see new bugfix releases after LXC 5.0 comes out (only security). LXC is unseeded and in universe these days. The main goal of putting the new LTS in the release is to reduce the maintenance cost for the Ubuntu LTS and to satisfy some of Canonical's customers that are directly using those packages and would expect a consistent set of LTS releases. LXCFS 5.0 is already in jammy and LXD 5.0 has similarly been released, though that one ships exclusively as a snap. If we can get general agreement that getting this LXC release in Ubuntu 22.04 is fine, what I can do to fast track things a bit is upload a 5.0~git-hash version which still relies on autotools, get that do clear autopkgtest and CI and then follow that up with the final 5.0 with the meson port as soon as it's complete on our side (expecting about a week, just got two directories to port). As a reminder, this is all unseeded and in universe, so overall impact should be quite low. Full upstream diff (4.0.12 to 5.0): https://gist.github.com/5c76aefcc8643e37a3e1b81a7a37a6f9 ** Affects: lxc (Ubuntu) Importance: High Status: New ** 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/1967620 Title: [FFe] LXC 5.0 LTS Status in lxc package in Ubuntu: New Bug description:
[Touch-packages] [Bug 1959047] Re: systemd ignores RootDirectory option in .service units
Uploaded to the queue ** Changed in: lxd (Ubuntu Bionic) Status: Confirmed => 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/1959047 Title: systemd ignores RootDirectory option in .service units Status in lxd package in Ubuntu: Invalid Status in systemd package in Ubuntu: Confirmed Status in lxd source package in Bionic: In Progress Status in systemd source package in Bionic: Confirmed Status in systemd source package in Focal: Confirmed Status in systemd source package in Impish: Confirmed Bug description: [Impact] Ubuntu carries a patch on top of systemd [a] to silence namespace set up failures. This is meant as a workaround for a bug in the LXD version shipped in Ubuntu 18.04. Masking namespace set up failures creates a false sense of security for the user/admin. As mentioned in comment #1, systemd upstream explains that silencing this kind of error is dangerous and should be avoided. Backporting the LXD fix [b] to Ubuntu 18.04 would allow namespaces to work inside containers. This is the goal of this SRU. Ultimately, once LXD in Ubuntu 18.04 includes the fix [b], it would be possible to drop the Ubuntu-specific patch for systemd [a]. This is however *not an immediate concern for this SRU*. [Test Plan] 1) Create a 18.04 VM: $ lxc launch images:ubuntu/18.04 lp1959047 --vm $ sleep 30 # give it time to boot 2) Install and initialize LXD in it: $ lxc exec lp1959047 -- apt-get update $ lxc exec lp1959047 -- apt-get install -y lxd $ lxc exec lp1959047 -- lxd init --auto 3) Create a Jammy container and enable systemd debugging: $ lxc exec lp1959047 -- lxc init images:ubuntu/22.04 c1 $ lxc exec lp1959047 -- lxc config set c1 raw.lxc 'lxc.init.cmd = /sbin/init systemd.log_level=debug' $ lxc exec lp1959047 -- lxc start c1 4) Check if namespace set up failures are logged: $ lxc exec lp1959047 -- lxc exec c1 -- journalctl -b0 --grep 'Failed to set up namespace' Mar 24 23:29:19 c1 systemd[99]: systemd-udevd.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:19 c1 systemd[132]: systemd-networkd.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:19 c1 systemd[131]: systemd-logind.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:20 c1 systemd[136]: systemd-resolved.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:20 c1 systemd[128]: e2scrub_reap.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:23 c1 systemd[243]: systemd-hostnamed.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied If LXD in Ubuntu 18.04 has the patch, the "Failed to set up namespace" messages wouldn't be there. [Where problems could occur] The LXD fix changes the Apparmor profile used for containers. This essentially loosen the mount restrictions applied to containers. Weakening the Apparmor profile could make it easier for a process in the container to do damage that would have otherwise been blocked. On the other hand, this allows making use of namespaces/sandboxing inside the container. Upstream LXD has the fix since 2019 which make it less likely to run into problems with the backport. The backported fix was also tested manually to ensure LXD still behaved normally and that it avoided the namespace set up failures in Jammy containers. [a]: https://git.launchpad.net/ubuntu/+source/systemd/tree/debian/patches/debian/UBUNTU-Revert-namespace-be-more-careful-when-handling-namespacin.patch?h=ubuntu/jammy [b]: https://github.com/lxc/lxd/commit/a6b780703350faff8328f3d565f6bac7b6dcf59f [Initial bug description] The version of systemd (249.5-2ubuntu4) currently packaged for the Ubuntu development version (22.04 Jammy Jellyfish) totally ignores the RootDirectory= option in systemd service files. With RootDirectory, systemd should start the service after calling chroot() on the supplied directory. To test/reproduce, create a test service file with the following contents: # /etc/systemd/system/lsb-release.service [Unit] Description=LSB Release Information [Service] Type=simple RootDirectory=/var/chroot/trusty ExecStartPre=/bin/pwd ExecStart=/usr/bin/lsb_release -a You should have a chroot environment in the specified RootDirectory, even though you can still deduce if systemd attempted to chroot or not from the resulting error message. In my example, I installed an end-of-life Ubuntu 14.04 Trusty Tahr in the chroot environment. On systems NOT affected by the problem, I get the
[Touch-packages] [Bug 1959047] Re: systemd ignores RootDirectory option in .service units
Okay, that looks promising. Can you add the SRU sections to the description describing those testing steps? Then I can upload to the SRU queue referencing this bug. -- 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/1959047 Title: systemd ignores RootDirectory option in .service units Status in lxd package in Ubuntu: Invalid Status in systemd package in Ubuntu: Confirmed Status in lxd source package in Bionic: New Status in systemd source package in Bionic: New Status in systemd source package in Focal: New Status in systemd source package in Impish: New Bug description: The version of systemd (249.5-2ubuntu4) currently packaged for the Ubuntu development version (22.04 Jammy Jellyfish) totally ignores the RootDirectory= option in systemd service files. With RootDirectory, systemd should start the service after calling chroot() on the supplied directory. To test/reproduce, create a test service file with the following contents: # /etc/systemd/system/lsb-release.service [Unit] Description=LSB Release Information [Service] Type=simple RootDirectory=/var/chroot/trusty ExecStartPre=/bin/pwd ExecStart=/usr/bin/lsb_release -a You should have a chroot environment in the specified RootDirectory, even though you can still deduce if systemd attempted to chroot or not from the resulting error message. In my example, I installed an end-of-life Ubuntu 14.04 Trusty Tahr in the chroot environment. On systems NOT affected by the problem, I get the following result when I start this test service. This is what I'd expect. Jan 25 20:40:40 dolly systemd[1]: Starting LSB Release Information... Jan 25 20:40:40 dolly pwd[361]: / Jan 25 20:40:40 dolly systemd[1]: Started LSB Release Information. Jan 25 20:40:40 dolly lsb_release[362]: No LSB modules are available. Jan 25 20:40:40 dolly lsb_release[362]: Distributor ID:Ubuntu Jan 25 20:40:40 dolly lsb_release[362]: Description:Ubuntu 14.04 LTS Jan 25 20:40:40 dolly lsb_release[362]: Release:14.04 Jan 25 20:40:40 dolly lsb_release[362]: Codename:trusty Jan 25 20:40:40 dolly systemd[1]: lsb-release.service: Succeeded. On the problematic system, however, I get the following result. Jan 25 21:21:08 savelog systemd[1]: Starting LSB Release Information... Jan 25 21:21:08 savelog systemd[1]: Started LSB Release Information. Jan 25 21:21:08 savelog pwd[81114]: / Jan 25 21:21:08 savelog lsb_release[81115]: No LSB modules are available. Jan 25 21:21:08 savelog lsb_release[81115]: Distributor ID:Ubuntu Jan 25 21:21:08 savelog lsb_release[81115]: Description:Ubuntu Jammy Jellyfish (development branch) Jan 25 21:21:08 savelog lsb_release[81115]: Release:22.04 Jan 25 21:21:08 savelog lsb_release[81115]: Codename:jammy Jan 25 21:21:08 savelog systemd[1]: lsb-release.service: Deactivated successfully. It totally run the service on the host's root filesystem, it didn't care even the slightest that a RootDirectory is specified. Tested on the following releases / systemd versions: Ubuntu 18.04.6 Bionic Beaver – ISSUE NOT PRESENT systemd 237 +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid Ubuntu 20.04.3 Focal Fossa – ISSUE NOT PRESENT systemd 245 (245.4-4ubuntu3.15) +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid Ubuntu 21.10 Impish Indri – ISSUE NOT PRESENT systemd 248 (248.3-1ubuntu8.2) +PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS -OPENSSL +ACL +BLKID +CURL +ELFUTILS -FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP -LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified Ubuntu 22.04 Jammy Jellyfish (development branch) – ISSUE PRESENT systemd 249 (249.5-2ubuntu4) +PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS -OPENSSL +ACL +BLKID +CURL +ELFUTILS -FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP -LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified Note that the problem is produced under an LXC container; since systemd detects virtualization, it might change how it behaves. It's either a bug or an intentional change I don't understand yet (i.e. the RootDirectory option has deprecated and is about to be replaced with something else, or there are additional conditions to be met before RootDirectory is considered), but I think in the latter case I should at least get a warning that there is a change in
[Touch-packages] [Bug 1959047] Re: systemd ignores RootDirectory option in .service units
Uploading a LXD SRU to bionic with the one commit cherry-picked shouldn't be too hard. But we'd need someone to sort out the SRU paperwork as I have no idea how we'd even test the fix. ** Changed in: lxd (Ubuntu) Status: New => 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/1959047 Title: systemd ignores RootDirectory option in .service units Status in lxd package in Ubuntu: Invalid Status in systemd package in Ubuntu: Confirmed Status in lxd source package in Bionic: New Status in systemd source package in Bionic: New Status in systemd source package in Focal: New Status in systemd source package in Impish: New Bug description: The version of systemd (249.5-2ubuntu4) currently packaged for the Ubuntu development version (22.04 Jammy Jellyfish) totally ignores the RootDirectory= option in systemd service files. With RootDirectory, systemd should start the service after calling chroot() on the supplied directory. To test/reproduce, create a test service file with the following contents: # /etc/systemd/system/lsb-release.service [Unit] Description=LSB Release Information [Service] Type=simple RootDirectory=/var/chroot/trusty ExecStartPre=/bin/pwd ExecStart=/usr/bin/lsb_release -a You should have a chroot environment in the specified RootDirectory, even though you can still deduce if systemd attempted to chroot or not from the resulting error message. In my example, I installed an end-of-life Ubuntu 14.04 Trusty Tahr in the chroot environment. On systems NOT affected by the problem, I get the following result when I start this test service. This is what I'd expect. Jan 25 20:40:40 dolly systemd[1]: Starting LSB Release Information... Jan 25 20:40:40 dolly pwd[361]: / Jan 25 20:40:40 dolly systemd[1]: Started LSB Release Information. Jan 25 20:40:40 dolly lsb_release[362]: No LSB modules are available. Jan 25 20:40:40 dolly lsb_release[362]: Distributor ID:Ubuntu Jan 25 20:40:40 dolly lsb_release[362]: Description:Ubuntu 14.04 LTS Jan 25 20:40:40 dolly lsb_release[362]: Release:14.04 Jan 25 20:40:40 dolly lsb_release[362]: Codename:trusty Jan 25 20:40:40 dolly systemd[1]: lsb-release.service: Succeeded. On the problematic system, however, I get the following result. Jan 25 21:21:08 savelog systemd[1]: Starting LSB Release Information... Jan 25 21:21:08 savelog systemd[1]: Started LSB Release Information. Jan 25 21:21:08 savelog pwd[81114]: / Jan 25 21:21:08 savelog lsb_release[81115]: No LSB modules are available. Jan 25 21:21:08 savelog lsb_release[81115]: Distributor ID:Ubuntu Jan 25 21:21:08 savelog lsb_release[81115]: Description:Ubuntu Jammy Jellyfish (development branch) Jan 25 21:21:08 savelog lsb_release[81115]: Release:22.04 Jan 25 21:21:08 savelog lsb_release[81115]: Codename:jammy Jan 25 21:21:08 savelog systemd[1]: lsb-release.service: Deactivated successfully. It totally run the service on the host's root filesystem, it didn't care even the slightest that a RootDirectory is specified. Tested on the following releases / systemd versions: Ubuntu 18.04.6 Bionic Beaver – ISSUE NOT PRESENT systemd 237 +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid Ubuntu 20.04.3 Focal Fossa – ISSUE NOT PRESENT systemd 245 (245.4-4ubuntu3.15) +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid Ubuntu 21.10 Impish Indri – ISSUE NOT PRESENT systemd 248 (248.3-1ubuntu8.2) +PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS -OPENSSL +ACL +BLKID +CURL +ELFUTILS -FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP -LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified Ubuntu 22.04 Jammy Jellyfish (development branch) – ISSUE PRESENT systemd 249 (249.5-2ubuntu4) +PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS -OPENSSL +ACL +BLKID +CURL +ELFUTILS -FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP -LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified Note that the problem is produced under an LXC container; since systemd detects virtualization, it might change how it behaves. It's either a bug or an intentional change I don't understand yet (i.e. the RootDirectory option has deprecated and is about to be replaced with something else, or there are additional conditions to be met before RootDirectory is considered), but I
[Touch-packages] [Bug 1959993] Re: SRU of LXC 4.0.12 to focal (upstream bugfix release)
Uploaded the exact same thing to impish queue. -- 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/1959993 Title: SRU of LXC 4.0.12 to focal (upstream bugfix release) Status in lxc package in Ubuntu: In Progress Bug description: LXC released 4.0.12 as a bugfix release and is now in jammy. We'd like to line things up in focal. [Impact] The proposed SRU will bump from 4.0.6 all the way to 4.0.12, lining it up with what's currently in jammy. We've been skipping a few of the bugfix releases in focal so far, mostly catching up when we're starting to see problems with the older version. In this case, we've seen a number of issues when running with the HWE kernels as well as autopkgtest issues on foreign architectures (arm64 and s390x), all those will go away with this bump as we've confirmed everything is clean in jammy. Changelog: * Cherry-pick upstream bugfixes (stable-4.0): - 0002-lxc-checkconfig-Fix-bashism.patch - 0003-doc-Fix-reverse-allowlist-denylist.patch * New upstream bugfix release (4.0.12): (https://discuss.linuxcontainers.org/t/lxc-4-0-12-has-been-released/13288) - Fixed CRIU restoration of containers with pre-created veth interfaces - Fixed issue with kernels lacking SMT support - Extended cgroup2 config options in lxc.mount.auto (cgroup2) - lxc-download now relies on HTTPS for validation (avoids GPG issues) * New upstream bugfix release (4.0.11): (https://discuss.linuxcontainers.org/t/lxc-4-0-11-has-been-released/12427) - Core scheduling support (lxc.sched.core) - riscv64 support in lxc.arch - Significantly improved bash completion profile - Greater use of the new VFS mount API (when supported by the kernel) - Fix containers with empty network namespaces - Handle kernels that lack TIOCGPTPEER - Improve CPU bitmask/id handling (handle skipped CPU numbers) - Reworked the tests to run offline * New upstream bugfix release (4.0.10): (https://discuss.linuxcontainers.org/t/lxc-4-0-10-has-been-released/11618) - Fix issues with less common architectures - Support for additional idmap mounts - nft support in lxc-net - Cleaner mount entries for sys:mixed - Switched GPG server to keyserver.ubuntu.com * New upstream bugfix release (4.0.9): (https://discuss.linuxcontainers.org/t/lxc-4-0-9-has-been-released/10999) - Fix incorrect personality setting when running 32bit containers on 64bit * New upstream bugfix release (4.0.8): - Fix CGroup attach against older running containers * New upstream bugfix release (4.0.7): - Testing improvements including fixes from oss-fuzz - Rework of the attach codepath - Cgroup handling rework * Bump to debhelper 12 (allows focal SRUs) * Bump standards to 4.6.0.1 * Add lintian overrides for incorrect bashism detection * Remove bash completion install logic (now done upstream) Just like Ubuntu itself, upstream releases long term support releases, e.g. 4.0, and then periodic point releases including all the accumulated bugfixes. Only the latest upstream release gets full support from the upstream developers, everyone else is expected to first update to it before receiving any kind of support. This should qualify under the minor/micro upstream bugfix release allowance of the SRU policy, letting us SRU this without paperwork for every single change included in this upstream release. [Test Plan] lxc has autopkgtests which will assert that the binaries built in -proposed are functional. [Where problems could occur] This is catching up a fair bit on recent kernel API changes, including cgroup1/cgroup2 support, handling of nftables, riscv64 and core scheduling which were all needed to properly handle the most recent HWE kernels especially as we're getting ready for Ubuntu 22.04's 5.15 to get pushed to focal. We've had all that code running on well over a million of LXD snap users for a few months now without seeing any issues (or more precisely, those issues we found have been all been resolved as of 4.0.12). However what LXD exercises isn't 100% of LXC and it's certainly possible that we missed a corner case in one of those changes. The good news is that this would most likely be triggered by a HWE kernel, so a viable workaround in many cases would be to temporarily go back to the original kernel (5.4) while the issue is sorted out in a follow up SRU. It's also worth noting that LXD CI runs daily tests against over a dozen different kernels coming from various distros which helps us identify such issues quite early on. [Other Info] Unless absolutely required, we're not intending to push for an SRU to impish as it has a reasonably recent LXC (4.0.10) and
[Touch-packages] [Bug 1959993] Re: SRU of LXC 4.0.12 to focal (upstream bugfix release)
Thanks Brian, my memory of this whole thing clearly dates back a long time then ;) I still remember some of the discussions of what we'd expect people to be doing in such cases and whether we'd ever officially support (as in test/validate) upgrade paths other than release to release+1 and LTS to LTS+1. I remember us struggling to really validate those two more common paths so I wonder what's done today to validate the upgrade paths when one release goes EOL and the upgrade path changes to something different for those upgrading from the LTS. -- 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/1959993 Title: SRU of LXC 4.0.12 to focal (upstream bugfix release) Status in lxc package in Ubuntu: In Progress Bug description: LXC released 4.0.12 as a bugfix release and is now in jammy. We'd like to line things up in focal. [Impact] The proposed SRU will bump from 4.0.6 all the way to 4.0.12, lining it up with what's currently in jammy. We've been skipping a few of the bugfix releases in focal so far, mostly catching up when we're starting to see problems with the older version. In this case, we've seen a number of issues when running with the HWE kernels as well as autopkgtest issues on foreign architectures (arm64 and s390x), all those will go away with this bump as we've confirmed everything is clean in jammy. Changelog: * Cherry-pick upstream bugfixes (stable-4.0): - 0002-lxc-checkconfig-Fix-bashism.patch - 0003-doc-Fix-reverse-allowlist-denylist.patch * New upstream bugfix release (4.0.12): (https://discuss.linuxcontainers.org/t/lxc-4-0-12-has-been-released/13288) - Fixed CRIU restoration of containers with pre-created veth interfaces - Fixed issue with kernels lacking SMT support - Extended cgroup2 config options in lxc.mount.auto (cgroup2) - lxc-download now relies on HTTPS for validation (avoids GPG issues) * New upstream bugfix release (4.0.11): (https://discuss.linuxcontainers.org/t/lxc-4-0-11-has-been-released/12427) - Core scheduling support (lxc.sched.core) - riscv64 support in lxc.arch - Significantly improved bash completion profile - Greater use of the new VFS mount API (when supported by the kernel) - Fix containers with empty network namespaces - Handle kernels that lack TIOCGPTPEER - Improve CPU bitmask/id handling (handle skipped CPU numbers) - Reworked the tests to run offline * New upstream bugfix release (4.0.10): (https://discuss.linuxcontainers.org/t/lxc-4-0-10-has-been-released/11618) - Fix issues with less common architectures - Support for additional idmap mounts - nft support in lxc-net - Cleaner mount entries for sys:mixed - Switched GPG server to keyserver.ubuntu.com * New upstream bugfix release (4.0.9): (https://discuss.linuxcontainers.org/t/lxc-4-0-9-has-been-released/10999) - Fix incorrect personality setting when running 32bit containers on 64bit * New upstream bugfix release (4.0.8): - Fix CGroup attach against older running containers * New upstream bugfix release (4.0.7): - Testing improvements including fixes from oss-fuzz - Rework of the attach codepath - Cgroup handling rework * Bump to debhelper 12 (allows focal SRUs) * Bump standards to 4.6.0.1 * Add lintian overrides for incorrect bashism detection * Remove bash completion install logic (now done upstream) Just like Ubuntu itself, upstream releases long term support releases, e.g. 4.0, and then periodic point releases including all the accumulated bugfixes. Only the latest upstream release gets full support from the upstream developers, everyone else is expected to first update to it before receiving any kind of support. This should qualify under the minor/micro upstream bugfix release allowance of the SRU policy, letting us SRU this without paperwork for every single change included in this upstream release. [Test Plan] lxc has autopkgtests which will assert that the binaries built in -proposed are functional. [Where problems could occur] This is catching up a fair bit on recent kernel API changes, including cgroup1/cgroup2 support, handling of nftables, riscv64 and core scheduling which were all needed to properly handle the most recent HWE kernels especially as we're getting ready for Ubuntu 22.04's 5.15 to get pushed to focal. We've had all that code running on well over a million of LXD snap users for a few months now without seeing any issues (or more precisely, those issues we found have been all been resolved as of 4.0.12). However what LXD exercises isn't 100% of LXC and it's certainly possible that we missed a corner case in one of those changes. The good news is that this would most likely be
[Touch-packages] [Bug 1960847] Re: lxc autopkgtests failures with cgroupv2 on jammy
The autopkgtest script in the Ubuntu package has: # Skip some tests due to cgroup v2 incompatibility if [ -e /sys/fs/cgroup/system.slice/memory.current ]; then [ "$testbin" = "lxc-test-apparmor-mount" ] && \ ignore "$STRING" && continue [ "$testbin" = "lxc-test-autostart" ] && \ ignore "$STRING" && continue [ "$testbin" = "lxc-test-no-new-privs" ] && \ ignore "$STRING" && continue [ "$testbin" = "lxc-test-unpriv" ] && \ ignore "$STRING" && continue fi And it did clear autopkgtest very recently in jammy. Closing this issue. I think a lot of the recent issues we've been getting with kernel testing of LXC is because you're not actually running the same autopkgtest and packages that we are in the main archive. This caused library/binary mismatches in a recent issue and now is causing issues because of the difference in test script (the on in lxc- ci is lagging behind in this case which isn't a problem as the LXC CI environment runs hybrid cgroupv1 on purpose). ** 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/1960847 Title: lxc autopkgtests failures with cgroupv2 on jammy Status in ubuntu-kernel-tests: New Status in lxc package in Ubuntu: Invalid Bug description: Some lxc autotests (like lxc-test-apparmor-mount for example) are still expecting to find cgroupv1 or a hybrid hierarchy and they just fail on jammy, because systemd is now using a full cgroupv2 hierarchy. Running these tests in a cgroupv2 system is pointless, because it's just going to trigger lots of errors and it's not really stress- testing anything. We should consider to create a new test based on this: https://github.com/lxc/lxc-ci and enable it only on those systems that are using cgroupv2 (for example checking if /sys/fs/cgroup/cgroup.procs exists as a regular file). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1960847/+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 1960847] Re: lxc autopkgtests failures with cgroupv2 on jammy
Marking this invalid against LXC as the code in the archive for package testing is handling this case properly already. -- 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/1960847 Title: lxc autopkgtests failures with cgroupv2 on jammy Status in ubuntu-kernel-tests: New Status in lxc package in Ubuntu: Invalid Bug description: Some lxc autotests (like lxc-test-apparmor-mount for example) are still expecting to find cgroupv1 or a hybrid hierarchy and they just fail on jammy, because systemd is now using a full cgroupv2 hierarchy. Running these tests in a cgroupv2 system is pointless, because it's just going to trigger lots of errors and it's not really stress- testing anything. We should consider to create a new test based on this: https://github.com/lxc/lxc-ci and enable it only on those systems that are using cgroupv2 (for example checking if /sys/fs/cgroup/cgroup.procs exists as a regular file). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1960847/+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 1959993] Re: SRU of LXC 4.0.12 to focal (upstream bugfix release)
(We technically had the same issue with the previous upload as 4.0.6 was higher than what hirsute shipped at the time, though in that case the EOL for hirsute was just a month or so away making the case for skipping that SRU even stronger :)) -- 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/1959993 Title: SRU of LXC 4.0.12 to focal (upstream bugfix release) Status in lxc package in Ubuntu: In Progress Bug description: LXC released 4.0.12 as a bugfix release and is now in jammy. We'd like to line things up in focal. [Impact] The proposed SRU will bump from 4.0.6 all the way to 4.0.12, lining it up with what's currently in jammy. We've been skipping a few of the bugfix releases in focal so far, mostly catching up when we're starting to see problems with the older version. In this case, we've seen a number of issues when running with the HWE kernels as well as autopkgtest issues on foreign architectures (arm64 and s390x), all those will go away with this bump as we've confirmed everything is clean in jammy. Changelog: * Cherry-pick upstream bugfixes (stable-4.0): - 0002-lxc-checkconfig-Fix-bashism.patch - 0003-doc-Fix-reverse-allowlist-denylist.patch * New upstream bugfix release (4.0.12): (https://discuss.linuxcontainers.org/t/lxc-4-0-12-has-been-released/13288) - Fixed CRIU restoration of containers with pre-created veth interfaces - Fixed issue with kernels lacking SMT support - Extended cgroup2 config options in lxc.mount.auto (cgroup2) - lxc-download now relies on HTTPS for validation (avoids GPG issues) * New upstream bugfix release (4.0.11): (https://discuss.linuxcontainers.org/t/lxc-4-0-11-has-been-released/12427) - Core scheduling support (lxc.sched.core) - riscv64 support in lxc.arch - Significantly improved bash completion profile - Greater use of the new VFS mount API (when supported by the kernel) - Fix containers with empty network namespaces - Handle kernels that lack TIOCGPTPEER - Improve CPU bitmask/id handling (handle skipped CPU numbers) - Reworked the tests to run offline * New upstream bugfix release (4.0.10): (https://discuss.linuxcontainers.org/t/lxc-4-0-10-has-been-released/11618) - Fix issues with less common architectures - Support for additional idmap mounts - nft support in lxc-net - Cleaner mount entries for sys:mixed - Switched GPG server to keyserver.ubuntu.com * New upstream bugfix release (4.0.9): (https://discuss.linuxcontainers.org/t/lxc-4-0-9-has-been-released/10999) - Fix incorrect personality setting when running 32bit containers on 64bit * New upstream bugfix release (4.0.8): - Fix CGroup attach against older running containers * New upstream bugfix release (4.0.7): - Testing improvements including fixes from oss-fuzz - Rework of the attach codepath - Cgroup handling rework * Bump to debhelper 12 (allows focal SRUs) * Bump standards to 4.6.0.1 * Add lintian overrides for incorrect bashism detection * Remove bash completion install logic (now done upstream) Just like Ubuntu itself, upstream releases long term support releases, e.g. 4.0, and then periodic point releases including all the accumulated bugfixes. Only the latest upstream release gets full support from the upstream developers, everyone else is expected to first update to it before receiving any kind of support. This should qualify under the minor/micro upstream bugfix release allowance of the SRU policy, letting us SRU this without paperwork for every single change included in this upstream release. [Test Plan] lxc has autopkgtests which will assert that the binaries built in -proposed are functional. [Where problems could occur] This is catching up a fair bit on recent kernel API changes, including cgroup1/cgroup2 support, handling of nftables, riscv64 and core scheduling which were all needed to properly handle the most recent HWE kernels especially as we're getting ready for Ubuntu 22.04's 5.15 to get pushed to focal. We've had all that code running on well over a million of LXD snap users for a few months now without seeing any issues (or more precisely, those issues we found have been all been resolved as of 4.0.12). However what LXD exercises isn't 100% of LXC and it's certainly possible that we missed a corner case in one of those changes. The good news is that this would most likely be triggered by a HWE kernel, so a viable workaround in many cases would be to temporarily go back to the original kernel (5.4) while the issue is sorted out in a follow up SRU. It's also worth noting that LXD CI runs daily tests against over a dozen different kernels coming from various distros which
[Touch-packages] [Bug 1959993] Re: SRU of LXC 4.0.12 to focal (upstream bugfix release)
In general, it's indeed a problem for such cases, though there are a few mitigating factors here: - This would only be a problem for those who upgrade from focal to impish. My understanding is that there is no direct upgrade path to achieve this, you'd need to go throughgroovy and hirsute, both of which are EOL, so I wouldn't really expect many/any user to do this. - The LXC team is responsible for self-assigning CVEs and preparing LXC security updates (~ubuntu-lxc-security). In such cases we usually prefer releasing a new upstream bugfix release (LXC 4.0.x is an LTS with a 5 years security commitment upstream) and then upload that to the -security pockets where applicable. So in that case, we'd bump jammy to match focal, saving us some effort on validating the security update by making things be identical on all releases shipping 4.0.x (jammy will be on 5.0.x). That's generally how we've handled those micro release updates and so far haven't run into any problems but I'm also not necessarily against uploading the exact same source package as focal to impish, the preparation time would be pretty minimal, it's mostly on the review and testing side of things that things can increase significantly especially as we usually struggle to find users on non-LTS to perform more than a simple install/upgrade test. -- 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/1959993 Title: SRU of LXC 4.0.12 to focal (upstream bugfix release) Status in lxc package in Ubuntu: In Progress Bug description: LXC released 4.0.12 as a bugfix release and is now in jammy. We'd like to line things up in focal. [Impact] The proposed SRU will bump from 4.0.6 all the way to 4.0.12, lining it up with what's currently in jammy. We've been skipping a few of the bugfix releases in focal so far, mostly catching up when we're starting to see problems with the older version. In this case, we've seen a number of issues when running with the HWE kernels as well as autopkgtest issues on foreign architectures (arm64 and s390x), all those will go away with this bump as we've confirmed everything is clean in jammy. Changelog: * Cherry-pick upstream bugfixes (stable-4.0): - 0002-lxc-checkconfig-Fix-bashism.patch - 0003-doc-Fix-reverse-allowlist-denylist.patch * New upstream bugfix release (4.0.12): (https://discuss.linuxcontainers.org/t/lxc-4-0-12-has-been-released/13288) - Fixed CRIU restoration of containers with pre-created veth interfaces - Fixed issue with kernels lacking SMT support - Extended cgroup2 config options in lxc.mount.auto (cgroup2) - lxc-download now relies on HTTPS for validation (avoids GPG issues) * New upstream bugfix release (4.0.11): (https://discuss.linuxcontainers.org/t/lxc-4-0-11-has-been-released/12427) - Core scheduling support (lxc.sched.core) - riscv64 support in lxc.arch - Significantly improved bash completion profile - Greater use of the new VFS mount API (when supported by the kernel) - Fix containers with empty network namespaces - Handle kernels that lack TIOCGPTPEER - Improve CPU bitmask/id handling (handle skipped CPU numbers) - Reworked the tests to run offline * New upstream bugfix release (4.0.10): (https://discuss.linuxcontainers.org/t/lxc-4-0-10-has-been-released/11618) - Fix issues with less common architectures - Support for additional idmap mounts - nft support in lxc-net - Cleaner mount entries for sys:mixed - Switched GPG server to keyserver.ubuntu.com * New upstream bugfix release (4.0.9): (https://discuss.linuxcontainers.org/t/lxc-4-0-9-has-been-released/10999) - Fix incorrect personality setting when running 32bit containers on 64bit * New upstream bugfix release (4.0.8): - Fix CGroup attach against older running containers * New upstream bugfix release (4.0.7): - Testing improvements including fixes from oss-fuzz - Rework of the attach codepath - Cgroup handling rework * Bump to debhelper 12 (allows focal SRUs) * Bump standards to 4.6.0.1 * Add lintian overrides for incorrect bashism detection * Remove bash completion install logic (now done upstream) Just like Ubuntu itself, upstream releases long term support releases, e.g. 4.0, and then periodic point releases including all the accumulated bugfixes. Only the latest upstream release gets full support from the upstream developers, everyone else is expected to first update to it before receiving any kind of support. This should qualify under the minor/micro upstream bugfix release allowance of the SRU policy, letting us SRU this without paperwork for every single change included in this upstream release. [Test Plan] lxc has autopkgtests which will assert that
[Touch-packages] [Bug 1960094] Re: lxc/1:4.0.6-0ubuntu1~20.04.1 undefined symbol: strlcat in Focal
** Changed in: lxc (Ubuntu) Status: Incomplete => Invalid ** Changed in: lxc (Ubuntu Focal) Status: Incomplete => Invalid ** No longer affects: lxc (Ubuntu) ** No longer affects: lxc (Ubuntu Focal) -- 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/1960094 Title: lxc/1:4.0.6-0ubuntu1~20.04.1 undefined symbol: strlcat in Focal Status in linux package in Ubuntu: New Status in linux source package in Focal: New Bug description: There are failures in ubuntu_lxc regression tests on Focal/linux/5.4.0-99.112 sru cycle 2022.01.03 with the error lxc-create: symbol lookup error: lxc-create: undefined symbol: strlcat These errors did not appear on previous kernels in the same cycle and now have a few tests failing on all architectures and systems as of Feb 4th 2022 it seems. Log with details is attached in the comments. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1960094/+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 1960094] Re: lxc/1:4.0.6-0ubuntu1~20.04.1 undefined symbol: strlcat in Focal
I think the strlcat thing is a red herring or an indication that the test environment is somehow in a bad shape. This could be explained if there was two versions of liblxc on the system for example. Outside of that, I'm also seeing: ``` lxc-start tmp.KEpxw2rh0e 20220205081512.354 ERRORutils - utils.c:__safe_mount_beneath_at:1106 - Function not implemented - Failed to open 30(full) ``` Which isn't a test issue but an actual failure. It could once again come from a bad test environment with mismatching library/binary somehow, but if the test environment isn't the issue, then you have a kernel regression on your hands as that's not one of those transient test failures. -- 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/1960094 Title: lxc/1:4.0.6-0ubuntu1~20.04.1 undefined symbol: strlcat in Focal Status in linux package in Ubuntu: New Status in lxc package in Ubuntu: Incomplete Status in linux source package in Focal: New Status in lxc source package in Focal: Incomplete Bug description: There are failures in ubuntu_lxc regression tests on Focal/linux/5.4.0-99.112 sru cycle 2022.01.03 with the error lxc-create: symbol lookup error: lxc-create: undefined symbol: strlcat These errors did not appear on previous kernels in the same cycle and now have a few tests failing on all architectures and systems as of Feb 4th 2022 it seems. Log with details is attached in the comments. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1960094/+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 1502604] Re: autopkgtests fail in LXC testbed
** Changed in: lxc (Ubuntu)
Status: Triaged => Won't Fix
--
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/1502604
Title:
autopkgtests fail in LXC testbed
Status in Auto Package Testing:
Invalid
Status in lxc package in Ubuntu:
Won't Fix
Bug description:
This spawned from
https://plus.google.com/u/0/+MartinPitti/posts/JE8be51XRZy : lxc's
autopkgtests currently fail on armhf/ppc64el where we run autopkgtests
in an LXC container
(http://autopkgtest.ubuntu.com/packages/l/lxc/wily/armhf/).
The testbeds use a custom and more liberal apparmor profile than the
default LXC one (see http://bazaar.launchpad.net/~auto-package-
testing-dev/auto-package-testing/trunk/view/head:/slave-admin/setup-
adt-lxc.commands):
profile lxc-container-adt flags=(attach_disconnected,mediate_deleted) {
#include
#include
# Nesting
mount fstype=cgroup -> /sys/fs/cgroup/**,
mount fstype=proc -> /var/cache/lxc/**,
mount fstype=sysfs -> /var/cache/lxc/**,
mount options=(rw,bind) /var/cache/lxc/**/dev/shm/ ->
/var/cache/lxc/**/run/shm/,
# Required for lxc-tests
mount options=(rw,bind) /lib/** -> /var/lib/lxc**,
mount options=(rw,rbind) /var/lib/lxcsnaps/** -> /var/lib/lxcsnaps/**,
# Allow containers to mount /proc, e. g. for sbuild/pbuilder tests
mount options=(rw,bind),
mount fstype=devpts,
mount fstype=proc,
mount fstype=sysfs,
}
But with just this they hang eternally and time out, and there are
also some test failures.
Reproducer: (tested on wily amd64):
adt-build-lxc ubuntu wily
echo "lxc.aa_profile = unconfined" | tee -a /var/lib/lxc/adt-wily/config
adt-run lxc --- lxc -s adt-wily
To manage notifications about this bug go to:
https://bugs.launchpad.net/auto-package-testing/+bug/1502604/+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 1510108] Re: pre-installed lxc in cloud-image means loss of access to 10.0.X.0/24
Closing as these days we only have LXD preinstalled on those images and LXD does a lot more validation and only creates the networks on first use. ** Changed in: lxc (Ubuntu) Status: Triaged => Won't Fix -- 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/1510108 Title: pre-installed lxc in cloud-image means loss of access to 10.0.X.0/24 Status in lxc package in Ubuntu: Won't Fix Bug description: Bug 1509414 describes fallout of inclusion of lxc in cloud images. The initial inclusion caused 2 issues: a.) containers created by 'lxc -t ubuntu-cloud' and 'lxd import-images ubuntu wily' had completely broken networking b.) all cloud images would have lost access to 10.0.3.0/24 networks. The fix that went in fixes 'a' above. By default, containers created for lxd and lxc will now work as expected. This bug is opened to address the much less severe 'b'. Now, on first boot lxc-net selects a network in the 10.0.X.0/24 to give to the lxcbr0 bridge. It selects the network by simply looking for the first available N where there . That code can be seen prior to fix in debian/lxc.preinst [1] and after fix in config/init/common/lxc-net.in [2]. Generally speaking it looks for local ip addresses on the targeted network. That code is fairly simplistic. There are definitely cases where it can pick a network that would be used by this system. The result is that traffic destined for that network will be sent to the lxcbr0 rather than out of the system to wherever it should go. The suggested fix would be to make that code run on 'lxc' or 'lxd' usage rather than on instance boot. By doing so, we reduce the set of users possibly affected from all cloud-image users to all users of lxc or lxd. Note, all users of lxd and lxc have been affected by this bug since at least 14.04. -- [1] https://github.com/lxc/lxc-pkg-ubuntu/blob/dpm-wily/debian/lxc.preinst#L55 [2] https://github.com/lxc/lxc-pkg-ubuntu/blob/dpm-wily/config/init/common/lxc-net.in Related bugs: * bug 1509414: pre-installed lxc in cloud image produces broken lxc (and later lxd) containers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1510108/+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 1591124] Re: LXC: Cannot create a container with the specific alias "tasks"
** Changed in: lxc (Ubuntu) Status: Triaged => 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/1591124 Title: LXC: Cannot create a container with the specific alias "tasks" Status in lxc package in Ubuntu: Fix Released Bug description: When trying to launch a container with the specific alias "tasks", it fails to launch. $ lxc launch d23ee1f4fd28 tasks Creating tasks Starting tasks error: Error calling 'lxd forkstart tasks /var/lib/lxd/containers /var/log/lxd/tasks/lxc.conf': err='exit status 1' Try `lxc info --show-log tasks` for more info Exit 1 The reason is that in /sys/fs/cgroup/systemd/lxc/ there is already a file called "tasks". In that directory, any new containers is created as a new directory that has as a name the alias that we have given. Since "tasks" is reserved", lxc fails to continue. Here are the contents of the directory $ ls -l /sys/fs/cgroup/systemd/lxc/ total 0 drwxrwxr-x 5 root 165536 0 Ιούν 10 12:32 c1 -rw-r--r-- 1 root root 0 Ιούν 10 12:53 cgroup.clone_children -rw-r--r-- 1 root root 0 Ιούν 10 12:53 cgroup.procs -rw-r--r-- 1 root root 0 Ιούν 10 12:53 notify_on_release -rw-r--r-- 1 root root 0 Ιούν 10 12:53 tasks Currently, there is potential conflict with "tasks" only as the other filenames are invalid hostnames (contain dots or underscores). Presumably in the future there might be more such files. Among the solutions, 1. the container directories in /sys/fs/cgroup/systemd/lxc/ should have something like ".lxd" appended to them so that there is no future conflict. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1591124/+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 1226855] Re: Cannot use open-iscsi inside LXC container
Closing the LXC side of this bug as there's nothing we can really do here. It's either a kernel issue (needs support for their socket option within a network namespace) or an open-iscsi issue where they could have some kind of fallback mechanism. ** Changed in: lxc (Ubuntu) Status: Confirmed => 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/1226855 Title: Cannot use open-iscsi inside LXC container Status in linux package in Ubuntu: Confirmed Status in lxc package in Ubuntu: Invalid Bug description: Trying to use open-iscsi from within an LXC container, but the iscsi netlink socket does not support multiple namespaces, causing: "iscsid: sendmsg: bug? ctrl_fd 6" error and failure. Command attempted: iscsiadm -m node -p $ip:$port -T $target --login Results in: Exit code: 18 Stdout: 'Logging in to [iface: default, target: $target, portal: $ip,$port] (multiple)' Stderr: 'iscsiadm: got read error (0/0), daemon died? iscsiadm: Could not login to [iface: default, target: $target, portal: $ip,$port]. iscsiadm: initiator reported error (18 - could not communicate to iscsid) iscsiadm: Could not log into all portals' ProblemType: Bug DistroRelease: Ubuntu 13.04 Package: lxc 0.9.0-0ubuntu3.4 ProcVersionSignature: Ubuntu 3.8.0-30.44-generic 3.8.13.6 Uname: Linux 3.8.0-30-generic x86_64 ApportVersion: 2.9.2-0ubuntu8.3 Architecture: amd64 Date: Tue Sep 17 14:38:08 2013 InstallationDate: Installed on 2013-01-15 (245 days ago) InstallationMedia: Xubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.1) MarkForUpload: True SourcePackage: lxc UpgradeStatus: Upgraded to raring on 2013-05-16 (124 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1226855/+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 1303756] Re: make lxc-console work non-confusingly by default on touch images
Ubuntu Touch hasn't been a thing for a few years and UBPorts hasn't really been hitting this issue as far as I know. ** Changed in: lxc (Ubuntu) Status: Triaged => Won't Fix -- 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/1303756 Title: make lxc-console work non-confusingly by default on touch images Status in lxc package in Ubuntu: Won't Fix Bug description: I learned after a few failed tries previously that lxc-console works on the touch images if it uses tty0 and if a return is pressed after the greeting. This is not easy to discover. Would there be a way to set good defaults here without affecting non-touch uses of lxc- console? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1303756/+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 1522992] Re: /usr/bin/lxc-stop:11:strlen:prune_init_scope:try_get_abs_cgroup:do_cgm_get:cgm_get
** Changed in: lxc (Ubuntu) Status: Triaged => 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/1522992 Title: /usr/bin/lxc- stop:11:strlen:prune_init_scope:try_get_abs_cgroup:do_cgm_get:cgm_get Status in Canonical System Image: Fix Released Status in lxc package in Ubuntu: Fix Released Status in lxc package in Ubuntu RTM: Fix Released Bug description: The Ubuntu Error Tracker has been receiving reports about a problem regarding lxc. This problem was most recently seen with version 1.1.5-0ubuntu0.15.04.3, the problem page at https://errors.ubuntu.com/problem/d640a68bf7343705899d7ca8c6bc070d477cd845 contains more details. To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1522992/+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 1642767] Re: starting any container with umask 007 breaks host system shutdown. lxc-stop just hangs.
Moving over to the kernel as a userspace process shouldn't be able to cause such a hang regardless of what it does so this looks like a kernel bug (lock related by the looks of it). ** Package changed: lxc (Ubuntu) => linux (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/1642767 Title: starting any container with umask 007 breaks host system shutdown. lxc-stop just hangs. Status in linux package in Ubuntu: Confirmed Bug description: If I have umask 007 (or any other value that masks the world-execute bit) when I run lxc-start for the first time after logging in, my host system enters a state with the following problems: * lxc-stop hangs forever instead of stopping any container, even one that wasn't started with umask 007. * lxc-stop --kill --nolock hangs in the same way. * Attempts to reboot or shut down the host system fail, requiring a hard reset to recover. When lxc-stop hangs, messages like these appear in syslog every couple of minutes: Nov 17 01:22:11 hostbox kernel: [ 3360.091624] INFO: task systemd:12179 blocked for more than 120 seconds. Nov 17 01:22:11 hostbox kernel: [ 3360.091629] Tainted: P OE 4.4.0-47-generic #68-Ubuntu Nov 17 01:22:11 hostbox kernel: [ 3360.091631] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Nov 17 01:22:11 hostbox kernel: [ 3360.091633] systemd D 8800c6febb58 0 12179 12168 0x0104 Nov 17 01:22:11 hostbox kernel: [ 3360.091638] 8800c6febb58 8800d318d280 88040c649b80 8800d318d280 Nov 17 01:22:11 hostbox kernel: [ 3360.091641] 8800c6fec000 8800345bc088 8800345bc070 Nov 17 01:22:11 hostbox kernel: [ 3360.091644] fffe0001 8800c6febb70 81830f15 8800d318d280 Nov 17 01:22:11 hostbox kernel: [ 3360.091647] Call Trace: Nov 17 01:22:11 hostbox kernel: [ 3360.091653] [] schedule+0x35/0x80 Nov 17 01:22:11 hostbox kernel: [ 3360.091657] [] rwsem_down_write_failed+0x202/0x350 Nov 17 01:22:11 hostbox kernel: [ 3360.091662] [] ? kernfs_sop_show_options+0x40/0x40 Nov 17 01:22:11 hostbox kernel: [ 3360.091666] [] call_rwsem_down_write_failed+0x13/0x20 Nov 17 01:22:11 hostbox kernel: [ 3360.091669] [] ? down_write+0x2d/0x40 Nov 17 01:22:11 hostbox kernel: [ 3360.091672] [] grab_super+0x30/0xa0 Nov 17 01:22:11 hostbox kernel: [ 3360.091674] [] sget_userns+0x152/0x450 Nov 17 01:22:11 hostbox kernel: [ 3360.091677] [] ? kernfs_sop_show_path+0x50/0x50 Nov 17 01:22:11 hostbox kernel: [ 3360.091680] [] kernfs_mount_ns+0x7e/0x230 Nov 17 01:22:11 hostbox kernel: [ 3360.091685] [] cgroup_mount+0x2eb/0x7f0 Nov 17 01:22:11 hostbox kernel: [ 3360.091687] [] mount_fs+0x38/0x160 Nov 17 01:22:11 hostbox kernel: [ 3360.091691] [] vfs_kern_mount+0x67/0x110 Nov 17 01:22:11 hostbox kernel: [ 3360.091694] [] do_mount+0x269/0xde0 Nov 17 01:22:11 hostbox kernel: [ 3360.091698] [] SyS_mount+0x9f/0x100 Nov 17 01:22:11 hostbox kernel: [ 3360.091701] [] entry_SYSCALL_64_fastpath+0x16/0x71 When system shutdown hangs, similar messages appear on the console every couple of minutes. I can reproduce this at will with a freshly-installed and fully- updated host OS in VirtualBox, and with either an old-ish container or a new one. I'm running lxc 2.0.5-0ubuntu1~ubuntu16.04.2 on xubuntu 16.04.1 LTS amd64. My containers are all unprivileged. My umask at container creation time does not seem to matter. As far as I have seen, my umask only matters the first time I start a container in my login session. I can work around the bug by manually setting my umask to something more permissive before I start my first container of the day, and then setting it back again, but that's rather a hassle. (Even worse, it's very easy to forget this workaround and be left with containers that can't be stopped and a host system that won't shut down cleanly.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1642767/+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 1549391] Re: /proc/sched_debug Information Leak
Closing as it's not really LXC's job to try and change that one. These days we'd recommend distros to change default permissions or ideally get that changed at the kernel level. Short of that, we do have some documented recommendations in our production environment doc for LXD: https://linuxcontainers.org/lxd/docs/master/production-setup/ ** Changed in: lxc (Ubuntu) Status: Triaged => 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/1549391 Title: /proc/sched_debug Information Leak Status in lxc package in Ubuntu: Invalid Bug description: Description: Unprivileged containers can read from '/proc/sched_debug', a world-readable file within proc that contains a large amount of CFS and CPU scheduler information. This allows a trivial information leak which discloses what processes IDs and names are running in the host or other containers, as well as cgroup information which can disclose container names and other details. This effectively breaks the expected PID Namespace isolation. Reproduction: Inside a default and unprivileged LXC container, run the command `cat /proc/sched_debug`. Note that information is displayed about processes running on the host, as well as inside other containers. Sample output includes: task PID tree-key switches prio exec-runtime sum-exec sum-sleep -- kthreadd 2 319429235.224770 9339 120 319429235.224770 753.267075 1067018909.484918 0 / rcu_sched 7 319489137.064234 18896675 120 319489137.064234 170125.420028 1066508074.968528 0 / rcuos/513 319218638.012762 192 120 319218638.012762 0.896416 1065991450.159691 0 / SNIP SNIP acpid 1813 57932.203222 1676704 120 57932.203222 114395.580999 1067170248.528885 0 /autogroup-222 sh 2273 113050772.15088442 120 113050772.150884 0.754525 1066111947.155906 0 /user/1000.user/c1.session bash 2276 113052316.082339 788 120 113052316.082339 137.826052 1066155735.798643 0 /user/1000.user/c1.session wpa_supplicant 2319 113098971.410443119765 120 113098971.410443 6903.885769 1067229349.942336 0 /user/1000.user/c1.session sh 2426 113050772.15195643 120 113050772.151956 2.035147 1066012436.338286 0 /user/1000.user/c1.session urxvt 2440 113098872.794317606323 120 113098872.794317 28198.224898 1067122648.025421 0 /user/1000.user/c1.session dbus-daemon 2664 113092371.341763 6155 109 113092371.341763 432.939147 1066723733.656385 0 /user/1000.user/c1.session dio/dm-2 2695 20657.783903 2 100 20657.783903 0.007240 0.002253 0 / Chrome_FileThre 3286 31903985.081343213744 120 31903985.081343 14398.389541 1065335604.938435 0 /lxc/chrome Recommendation: In the short term, modify the base LXC AppArmor profile to block access to this file. In the long term, this procfs interface should be rewritten to be namespace aware and possibly restricted to root-only users. If AppArmor is not in use, end-users could recompile their kernel to have CONFIG_SCHED_DEBUG disabled. # About NCC: NCC Group is a security consulting company that performs all manner of security testing and has a strong desire to help make the industry a better, more resilient place. Because of this, when NCC Group identifies vulnerabilities in a system they prefer to work closely with vendors to create more secure systems. NCC Group strongly believes in responsible disclosure, and has strict guidelines in place to ensure that proper disclosure procedure is followed at all times. This serves the dual purpose of allowing the vendor to safely secure the product or system in question as well as allowing NCC Group to share cutting edge research or advisories with the security community. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1549391/+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 1515615] Re: Disk quotas don't work in LXC containers
@brauner do you know what's the state of quotas in a VFS idmapped shifted world? -- 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/1515615 Title: Disk quotas don't work in LXC containers Status in lxc package in Ubuntu: Triaged Bug description: I'm trying to enable disk quotas in LXC container by adding option to its config: lxc.rootfs.options = usrquota After booting the container I'm trying to initialize quotas but getting the following error: r...@test.lxc:~# quotacheck -gum / quotacheck: Cannot stat() mounted device /dev/lxc/test: No such file or directory quotacheck: Mountpoint (or device) / not found or has no quota enabled. quotacheck: Cannot find filesystem to check or filesystem not mounted with quota option. Host OS: Ubuntu 15.04 Guest OS: Ubuntu 14.04.3 LTS lxc 1.1.2-0ubuntu3.2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1515615/+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 1813362] Re: lxc-top flash error and blkio write is always zero
Could you recheck with the current LXC (4.0.12) as the cgroup code was reworked quite extensively. ** Changed in: lxc (Ubuntu) Status: Confirmed => Incomplete -- 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/1813362 Title: lxc-top flash error and blkio write is always zero Status in lxc package in Ubuntu: Incomplete Bug description: When running lxc-top as root it flashes the following error messages for every container: Unable to read cgroup item memory.memsw.usage_in_bytes Unable to read cgroup item memory.memsw.limit_in_bytes Here output showing bad blkio write Container CPU CPU CPU BlkIOMem KMem Name Used Sys User Total(Read/Write) Used Used ltcd-root310.2298.26 196.88 315.06 MiB(315.06 MiB/ 0.00 ) 688.64 MiB 83.09 MiB ltcd-test236.0284.52 136.76 115.88 MiB(115.88 MiB/ 0.00 ) 384.39 MiB 31.89 MiB TOTAL 2 of 2 546.24 182.78 333.64 430.94 MiB(430.94 MiB/ 0.00 ) 1.04 GiB 114.97 MiB Doing an strace on lxc-top: openat(AT_FDCWD, "/sys/fs/cgroup/memory//lxc/ltcd-root/memory.memsw.usage_in_bytes", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) write(2, "Unable to read cgroup item memor"..., 55) = 55 openat(AT_FDCWD, "/sys/fs/cgroup/memory//lxc/ltcd-root/memory.memsw.limit_in_bytes", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) write(2, "Unable to read cgroup item memor"..., 55) = 55 Here is copy /sys/fs/cgroup/memory/lxc/ltcd-root mike@mike-desktop:/sys/fs/cgroup/memory/lxc/ltcd-root$ ls cgroup.clone_children memory.limit_in_bytes cgroup.event_control memory.max_usage_in_bytes cgroup.procs memory.move_charge_at_immigrate init.scopememory.numa_stat memory.failcntmemory.oom_control memory.force_emptymemory.pressure_level memory.kmem.failcnt memory.soft_limit_in_bytes memory.kmem.limit_in_bytesmemory.stat memory.kmem.max_usage_in_bytesmemory.swappiness memory.kmem.slabinfo memory.usage_in_bytes memory.kmem.tcp.failcnt memory.use_hierarchy memory.kmem.tcp.limit_in_bytesnotify_on_release memory.kmem.tcp.max_usage_in_bytes system.slice memory.kmem.tcp.usage_in_bytestasks memory.kmem.usage_in_bytesuser.slice ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: lxc-utils 3.0.3-0ubuntu1~18.04.1 ProcVersionSignature: Ubuntu 4.18.0-13.14~18.04.1-generic 4.18.17 Uname: Linux 4.18.0-13-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.9-0ubuntu7.5 Architecture: amd64 Date: Fri Jan 25 15:56:04 2019 InstallationDate: Installed on 2018-02-23 (336 days ago) InstallationMedia: Ubuntu-GNOME 16.04.3 LTS "Xenial Xerus" - Release amd64 (20170801) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: lxc UpgradeStatus: Upgraded to bionic on 2018-10-21 (95 days ago) mtime.conffile..etc.lxc.default.conf: 2019-01-24T17:40:41.527776 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1813362/+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
** 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/1646462 Title: lxc-create cannot setgid Status in lxc: Fix Released Status in lxc package in Ubuntu: Fix Released 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 1857542] Re: lxc-checkpoint needs the criu package
CRIU is once again in the archive (Ubuntu is just following what's in Debian for this one). ** 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/1857542 Title: lxc-checkpoint needs the criu package Status in lxc package in Ubuntu: Fix Released Bug description: lxc-checkpoint needs criu to be installed but the criu package is absent in eoan and focal (criu exists in disco and bionic). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1857542/+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 B/5.4 kernels (device_add_remove_test)
** Changed in: lxc (Ubuntu) Status: In Progress => Fix Released ** Changed in: lxc (Ubuntu Bionic) Status: Confirmed => Triaged -- 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 B/5.4 kernels (device_add_remove_test) Status in ubuntu-kernel-tests: New Status in lxc package in Ubuntu: Fix Released Status in lxc source package in Bionic: Triaged 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-kernel-tests/+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 1881292] Re: Linux 5.7: autopkgtest failures - lxc-test-cloneconfig && lxc-destroy
Did we ever see this one again or was it just transient? ** Changed in: lxc (Ubuntu) Status: New => Incomplete -- 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/1881292 Title: Linux 5.7: autopkgtest failures - lxc-test-cloneconfig && lxc-destroy Status in lxc package in Ubuntu: Incomplete Bug description: ... make[1]: Leaving directory '/tmp/autopkgtest.OzTsXV/build.myP/src' PASS: lxc-tests: lxc-test-api-reboot (75s) PASS: lxc-tests: lxc-test-apparmor (1s) PASS: lxc-tests: lxc-test-apparmor-generated (0s) PASS: lxc-tests: lxc-test-apparmor-mount (25s) PASS: lxc-tests: lxc-test-attach (0s) PASS: lxc-tests: lxc-test-autostart (38s) PASS: lxc-tests: lxc-test-basic (0s) PASS: lxc-tests: lxc-test-cgpath (0s) PASS: lxc-tests: lxc-test-checkpoint-restore (0s) FAIL: lxc-tests: lxc-test-cloneconfig (1s) --- lxc-destroy: lxctestb: tools/lxc_destroy.c: main: 242 Container is not defined Test 1 starting (/tmp/lxctest-2SbLtT/1.conf) lxc-destroy: lxctestb2: tools/lxc_destroy.c: main: 242 Container is not defined FAIL --- ... Groovy 5.7 kernel here: https://launchpad.net/~canonical-kernel- team/+archive/ubuntu/bootstrap - linux-5.7 Full log here: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest- groovy-canonical-kernel-team- bootstrap/groovy/amd64/l/lxc/20200528_142652_ac8b1@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1881292/+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 1883041] Re: libpam-cgfs fails to create freezer cgroup writable by user
** 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/1883041 Title: libpam-cgfs fails to create freezer cgroup writable by user Status in lxc package in Ubuntu: Invalid Bug description: This is on 16.04.6. It appears that on some systems, libpam-cgfs doesn't set the correct cgroup information, which prevents containers from starting. This can be seen by looking at the contents of /proc/self/cgroup, which in my case was: blkio:/user.slice cpu,cpuacct:/user.slice cpuset:/ devices:/user.slice freezer:/ hugetlb:/ memory:/user.slice name=systemd:/user.slice/user-18160.slice/session-12214.scope net_cls,net_prio:/ perf_event:/ pids:/user.slice/user-18160.slice whereas it should have instead of freezer:/ freezer:/user//0 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1883041/+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 1887919] Re: autopkgtest failure with libselinux 3.1
** 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/1887919 Title: autopkgtest failure with libselinux 3.1 Status in glibc package in Ubuntu: Fix Released Status in lxc package in Ubuntu: Invalid Bug description: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest- groovy/groovy/amd64/g/glibc/20200717_023434_9a6a8@/log.gz ... x86_64-linux-gnu-gcc-9 nss_files/files-service.c -c -std=gnu11 -fgnu89-inline -pipe -O2 -g -O3 -Wall -Wwrite-strings -Wundef -Werror -fmerge-all-constants -frounding-math -fstack-protector-strong -Wstrict-prototypes -Wold-style-definition -fmath-errno -fPIC -fcf-protection -U_FORTIFY_SOURCE -isystem /tmp/autopkgtest.p9VjWR/build.CPS/src/debian/include -I../include -I/tmp/autopkgtest.p9VjWR/build.CPS/src/build-tree/amd64-libc/nss -I/tmp/autopkgtest.p9VjWR/build.CPS/src/build-tree/amd64-libc -I../sysdeps/unix/sysv/linux/x86_64/64 -I../sysdeps/unix/sysv/linux/x86_64 -I../sysdeps/unix/sysv/linux/x86/include -I../sysdeps/unix/sysv/linux/x86 -I../sysdeps/x86/nptl -I../sysdeps/unix/sysv/linux/wordsize-64 -I../sysdeps/x86_64/nptl -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux -I../sysdeps/nptl -I../sysdeps/pthread -I../sysdeps/gnu -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix/x86_64 -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/x86_64/64 -I../sysdeps/x86_64/fpu/multiarch -I../sysdeps/x86_64/fpu -I../sysdeps/x86/fpu/include -I../sysdeps/x86/fpu -I../sysdeps/x86_64/multiarch -I../sysdeps/x86_64 -I../sysdeps/x86 -I../sysdeps/ieee754/float128 -I../sysdeps/ieee754/ldbl-96/include -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64/wordsize-64 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/wordsize-64 -I../sysdeps/ieee754 -I../sysdeps/generic -I.. -I../libio -I. -nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/9/include -isystem /tmp/autopkgtest.p9VjWR/build.CPS/src/debian/include -D_LIBC_REENTRANT -include /tmp/autopkgtest.p9VjWR/build.CPS/src/build-tree/amd64-libc/libc-modules.h -DMODULE_NAME=libnss_files -include ../include/libc-symbols.h -DPIC -DSHARED -DTOP_NAMESPACE=glibc -o /tmp/autopkgtest.p9VjWR/build.CPS/src/build-tree/amd64-libc/nss/files-service.os -MD -MP -MF /tmp/autopkgtest.p9VjWR/build.CPS/src/build-tree/amd64-libc/nss/files-service.os.dt -MT /tmp/autopkgtest.p9VjWR/build.CPS/src/build-tree/amd64-libc/nss/files-service.os makedb.c: In function ‘set_file_creation_context’: makedb.c:849:3: error: ‘security_context_t’ is deprecated [-Werror=deprecated-declarations] 849 | security_context_t ctx; | ^~ makedb.c:863:3: error: ‘matchpathcon’ is deprecated: Use selabel_lookup instead [-Werror=deprecated-declarations] 863 | if (matchpathcon (outname, S_IFREG | mode, ) == 0 && ctx != NULL) | ^~ In file included from makedb.c:50: /usr/include/selinux/selinux.h:500:12: note: declared here 500 | extern int matchpathcon(const char *path, |^~~~ ... https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/amd64/l/lxc/20200717_015751_af18d@/log.gz ... 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
[Touch-packages] [Bug 1907307] Re: lxc 1:4.0.4-0ubuntu3 ADT test failure with linux 5.10.0-7.8
Are we still seeing this? The failure looks a lot like it could be a legitimate kernel issue. ** Changed in: lxc (Ubuntu) Status: New => Incomplete ** Changed in: lxc (Ubuntu Focal) Status: New => Incomplete -- 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/1907307 Title: lxc 1:4.0.4-0ubuntu3 ADT test failure with linux 5.10.0-7.8 Status in lxc package in Ubuntu: Incomplete Status in lxc source package in Focal: Incomplete Bug description: Testing failed on: amd64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute-canonical-kernel-team-bootstrap/hirsute/amd64/l/lxc/20201208_183047_03358@/log.gz arm64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute-canonical-kernel-team-bootstrap/hirsute/arm64/l/lxc/20201208_193132_88a43@/log.gz ppc64el: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute-canonical-kernel-team-bootstrap/hirsute/ppc64el/l/lxc/20201208_194831_12ffc@/log.gz s390x: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute-canonical-kernel-team-bootstrap/hirsute/s390x/l/lxc/20201208_175951_b132c@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1907307/+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 1532314] Re: Buffer overflow in cgmanager
** Changed in: lxc (Ubuntu) Status: Confirmed => Won't Fix ** Changed in: libnih (Ubuntu) Status: Confirmed => Won't Fix -- 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/1532314 Title: Buffer overflow in cgmanager Status in cgmanager package in Ubuntu: Fix Released Status in libnih package in Ubuntu: Won't Fix Status in lxc package in Ubuntu: Won't Fix Bug description: Host: Ubuntu 15.10 lxc: 1.1.5-0ubuntu0.15.10.3 cgmanager: 0.39-2ubuntu2 Container: Ubuntu 15.10 Got the following trace in syslog. Please let me know what other information will be useful for troubleshooting. Jan 8 19:29:24 ip-10-169-249-164 cgmanager[7725]: *** buffer overflow detected ***: /sbin/cgmanager terminated Jan 8 19:29:24 ip-10-169-249-164 cgmanager[7725]: === Backtrace: = Jan 8 19:29:24 ip-10-169-249-164 cgmanager[7725]: /lib/x86_64-linux-gnu/libc.so.6(+0x78c4e)[0x7f1929550c4e] Jan 8 19:29:24 ip-10-169-249-164 cgmanager[7725]: /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7f19295f0e8c] Jan 8 19:29:24 ip-10-169-249-164 cgmanager[7725]: /lib/x86_64-linux-gnu/libc.so.6(+0x116e80)[0x7f19295eee80] Jan 8 19:29:24 ip-10-169-249-164 cgmanager[7725]: /lib/x86_64-linux-gnu/libc.so.6(+0x118dd7)[0x7f19295f0dd7] Jan 8 19:29:24 ip-10-169-249-164 cgmanager[7725]: /lib/x86_64-linux-gnu/libnih.so.1(nih_io_handle_fds+0xad)[0x7f1929d01b3d] Jan 8 19:29:24 ip-10-169-249-164 cgmanager[7725]: /lib/x86_64-linux-gnu/libnih.so.1(nih_main_loop+0x13f)[0x7f1929d05faf] Jan 8 19:29:24 ip-10-169-249-164 cgmanager[7725]: /sbin/cgmanager(+0x5145)[0x562d8fc75145] Jan 8 19:29:24 ip-10-169-249-164 cgmanager[7725]: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f19294f8a40] Jan 8 19:29:24 ip-10-169-249-164 cgmanager[7725]: /sbin/cgmanager(+0x53d9)[0x562d8fc753d9] Jan 8 19:29:24 ip-10-169-249-164 cgmanager[7725]: === Memory map: Jan 8 19:29:24 ip-10-169-249-164 cgmanager[7725]: 562d8fc7-562d8fc92000 r-xp ca:01 12884 /sbin/cgmanager Jan 8 19:29:24 ip-10-169-249-164 cgmanager[7725]: 562d8fe92000-562d8fe94000 r--p 00022000 ca:01 12884 /sbin/cgmanager Jan 8 19:29:24 ip-10-169-249-164 cgmanager[7725]: 562d8fe94000-562d8fe95000 rw-p 00024000 ca:01 12884 /sbin/cgmanager Jan 8 19:29:24 ip-10-169-249-164 cgmanager[7725]: 562d915f8000-562d9203 rw-p 00:00 0 [heap] Jan 8 19:29:24 ip-10-169-249-164 cgmanager[7725]: 7f1927d44000-7f1927d5a000 r-xp ca:01 395872 /lib/x86_64-linux-gnu/libgcc_s.so.1 Jan 8 19:29:24 ip-10-169-249-164 cgmanager[7725]: 7f1927d5a000-7f1927f59000 ---p 00016000 ca:01 395872 /lib/x86_64-linux-gnu/libgcc_s.so.1 Jan 8 19:29:24 ip-10-169-249-164 cgmanager[7725]: 7f1927f59000-7f1927f5a000 r--p 00015000 ca:01 395872 /lib/x86_64-linux-gnu/libgcc_s.so.1 Jan 8 19:29:24 ip-10-169-249-164 cgmanager[7725]: 7f1927f5a000-7f1927f5b000 rw-p 00016000 ca:01 395872 /lib/x86_64-linux-gnu/libgcc_s.so.1 Jan 8 19:29:24 ip-10-169-249-164 cgmanager[7725]: 7f1927f5b000-7f1927f67000 r-xp ca:01 403839 /lib/x86_64-linux-gnu/libnss_files-2.21.so Jan 8 19:29:24 ip-10-169-249-164 cgmanager[7725]: 7f1927f67000-7f1928166000 ---p c000 ca:01 403839 /lib/x86_64-linux-gnu/libnss_files-2.21.so Jan 8 19:29:24 ip-10-169-249-164 cgmanager[7725]: 7f1928166000-7f1928167000 r--p b000 ca:01 403839 /lib/x86_64-linux-gnu/libnss_files-2.21.so Jan 8 19:29:24 ip-10-169-249-164 cgmanager[7725]: 7f1928167000-7f1928168000 rw-p c000 ca:01 403839 /lib/x86_64-linux-gnu/libnss_files-2.21.so Jan 8 19:29:24 ip-10-169-249-164 cgmanager[7725]: 7f1928168000-7f1928173000 r-xp ca:01 403823 /lib/x86_64-linux-gnu/libnss_nis-2.21.so Jan 8 19:29:24 ip-10-169-249-164 cgmanager[7725]: 7f1928173000-7f1928372000 ---p b000 ca:01 403823 /lib/x86_64-linux-gnu/libnss_nis-2.21.so Jan 8 19:29:24 ip-10-169-249-164 cgmanager[7725]: 7f1928372000-7f1928373000 r--p a000 ca:01 403823 /lib/x86_64-linux-gnu/libnss_nis-2.21.so Jan 8 19:29:24 ip-10-169-249-164 cgmanager[7725]: 7f1928373000-7f1928374000 rw-p b000 ca:01 403823 /lib/x86_64-linux-gnu/libnss_nis-2.21.so Jan 8 19:29:24 ip-10-169-249-164 cgmanager[7725]: 7f1928374000-7f192838b000 r-xp ca:01 403845 /lib/x86_64-linux-gnu/libnsl-2.21.so Jan 8 19:29:24 ip-10-169-249-164 cgmanager[7725]: 7f192838b000-7f192858a000 ---p 00017000 ca:01 403845 /lib/x86_64-linux-gnu/libnsl-2.21.so Jan 8 19:29:24 ip-10-169-249-164
[Touch-packages] [Bug 1916669] Re: autopkgtests flaky for hirsute across various architectures
Seems green lately ** Changed in: lxc (Ubuntu) Status: New => 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/1916669 Title: autopkgtests flaky for hirsute across various architectures Status in lxc package in Ubuntu: Fix Released Bug description: Currently the lxc 1:4.0.4-1:4.0.4-0ubuntu3 and 1:4.0.6-0ubuntu1 autopkgtests for hirsute are quite flaky across most architectures: amd64 - https://autopkgtest.ubuntu.com/packages/l/lxc/hirsute/amd64 --- only 3 out of the last 8 runs were successful even after multiple manual retries for the same trigger package. arm64 - https://autopkgtest.ubuntu.com/packages/l/lxc/hirsute/arm64 --- only 3 out of the last 10 runs were successful even after multiple manual retries for the same trigger package. s390x - https://autopkgtest.ubuntu.com/packages/l/lxc/hirsute/s390x --- only 1 out of the last 12 runs were successful even after multiple manual retries for the same trigger package. ppc64el - https://autopkgtest.ubuntu.com/packages/l/lxc/hirsute/ppc64el --- this seems to be running better more recently but was failing previously for the same trigger packages against the same lxc package As such I feel it makes sense to mark both of these versions as force- reset-test so that lxc failures do not block other packages migrating. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1916669/+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
** Changed in: lxc (Ubuntu) Status: Confirmed => Won't Fix -- 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 ubuntu-kernel-tests: New Status in lxc package in Ubuntu: Won't Fix Status in lxc source package in Groovy: Won't Fix 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-kernel-tests/+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 1917187] Re: lxc cgroup2: containers unbootable
The error you're getting is coming from systemd in the container which for some reason is trying to mount a cgroup1 hierarchy rather than using cgroup2 like the rest of your system. You may be able to workaround that by using `lxc.init_cmd` to pass /sbin/init with additional arguments to change the systemd behavior in the container. ** 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/1917187 Title: lxc cgroup2: containers unbootable Status in lxc package in Ubuntu: Invalid Bug description: Distributor ID: Ubuntu Description: Ubuntu 20.04.2 LTS Release: 20.04 Codename: focal If one sets in /etc/default/grub (as e.g. desired by facebook oomd): GRUB_CMDLINE_LINUX="systemd.unified_cgroup_hierarchy=1 swapaccount=1 ..." lxc is not able to start any containers anymore. # lxc-start -F n04-01 lxc-start: n04-01: conf.c: lxc_setup_boot_id: 3249 Permission denied - Failed to mount /dev/.lxc-boot-id to /proc/sys/kernel/random/boot_id Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems. Exiting PID 1... config: --- # Common configuration lxc.include = /usr/share/lxc/config/ubuntu.common.conf # Container specific configuration lxc.apparmor.profile = lxc-default-cgns-with-mounting lxc.start.auto = 1 lxc.rootfs.path = dir:/zones/n04-01/rootfs lxc.rootfs.options = noatime lxc.mount.fstab = /zones/n04-01/fstab lxc.uts.name = n04-01 lxc.arch = amd64 # Network configuration lxc.net.0.type = macvlan lxc.net.0.macvlan.mode = bridge lxc.net.0.flags = up lxc.net.0.link = vlan2 lxc.net.0.hwaddr = 00:80:41:22:0d:10 lxc.net.0.name = n04-01_0 #lxc.include = /zones/n04-01/nvconfig lxc.start.order = 16 #lxc.net.0.ipv4 = 10.2.1.65/16 #lxc.net.0.ipv4.gateway = 10.2.0.1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1917187/+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 1931064] Re: lxc autotest failure with kernel >= 5.13
Marking as invalid as this wasn't an LXC bug but a kernel bug.
--
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:
Invalid
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 1931064] Re: lxc autotest failure with kernel >= 5.13
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=591a22c14d3f45cc38bd1931c593c221df2f1881
** 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/1931064
Title:
lxc autotest failure with kernel >= 5.13
Status in ubuntu-kernel-tests:
New
Status in lxc package in Ubuntu:
Invalid
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 1957934] Re: error in man page for lxc.container.conf
** 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/1957934 Title: error in man page for lxc.container.conf Status in lxc package in Ubuntu: In Progress Bug description: the man page or lxc.container.conf contains in "CONTROL GROUP" section the following text : -- • A allowlist device rule lxc.cgroup2.devices.deny = a will cause LXC to instruct the kernel to block access to all devices by default. To grant access to devices allow device rules must be added via the lxc.cgroup2.devices.allow key. This is referred to as a "allowlist" device program. • A denylist device rule lxc.cgroup2.devices.allow = a will cause LXC to instruct the kernel to allow access to all devices by default. To deny access to devices deny device rules must be added via lxc.cgroup2.devices.deny key. This is referred to as a "denylist" device program. --- the titles are inverted, the first is a denylist, the second is an allowlist ubuntu version : 21.10 package version : lxc-utils 1:4.0.10-0ubuntu5 amd64 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1957934/+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 1950787] Re: systemd-sysusers cannot mount /dev in privileged containers (to pass credentials)
Closing the LXD task as there's not really anything we can do there. The options here are pretty much: - Do nothing, if it's just privileged containers, it's usually not a big deal - Significantly rework apparmor mount handling logic and policies so this can be safely allowed - Ship unit overrides, either though lxd-agent-loader, through a systemd patch or a similar distro mechanism Closing the LXD task as there currently isn't any change we can make to our policies to safely allow this. ** Changed in: lxd (Ubuntu) Status: New => 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/1950787 Title: systemd-sysusers cannot mount /dev in privileged containers (to pass credentials) Status in lxd package in Ubuntu: Invalid Status in systemd package in Ubuntu: New Bug description: systemd-sysusers.service/systemd.exec fails to start in privileged containers, due to being unable to properly mount /dev for passing credentials, caused by the following config in the .service unit: ``` # Optionally, pick up a root password and shell for the root user from a # credential passed to the service manager. This is useful for importing this # data from nspawn's --set-credential= switch. LoadCredential=passwd.hashed-password.root LoadCredential=passwd.plaintext-password.root LoadCredential=passwd.shell.root ``` Reproducer: $ lxc profile set default security.privileged "true" $ lxc launch ubuntu-daily:jammy test $ lxc exec test bash # add-apt-repository ppa:ci-train-ppa-service/4704 # apt install systemd # install systemd 249.5-2ubuntu1 # systemctl restart systemd-sysusers # systemctl status systemd-sysusers # system --status=failed $ lxc profile set default security.privileged "false" A workaround is to disable it via: $ cat /etc/systemd/system/systemd-sysusers.service.d/override.conf: [Service] LoadCredential= Interesting logs: Nov 12 12:09:44 test systemd[1]: systemd-journald.service: Added fd 42 (n/a) to fd store. Nov 12 12:09:44 test systemd[431]: Mounting /dev (MS_REC|MS_SLAVE "")... Nov 12 12:09:44 test systemd[431]: Failed to mount n/a (type n/a) on /dev (MS_REC|MS_SLAVE ""): Permission denied Nov 12 12:09:44 test systemd[430]: (sd-mkdcreds) failed with exit status 1. Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed to set up credentials: Protocol error Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed at step CREDENTIALS spawning To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1950787/+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 1950787] Re: systemd-sysusers cannot mount /dev in privileged containers (to pass credentials)
If this only fails in privileged containers, then I probably wouldn't worry about it too much, those aren't the default and a LOT of things break in privileged containers, so I don't think it's worth doing distro changes to accommodate this, assuming the container otherwise still boots. For cases like this one, it's usually been hard to make a solid case for a change of behavior in upstream systemd. There are a few places like the devices cgroup where permission errors are considered non-fatal which then accommodates containers quite well, but the same isn't true with the isolation security features which this one ties into. In an ideal world, AppArmor would allow us to craft a policy which: - Allows for mount namespaces - Allows for bind-mounts of restricted paths - Applies the parent's policy onto the bind-mount target - Properly support mount propagation flags in a way that can't be abuse to allow all mounts But as it stands, AppArmor is entirely path based, so a policy that applies to /proc will not apply to /proc bind-mount to /blah/proc (which is effectively what systemd does) and so causes all confinement to be bypassable. Additionally, there are (or were in some versions at least) issues with processing those mount propagation flags you see in your log (shared/slave/...) and allowing a bind-mount to be marked using one of those flags would incorrectly cause the parser or the kernel (not quite sure which) to allow ALL mounts... -- 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/1950787 Title: systemd-sysusers cannot mount /dev in privileged containers (to pass credentials) Status in lxd package in Ubuntu: Invalid Status in systemd package in Ubuntu: New Bug description: systemd-sysusers.service/systemd.exec fails to start in privileged containers, due to being unable to properly mount /dev for passing credentials, caused by the following config in the .service unit: ``` # Optionally, pick up a root password and shell for the root user from a # credential passed to the service manager. This is useful for importing this # data from nspawn's --set-credential= switch. LoadCredential=passwd.hashed-password.root LoadCredential=passwd.plaintext-password.root LoadCredential=passwd.shell.root ``` Reproducer: $ lxc profile set default security.privileged "true" $ lxc launch ubuntu-daily:jammy test $ lxc exec test bash # add-apt-repository ppa:ci-train-ppa-service/4704 # apt install systemd # install systemd 249.5-2ubuntu1 # systemctl restart systemd-sysusers # systemctl status systemd-sysusers # system --status=failed $ lxc profile set default security.privileged "false" A workaround is to disable it via: $ cat /etc/systemd/system/systemd-sysusers.service.d/override.conf: [Service] LoadCredential= Interesting logs: Nov 12 12:09:44 test systemd[1]: systemd-journald.service: Added fd 42 (n/a) to fd store. Nov 12 12:09:44 test systemd[431]: Mounting /dev (MS_REC|MS_SLAVE "")... Nov 12 12:09:44 test systemd[431]: Failed to mount n/a (type n/a) on /dev (MS_REC|MS_SLAVE ""): Permission denied Nov 12 12:09:44 test systemd[430]: (sd-mkdcreds) failed with exit status 1. Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed to set up credentials: Protocol error Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed at step CREDENTIALS spawning To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1950787/+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 1950787] Re: systemd-sysusers cannot mount /dev in privileged containers (to pass credentials)
Privileged containers have a much stricter apparmor policy applied than unprivileged containers. That's because unprivileged containers primarily rely on the user namespace to prevent breakout and taking over of the host whereas privileged containers rely entirely on apparmor. As apparmor isn't particularly good at dealing with mounts, especially with mount namespaces, there is no safe way for us to allow this operation in privileged containers. As you point out above, we've recently started using a systemd generator to dynamically generate unit overrides based on the environment, letting us disable specific features that interfere with container security. This is used in all of the community images, so in this case you could try it by using "images:ubuntu/jammy" instead of "ubuntu-daily:jammy". We've been considering getting the generator into the lxd-agent-loader package which is included in all Ubuntu images though so far we've found it to be too volatile for that (we were updating it up to twice a week for a while...). -- 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/1950787 Title: systemd-sysusers cannot mount /dev in privileged containers (to pass credentials) Status in lxd package in Ubuntu: Invalid Status in systemd package in Ubuntu: New Bug description: systemd-sysusers.service/systemd.exec fails to start in privileged containers, due to being unable to properly mount /dev for passing credentials, caused by the following config in the .service unit: ``` # Optionally, pick up a root password and shell for the root user from a # credential passed to the service manager. This is useful for importing this # data from nspawn's --set-credential= switch. LoadCredential=passwd.hashed-password.root LoadCredential=passwd.plaintext-password.root LoadCredential=passwd.shell.root ``` Reproducer: $ lxc profile set default security.privileged "true" $ lxc launch ubuntu-daily:jammy test $ lxc exec test bash # add-apt-repository ppa:ci-train-ppa-service/4704 # apt install systemd # install systemd 249.5-2ubuntu1 # systemctl restart systemd-sysusers # systemctl status systemd-sysusers # system --status=failed $ lxc profile set default security.privileged "false" A workaround is to disable it via: $ cat /etc/systemd/system/systemd-sysusers.service.d/override.conf: [Service] LoadCredential= Interesting logs: Nov 12 12:09:44 test systemd[1]: systemd-journald.service: Added fd 42 (n/a) to fd store. Nov 12 12:09:44 test systemd[431]: Mounting /dev (MS_REC|MS_SLAVE "")... Nov 12 12:09:44 test systemd[431]: Failed to mount n/a (type n/a) on /dev (MS_REC|MS_SLAVE ""): Permission denied Nov 12 12:09:44 test systemd[430]: (sd-mkdcreds) failed with exit status 1. Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed to set up credentials: Protocol error Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed at step CREDENTIALS spawning To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1950787/+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 1937945] Re: old gpg keyserver no longer works
** 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/1937945
Title:
old gpg keyserver no longer works
Status in lxc package in Ubuntu:
Fix Released
Bug description:
This is with lxc 1:4.0.6-0ubuntu1~20.04.1 on Ubuntu 20.04 LTS.
All lxc-create commands that need to download GPG keys fail with
something similar to:
$ lxc-create -n foobar -t download -- -d ubuntu -r focal -a amd64
The cached copy has expired, re-downloading...
Setting up the GPG keyring
ERROR: Unable to fetch GPG key from keyserver
lxc-create: foobar: lxccontainer.c: create_run_template: 1616 Failed to
create container from template
It turns out that the GPG keyserver used (pool.sks-keyservers.net) no
longer produces the expected responses. Upstream lxc has a ticket for
this:
https://github.com/lxc/lxc/issues/3894 ('lxc-create fails because
"ERROR: Unable to fetch GPG key from keyserver')
and it was fixed by changing:
DOWNLOAD_KEYSERVER="hkp://pool.sks-keyservers.net"
to:
DOWNLOAD_KEYSERVER="hkp://keyserver.ubuntu.com"
in this commit:
https://github.com/lxc/lxc/commit/f2a5d95d00a55bed27ef9920d67617cc75fecad8
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1937945/+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 1923232] Re: SRU of LXC 4.0.6 to focal (upstream bugfix release)
Hello Serge, or anyone else affected, Accepted lxc into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/lxc/1:4.0.6-0ubuntu1~20.04.1 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-focal. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: lxc (Ubuntu Focal) Status: Triaged => Fix Committed ** Tags added: verification-needed verification-needed-focal -- 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/1923232 Title: SRU of LXC 4.0.6 to focal (upstream bugfix release) Status in lxc package in Ubuntu: Fix Released Status in lxc source package in Focal: Fix Committed Bug description: LXC released 4.0.6 as a bugfix release with the following changelog: - Improve handling for compatibility architectures for seccomp - Harden seccomp notifier implementation - Rework parsing of /proc//mountinfo to handle kernel regression - Improve network device restoration - Significantly cleanup and harden config file parsing - Support new capabilities CAP_PERFORM, CAP_BPF, and CAP_CHECKPOINT_RESTORE - Harden containers started without CAP_NET_ADMIN * New upstream bugfix release (4.0.5): - Support allocating PTS devices from within the container - Harden more path/mount handling logics - Rework LSM logic to limit initializer use * Cherry-pick upstream fixes: - 0002-commands-fix-check-for-seccomp-notify-support.patch - 0003-configure-skip-libseccomp-tests-if-it-is-disabled.patch - 0004-conf-fix-containers-retaining-CAP_NET_ADMIN.patch - 0005-cgroups-fix-cgroup-mounting.patch - 0006-lsm-remove-obsolute-comment-about-constructor.patch - 0007-lxc_attach-include-rexec-conditionally.patch - 0008-tree-wide-fix-some-header-inclusions.patch - 0009-initutils-fix-missing-includes.patch - 0010-configure-support-static-binaries.patch - 0011-autotools-enable-static-builds-for-tools.patch - 0012-autotools-enable-static-builds-for-commands.patch - 0013-tree-wide-fix-compilation-with-Wstrict-prototypes-Wo.patch - 0014-config-update-ax_pthread.m4.patch - 0015-configure-add-AC_SYS_LARGEFILE-checking.patch - 0016-autotools-update-build.patch - 0017-file_utils-introduce-read_file_at.patch - 0018-string_utils-add-must_make_path_relative.patch - 0019-cgroups-coding-style-fixes.patch - 0020-cgroups-rework-cg_unified_init.patch - 0021-cgroups-detect-and-record-cgroup2-freezer-support.patch - 0022-criu-handle-cgroup2-freezer.patch - 0023-mkdir-p-proc-sys-on-container-startup.patch - 0024-conf-fix-coding-style.patch - 0025-conf-coding-style-fixes.patch - 0026-conf-move-proc-and-sys-mountpoint-creation-int-lxc_m.patch - 0027-attach-invert-child-parent-handling.patch - 0028-attach-use-__do_free-cleanup-macro-for-cwd.patch - 0029-attach-tweak-logging.patch - 0030-attach-use-__do_close-for-labelfd.patch - 0031-attach-coding-style-fixes.patch - 0032-attach-use-free_disarm.patch - 0033-attach-s-attach_child_main-do_attach-g.patch - 0034-attach-mark-do_attach-as-__noreturn.patch - 0035-attach-make-do_attach-void.patch - 0036-attach-use-close_prot_errno_disarm.patch - 0037-attach-add-some-DEBUG-logging-to-stdfd-dpulication.patch - 0038-cgroups-fix-cgroup-mounting.patch - 0039-utils-fix-mount_at.patch - 0040-configure-fix-static-builds-with-clang-12-and-LTO.patch - 0041-cgroups-bpf-fixes.patch - 0042-croups-improve-__do_bpf_program_free.patch - 0043-cgroups-coding-style-fixes.patch - 0044-cgroups-don-t-initiliaze-NULL-log.patch - 0045-cgroups-ensure-all-memory-is-zeroed.patch - 0046-cgroups-use-zalloc.patch - 0047-cgroups-tweak-cgroup-initialization.patch -
[Touch-packages] [Bug 1923232] Re: SRU of LXC 4.0.6 to focal (upstream bugfix release)
Moving to Triaged, LXC does have a comprehensive autopkgtest test suite which runs both unit and integration tests and is integrated with Ubuntu. ** Changed in: lxc (Ubuntu Focal) Status: Incomplete => Opinion ** Changed in: lxc (Ubuntu Focal) Status: Opinion => Triaged ** Changed in: lxc (Ubuntu) Status: New => 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/1923232 Title: SRU of LXC 4.0.6 to focal (upstream bugfix release) Status in lxc package in Ubuntu: Fix Released Status in lxc source package in Focal: Triaged Bug description: LXC released 4.0.6 as a bugfix release with the following changelog: - Improve handling for compatibility architectures for seccomp - Harden seccomp notifier implementation - Rework parsing of /proc//mountinfo to handle kernel regression - Improve network device restoration - Significantly cleanup and harden config file parsing - Support new capabilities CAP_PERFORM, CAP_BPF, and CAP_CHECKPOINT_RESTORE - Harden containers started without CAP_NET_ADMIN * New upstream bugfix release (4.0.5): - Support allocating PTS devices from within the container - Harden more path/mount handling logics - Rework LSM logic to limit initializer use * Cherry-pick upstream fixes: - 0002-commands-fix-check-for-seccomp-notify-support.patch - 0003-configure-skip-libseccomp-tests-if-it-is-disabled.patch - 0004-conf-fix-containers-retaining-CAP_NET_ADMIN.patch - 0005-cgroups-fix-cgroup-mounting.patch - 0006-lsm-remove-obsolute-comment-about-constructor.patch - 0007-lxc_attach-include-rexec-conditionally.patch - 0008-tree-wide-fix-some-header-inclusions.patch - 0009-initutils-fix-missing-includes.patch - 0010-configure-support-static-binaries.patch - 0011-autotools-enable-static-builds-for-tools.patch - 0012-autotools-enable-static-builds-for-commands.patch - 0013-tree-wide-fix-compilation-with-Wstrict-prototypes-Wo.patch - 0014-config-update-ax_pthread.m4.patch - 0015-configure-add-AC_SYS_LARGEFILE-checking.patch - 0016-autotools-update-build.patch - 0017-file_utils-introduce-read_file_at.patch - 0018-string_utils-add-must_make_path_relative.patch - 0019-cgroups-coding-style-fixes.patch - 0020-cgroups-rework-cg_unified_init.patch - 0021-cgroups-detect-and-record-cgroup2-freezer-support.patch - 0022-criu-handle-cgroup2-freezer.patch - 0023-mkdir-p-proc-sys-on-container-startup.patch - 0024-conf-fix-coding-style.patch - 0025-conf-coding-style-fixes.patch - 0026-conf-move-proc-and-sys-mountpoint-creation-int-lxc_m.patch - 0027-attach-invert-child-parent-handling.patch - 0028-attach-use-__do_free-cleanup-macro-for-cwd.patch - 0029-attach-tweak-logging.patch - 0030-attach-use-__do_close-for-labelfd.patch - 0031-attach-coding-style-fixes.patch - 0032-attach-use-free_disarm.patch - 0033-attach-s-attach_child_main-do_attach-g.patch - 0034-attach-mark-do_attach-as-__noreturn.patch - 0035-attach-make-do_attach-void.patch - 0036-attach-use-close_prot_errno_disarm.patch - 0037-attach-add-some-DEBUG-logging-to-stdfd-dpulication.patch - 0038-cgroups-fix-cgroup-mounting.patch - 0039-utils-fix-mount_at.patch - 0040-configure-fix-static-builds-with-clang-12-and-LTO.patch - 0041-cgroups-bpf-fixes.patch - 0042-croups-improve-__do_bpf_program_free.patch - 0043-cgroups-coding-style-fixes.patch - 0044-cgroups-don-t-initiliaze-NULL-log.patch - 0045-cgroups-ensure-all-memory-is-zeroed.patch - 0046-cgroups-use-zalloc.patch - 0047-cgroups-tweak-cgroup-initialization.patch - 0048-log-remove-pointless-inline.patch - 0049-log-add-lxc_log_get_fd.patch - 0050-seccomp-use-lxc_log_get_fd.patch - 0051-log-rework-lxc_log_get_level.patch - 0052-seccomp-use-lxc_log_get_level.patch - 0053-cgroups-use-bpf-log-when-logging-at-trace-level.patch - 0054-log-add-lxc_log_trace-helper.patch - 0055-cgroups-use-PTR_TO_U64.patch - 0056-cgroups-align-methods.patch - 0057-utils-use-SYSTRACE-when-logging-stdio-permission-fix.patch - 0058-attach-log-failues-to-dup2-with-SYSDEBUG.patch - 0059-attach-fix-logging-for-stdfd-replacement.patch - 0060-attach-fix-error-checking-for-dup2.patch - 0061-cgroups-initialize-variable.patch - 0062-commands_utils-don-t-leak-memory.patch - 0063-conf-use-lxc_log_trace.patch - 0064-confile_utils-use-lxc_log_trace.patch - 0065-rexec-check-lseek-return-value.patch * Cherry-pick upstream bugfix: - cgroups: fix armhf builds * Cherry-pick upstream bugfix: - cgfsng: fix cgroup attach cgroup
[Touch-packages] [Bug 1923232] Re: SRU of LXC 4.0.6 to focal (upstream bugfix release)
https://autopkgtest.ubuntu.com/packages/l/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/1923232 Title: SRU of LXC 4.0.6 to focal (upstream bugfix release) Status in lxc package in Ubuntu: Fix Released Status in lxc source package in Focal: Triaged Bug description: LXC released 4.0.6 as a bugfix release with the following changelog: - Improve handling for compatibility architectures for seccomp - Harden seccomp notifier implementation - Rework parsing of /proc//mountinfo to handle kernel regression - Improve network device restoration - Significantly cleanup and harden config file parsing - Support new capabilities CAP_PERFORM, CAP_BPF, and CAP_CHECKPOINT_RESTORE - Harden containers started without CAP_NET_ADMIN * New upstream bugfix release (4.0.5): - Support allocating PTS devices from within the container - Harden more path/mount handling logics - Rework LSM logic to limit initializer use * Cherry-pick upstream fixes: - 0002-commands-fix-check-for-seccomp-notify-support.patch - 0003-configure-skip-libseccomp-tests-if-it-is-disabled.patch - 0004-conf-fix-containers-retaining-CAP_NET_ADMIN.patch - 0005-cgroups-fix-cgroup-mounting.patch - 0006-lsm-remove-obsolute-comment-about-constructor.patch - 0007-lxc_attach-include-rexec-conditionally.patch - 0008-tree-wide-fix-some-header-inclusions.patch - 0009-initutils-fix-missing-includes.patch - 0010-configure-support-static-binaries.patch - 0011-autotools-enable-static-builds-for-tools.patch - 0012-autotools-enable-static-builds-for-commands.patch - 0013-tree-wide-fix-compilation-with-Wstrict-prototypes-Wo.patch - 0014-config-update-ax_pthread.m4.patch - 0015-configure-add-AC_SYS_LARGEFILE-checking.patch - 0016-autotools-update-build.patch - 0017-file_utils-introduce-read_file_at.patch - 0018-string_utils-add-must_make_path_relative.patch - 0019-cgroups-coding-style-fixes.patch - 0020-cgroups-rework-cg_unified_init.patch - 0021-cgroups-detect-and-record-cgroup2-freezer-support.patch - 0022-criu-handle-cgroup2-freezer.patch - 0023-mkdir-p-proc-sys-on-container-startup.patch - 0024-conf-fix-coding-style.patch - 0025-conf-coding-style-fixes.patch - 0026-conf-move-proc-and-sys-mountpoint-creation-int-lxc_m.patch - 0027-attach-invert-child-parent-handling.patch - 0028-attach-use-__do_free-cleanup-macro-for-cwd.patch - 0029-attach-tweak-logging.patch - 0030-attach-use-__do_close-for-labelfd.patch - 0031-attach-coding-style-fixes.patch - 0032-attach-use-free_disarm.patch - 0033-attach-s-attach_child_main-do_attach-g.patch - 0034-attach-mark-do_attach-as-__noreturn.patch - 0035-attach-make-do_attach-void.patch - 0036-attach-use-close_prot_errno_disarm.patch - 0037-attach-add-some-DEBUG-logging-to-stdfd-dpulication.patch - 0038-cgroups-fix-cgroup-mounting.patch - 0039-utils-fix-mount_at.patch - 0040-configure-fix-static-builds-with-clang-12-and-LTO.patch - 0041-cgroups-bpf-fixes.patch - 0042-croups-improve-__do_bpf_program_free.patch - 0043-cgroups-coding-style-fixes.patch - 0044-cgroups-don-t-initiliaze-NULL-log.patch - 0045-cgroups-ensure-all-memory-is-zeroed.patch - 0046-cgroups-use-zalloc.patch - 0047-cgroups-tweak-cgroup-initialization.patch - 0048-log-remove-pointless-inline.patch - 0049-log-add-lxc_log_get_fd.patch - 0050-seccomp-use-lxc_log_get_fd.patch - 0051-log-rework-lxc_log_get_level.patch - 0052-seccomp-use-lxc_log_get_level.patch - 0053-cgroups-use-bpf-log-when-logging-at-trace-level.patch - 0054-log-add-lxc_log_trace-helper.patch - 0055-cgroups-use-PTR_TO_U64.patch - 0056-cgroups-align-methods.patch - 0057-utils-use-SYSTRACE-when-logging-stdio-permission-fix.patch - 0058-attach-log-failues-to-dup2-with-SYSDEBUG.patch - 0059-attach-fix-logging-for-stdfd-replacement.patch - 0060-attach-fix-error-checking-for-dup2.patch - 0061-cgroups-initialize-variable.patch - 0062-commands_utils-don-t-leak-memory.patch - 0063-conf-use-lxc_log_trace.patch - 0064-confile_utils-use-lxc_log_trace.patch - 0065-rexec-check-lseek-return-value.patch * Cherry-pick upstream bugfix: - cgroups: fix armhf builds * Cherry-pick upstream bugfix: - cgfsng: fix cgroup attach cgroup creation * New upstream bugfix release (4.0.4): - Support for new Linux clone flags (clone into cgroup) - Support for new Linux VFS system calls - Internal symbols are now properly hidden from external consumers * New upstream bugfix release (4.0.3): - Improvement to
[Touch-packages] [Bug 1914062] Re: NetworkManager-wait-online.service in 1.28.0-2ubuntu1 fails to start in LXC
Christian submitted https://github.com/systemd/systemd/pull/18559 which got turned into https://github.com/systemd/systemd/pull/18684 and has now been merged in upstream systemd. We've both tested the resulting systemd and can confirm that /run/udev is now properly populated. Please cherry-pick those udevd fixes into Ubuntu's systemd. ** Changed in: systemd (Ubuntu) Assignee: Christian Brauner (cbrauner) => (unassigned) ** Changed in: systemd (Ubuntu) Status: Fix Released => Triaged ** Changed in: systemd (Ubuntu) Importance: Wishlist => High -- 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/1914062 Title: NetworkManager-wait-online.service in 1.28.0-2ubuntu1 fails to start in LXC Status in lxd package in Ubuntu: Won't Fix Status in network-manager package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Triaged Bug description: This regresses systemd's autopkgtest because it expects the system in the container to reach running state, but the system ends up in degraded state due to the service failing. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/s/systemd/20210112_185712_ff570@/log.gz ... == FAIL: test_no_failed (__main__.ServicesTest) No failed units -- Traceback (most recent call last): File "/tmp/autopkgtest.fFC3Lw/build.xLc/real-tree/debian/tests/boot-and-services", line 68, in test_no_failed self.assertEqual(failed, []) AssertionError: Lists differ: ['● NetworkManager-wait-online.service loa[42 chars]ine'] != [] First list contains 1 additional elements. First extra element 0: '● NetworkManager-wait-online.service loaded failed failed Network Manager Wait Online' + [] - ['● NetworkManager-wait-online.service loaded failed failed Network Manager ' - 'Wait Online'] -- Ran 23 tests in 4.435s ... Reproducible locally by installing n-m from -proposed, then restarting the system in the LXC container. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1914062/+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 1914062] Re: NetworkManager-wait-online.service in 1.28.0-2ubuntu1 fails to start in LXC
** Changed in: systemd (Ubuntu) Assignee: Ubuntu containers team (ubuntu-lxc) => Christian Brauner (cbrauner) -- 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/1914062 Title: NetworkManager-wait-online.service in 1.28.0-2ubuntu1 fails to start in LXC Status in lxd package in Ubuntu: Won't Fix Status in network-manager package in Ubuntu: Invalid Status in systemd package in Ubuntu: Triaged Bug description: This regresses systemd's autopkgtest because it expects the system in the container to reach running state, but the system ends up in degraded state due to the service failing. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/s/systemd/20210112_185712_ff570@/log.gz ... == FAIL: test_no_failed (__main__.ServicesTest) No failed units -- Traceback (most recent call last): File "/tmp/autopkgtest.fFC3Lw/build.xLc/real-tree/debian/tests/boot-and-services", line 68, in test_no_failed self.assertEqual(failed, []) AssertionError: Lists differ: ['● NetworkManager-wait-online.service loa[42 chars]ine'] != [] First list contains 1 additional elements. First extra element 0: '● NetworkManager-wait-online.service loaded failed failed Network Manager Wait Online' + [] - ['● NetworkManager-wait-online.service loaded failed failed Network Manager ' - 'Wait Online'] -- Ran 23 tests in 4.435s ... Reproducible locally by installing n-m from -proposed, then restarting the system in the LXC container. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1914062/+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 1914062] Re: NetworkManager-wait-online.service in 1.28.0-2ubuntu1 fails to start in LXC
** Changed in: network-manager (Ubuntu) Status: New => Invalid ** Changed in: systemd (Ubuntu) Assignee: (unassigned) => Ubuntu containers team (ubuntu-lxc) -- 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/1914062 Title: NetworkManager-wait-online.service in 1.28.0-2ubuntu1 fails to start in LXC Status in lxd package in Ubuntu: Won't Fix Status in network-manager package in Ubuntu: Invalid Status in systemd package in Ubuntu: Triaged Bug description: This regresses systemd's autopkgtest because it expects the system in the container to reach running state, but the system ends up in degraded state due to the service failing. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/s/systemd/20210112_185712_ff570@/log.gz ... == FAIL: test_no_failed (__main__.ServicesTest) No failed units -- Traceback (most recent call last): File "/tmp/autopkgtest.fFC3Lw/build.xLc/real-tree/debian/tests/boot-and-services", line 68, in test_no_failed self.assertEqual(failed, []) AssertionError: Lists differ: ['● NetworkManager-wait-online.service loa[42 chars]ine'] != [] First list contains 1 additional elements. First extra element 0: '● NetworkManager-wait-online.service loaded failed failed Network Manager Wait Online' + [] - ['● NetworkManager-wait-online.service loaded failed failed Network Manager ' - 'Wait Online'] -- Ran 23 tests in 4.435s ... Reproducible locally by installing n-m from -proposed, then restarting the system in the LXC container. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1914062/+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 1914062] Re: NetworkManager-wait-online.service in 1.28.0-2ubuntu1 fails to start in LXC
This is a systemd/udev bug. We're aware of the CONTAINER_INTERFACE and it being wrong doesn't mean we need to change LXD to make it similarly wrong. LXD containers need to have udevd running to function properly, so you'll need to undo that change. If there is a bug in how udevd now behaves, that's what needs to be fixed and we can assist you with that. ** Changed in: lxd (Ubuntu) Status: New => Won't Fix -- 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/1914062 Title: NetworkManager-wait-online.service in 1.28.0-2ubuntu1 fails to start in LXC Status in lxd package in Ubuntu: Won't Fix Status in network-manager package in Ubuntu: New Status in systemd package in Ubuntu: Triaged Bug description: This regresses systemd's autopkgtest because it expects the system in the container to reach running state, but the system ends up in degraded state due to the service failing. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/s/systemd/20210112_185712_ff570@/log.gz ... == FAIL: test_no_failed (__main__.ServicesTest) No failed units -- Traceback (most recent call last): File "/tmp/autopkgtest.fFC3Lw/build.xLc/real-tree/debian/tests/boot-and-services", line 68, in test_no_failed self.assertEqual(failed, []) AssertionError: Lists differ: ['● NetworkManager-wait-online.service loa[42 chars]ine'] != [] First list contains 1 additional elements. First extra element 0: '● NetworkManager-wait-online.service loaded failed failed Network Manager Wait Online' + [] - ['● NetworkManager-wait-online.service loaded failed failed Network Manager ' - 'Wait Online'] -- Ran 23 tests in 4.435s ... Reproducible locally by installing n-m from -proposed, then restarting the system in the LXC container. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1914062/+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 1914062] Re: NetworkManager-wait-online.service in 1.28.0-2ubuntu1 fails to start in LXC
Making /sys read-only will break very very many things that we have no intention of breaking. LXD is also completely init system agnostic and we have no idea what the init system in a particular container may be. ** Changed in: lxd (Ubuntu) Status: New => 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/1914062 Title: NetworkManager-wait-online.service in 1.28.0-2ubuntu1 fails to start in LXC Status in lxd package in Ubuntu: Invalid Status in network-manager package in Ubuntu: New Status in systemd package in Ubuntu: Triaged Bug description: This regresses systemd's autopkgtest because it expects the system in the container to reach running state, but the system ends up in degraded state due to the service failing. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/s/systemd/20210112_185712_ff570@/log.gz ... == FAIL: test_no_failed (__main__.ServicesTest) No failed units -- Traceback (most recent call last): File "/tmp/autopkgtest.fFC3Lw/build.xLc/real-tree/debian/tests/boot-and-services", line 68, in test_no_failed self.assertEqual(failed, []) AssertionError: Lists differ: ['● NetworkManager-wait-online.service loa[42 chars]ine'] != [] First list contains 1 additional elements. First extra element 0: '● NetworkManager-wait-online.service loaded failed failed Network Manager Wait Online' + [] - ['● NetworkManager-wait-online.service loaded failed failed Network Manager ' - 'Wait Online'] -- Ran 23 tests in 4.435s ... Reproducible locally by installing n-m from -proposed, then restarting the system in the LXC container. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1914062/+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 1915091] Re: Nautilus shows LXD storage pool in sidebar
Ok, so the mount table output confirms that your LXD default storage pool isn't visible in the host's mount table, so that's not what's triggering nautilus. Also, if that was the case, I'd have seen it on my own machine a long time ago ;) My best guess is that it's the loop device (also called default.img) which nautilus is incorrectly showing as some kind of external block device (like a USB stick or SD card). You'll most likely see it in `losetup -a` and it may show up in some `/dev/disk/` sub-directories which I supposed nautilus or something in the gnome desktop is monitoring. Unfortunately unlike actual mount entries that we can hide in a different mount namespace or pass custom mount flags to have the desktop ignore, the same can't be done with block devices, so re-assigning this to nautilus for further investigation. ** Package changed: lxc (Ubuntu) => nautilus (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/1915091 Title: Nautilus shows LXD storage pool in sidebar Status in nautilus package in Ubuntu: Incomplete Bug description: I recently set up LXD 4.11 on Ubuntu 20.04 with a file-backed btrfs storage pool called "default". Now Nautilus shows a "default" device in the sidebar despite the loop device not being intended for users to directly interact with. System: Ubuntu 20.04.2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1915091/+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 1915091] Re: Nautilus shows LXD storage pool in sidebar
Can you show `cat /proc/self/mountinfo` on your 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/1915091 Title: Nautilus shows LXD storage pool in sidebar Status in lxc package in Ubuntu: New Bug description: I recently set up LXD 4.11 on Ubuntu 20.04 with a file-backed btrfs storage pool called "default". Now Nautilus shows a "default" device in the sidebar despite the loop device not being intended for users to directly interact with. System: Ubuntu 20.04.2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1915091/+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 1915091] Re: Nautilus shows LXD storage pool in sidebar
Hmm, LXD's mounts are in a separate mount namespace invisible from the host, so I don't quite get how this is possible ;) -- 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/1915091 Title: Nautilus shows LXD storage pool in sidebar Status in lxc package in Ubuntu: New Bug description: I recently set up LXD 4.11 on Ubuntu 20.04 with a file-backed btrfs storage pool called "default". Now Nautilus shows a "default" device in the sidebar despite the loop device not being intended for users to directly interact with. System: Ubuntu 20.04.2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1915091/+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 1905245] Re: "Failed to parse bus message: Invalid argument" with Linux 5.8
Now that we have the 5.8 kernel in HWE for focal, all my servers are hitting this, both on metal and in containers. This causes things like "systemctl show" to show an error as well as partial data. It really feels like this should have been fixed before the rollout of the 5.8 kernel through HWE... -- 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/1905245 Title: "Failed to parse bus message: Invalid argument" with Linux 5.8 Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: In Progress Status in systemd source package in Focal: In Progress Bug description: [impact] newer kernels introduced a new capability, and existing systemd doesn't have the name mapping for the new cap (since the mapping table is generated at systemd compile time), so it fails when trying to map the capability to a user-facing name, which causes failure when running commands like 'systemctl show' [test case] install a focal system, and install the 5.8 (or newer) kernel, e.g. from linux-generic-hwe-20.04-edge, and reboot into the new kernel. Find any service that does not specify its CapabilityBoundingSet; e.g. 'apparmor', and run systemctl show on it: ubuntu@lp1905245-f:~$ systemctl show -p CapabilityBoundingSet apparmor Failed to parse bus message: Invalid argument the command should correctly show the value, e.g.: $ systemctl show -p CapabilityBoundingSet apparmor CapabilityBoundingSet=cap_chown cap_dac_override ...etc... [regression potential] a regression would likely occur while systemd is parsing or printing or otherwise handling kernel capabilities. A regression could happen when running systemd commands, such as systemctl, or when pid1 is managing services. [scope] this is needed only in focal (and possibly bionic). This is fixed upstream by PR 16424: https://github.com/systemd/systemd/pull/16424 which was first included in v246, so this is already fixed in groovy and later. this was introduced externally from systemd, with the new capability in the kernel, so this fix technically is needed in x/b/f. However, x is unlikely to get a new kernel capability during the rest of its life cycle. For b, unless a kernel is added that includes a new capability, this patch is not needed. [other info] there is a testcase-only related bug 1905044 [original description] When I run `systemctl show myservice.service`, I get the following error message: Failed to parse bus message: Invalid argument systemd version: 245.4-4ubuntu3.3 linux version: 5.8.0-29-generic #31~20.04.1-Ubuntu (From linux-generic-hwe-20.04-edge) This is a bug that has been fixed in Debian. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964926 Please can we port the fix to the ubuntu 20.04 version. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1905245/+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 1891903] Re: "File exists" error while starting container
The cpuset "error" is normal, it just means the directory was already there and is getting recycled. The boot_id permission problem has already been fixed upstream. ** 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/1891903 Title: "File exists" error while starting container Status in lxc package in Ubuntu: Fix Committed Bug description: On a freshly installed Ubuntu 20.04.1 VM, while starting a container created using sudo lxc-create -t ubuntu -n testlxc the following messages are shown: lxc-start: testlxc: cgroups/cgfsng.c: mkdir_eexist_on_last: 1143 File exists - Failed to create directory "/sys/fs/cgroup/cpuset//lxc.monitor.testlxc" lxc-start: testlxc: conf.c: lxc_setup_boot_id: 3249 Permission denied - Failed to mount /dev/.lxc-boot-id to /proc/sys/kernel/random/boot_id The container starts correctly but it would be nice find out why those errors are being issued. lxc-checkconfig output follows: Kernel configuration not found at /proc/config.gz; searching... Kernel configuration found at /boot/config-5.4.0-42-generic --- Namespaces --- Namespaces: enabled Utsname namespace: enabled Ipc namespace: enabled Pid namespace: enabled User namespace: enabled Network namespace: enabled --- Control groups --- Cgroups: enabled Cgroup v1 mount points: /sys/fs/cgroup/systemd /sys/fs/cgroup/hugetlb /sys/fs/cgroup/cpuset /sys/fs/cgroup/memory /sys/fs/cgroup/cpu,cpuacct /sys/fs/cgroup/net_cls,net_prio /sys/fs/cgroup/blkio /sys/fs/cgroup/perf_event /sys/fs/cgroup/pids /sys/fs/cgroup/freezer /sys/fs/cgroup/devices /sys/fs/cgroup/rdma Cgroup v2 mount points: /sys/fs/cgroup/unified Cgroup v1 clone_children flag: enabled Cgroup device: enabled Cgroup sched: enabled Cgroup cpu account: enabled Cgroup memory controller: enabled Cgroup cpuset: enabled --- Misc --- Veth pair device: enabled, loaded Macvlan: enabled, not loaded Vlan: enabled, not loaded Bridges: enabled, loaded Advanced netfilter: enabled, not loaded CONFIG_NF_NAT_IPV4: missing CONFIG_NF_NAT_IPV6: missing CONFIG_IP_NF_TARGET_MASQUERADE: enabled, not loaded CONFIG_IP6_NF_TARGET_MASQUERADE: enabled, not loaded CONFIG_NETFILTER_XT_TARGET_CHECKSUM: enabled, loaded CONFIG_NETFILTER_XT_MATCH_COMMENT: enabled, not loaded FUSE (for use with lxcfs): enabled, not loaded --- Checkpoint/Restore --- checkpoint restore: enabled CONFIG_FHANDLE: enabled CONFIG_EVENTFD: enabled CONFIG_EPOLL: enabled CONFIG_UNIX_DIAG: enabled CONFIG_INET_DIAG: enabled CONFIG_PACKET_DIAG: enabled CONFIG_NETLINK_DIAG: enabled File capabilities: Note : Before booting a new kernel, you can check its configuration usage : CONFIG=/path/to/config /usr/bin/lxc-checkconfig To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1891903/+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) 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/1888705 Title: lxc ftbfs against libselinux 3.1 Status in lxc package in Ubuntu: New 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 1868456] Re: "sudo: setrlimit(RLIMIT_CORE): Operation not permitted" error when using sudo in 20.04 LXD container
We'll want that sudo fix included in Ubuntu. It's the usual catch with unprivileged containers only being able to lower their limits and never raise them so there's nothing we can really do about it in LXD. ** Changed in: lxd (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sudo in Ubuntu. https://bugs.launchpad.net/bugs/1868456 Title: "sudo: setrlimit(RLIMIT_CORE): Operation not permitted" error when using sudo in 20.04 LXD container Status in lxd package in Ubuntu: Invalid Status in sudo package in Ubuntu: Confirmed Bug description: I fired up a LXD container using ubuntu-daily:f on my machine and every time I issue a comment inside the container using sudo, I get this error: sudo: setrlimit(RLIMIT_CORE): Operation not permitted I did some digging online and found this was reported against Fedora last fall which lead me to this bugzilla report: https://bugzilla.redhat.com/show_bug.cgi?id=1773148 which seems to tie this to a change in sudo between 1.8.28 and 1.8.29. Focal has 1.8.31: bladernr@focal-builder:~/development/kernels-ubuntu/focal$ apt-cache policy sudo sudo: Installed: 1.8.31-1ubuntu1 Candidate: 1.8.31-1ubuntu1 Version table: *** 1.8.31-1ubuntu1 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status This is not an issue on Bionic: bladernr@galactica:~/development/kernels-upstream/mainline$ apt-cache policy sudo sudo: Installed: 1.8.21p2-3ubuntu1.2 Candidate: 1.8.21p2-3ubuntu1.2 Version table: *** 1.8.21p2-3ubuntu1.2 500 500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages 100 /var/lib/dpkg/status 1.8.21p2-3ubuntu1 500 500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages From the redhat bug, the described workaround does clear these messages up: # set disable_coredump false Once I've done that, the error messages go away. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1868456/+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: 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/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: New 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 1835660] Re: initramfs unpacking failed
All LXD virtual machines are hitting this too. Run: - lxc launch images:ubuntu/focal/cloud f1 && lxc console f1 And you'll see it show that message. As mentioned above, boot then still goes ahead and you get a login prompt, but as that may not always be the case. For example in linux-kvm, that fallback mechanism doesn't appear to work and we instead get a kernel panic unless we've manually modified the initrd to be gzip: https://bugs.launchpad.net/cloud-images/+bug/1873809 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1835660 Title: initramfs unpacking failed Status in initramfs-tools package in Ubuntu: Invalid Status in linux package in Ubuntu: Confirmed Bug description: "initramfs unpacking failed: Decoding failed", message appears on boot up. If I "update-initramfs" using gzip instead of lz, then boot up passes without decoding failed message. --- However, we currently believe that the decoding error reported in dmesg is actually harmless and has no impact on usability on the system. Switching from lz4 to gzip compression, simply papers over the warning, without any benefits, and slows down boot. Kernel should be fixed to correctly parse lz4 compressed initrds, or at least lower the warning, to not be user visible as an error. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+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 1883041] Re: libpam-cgfs fails to create freezer cgroup writable by user
How are you logging in and can you confirm that this path does hit libpam_cgfs? Also look in /var/log/auth.log for potential errors. -- 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/1883041 Title: libpam-cgfs fails to create freezer cgroup writable by user Status in lxc package in Ubuntu: New Bug description: This is on 16.04.6. It appears that on some systems, libpam-cgfs doesn't set the correct cgroup information, which prevents containers from starting. This can be seen by looking at the contents of /proc/self/cgroup, which in my case was: blkio:/user.slice cpu,cpuacct:/user.slice cpuset:/ devices:/user.slice freezer:/ hugetlb:/ memory:/user.slice name=systemd:/user.slice/user-18160.slice/session-12214.scope net_cls,net_prio:/ perf_event:/ pids:/user.slice/user-18160.slice whereas it should have instead of freezer:/ freezer:/user//0 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1883041/+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 1668049] Re: lxd cannot shutdown container
** Changed in: systemd (Ubuntu) Status: New => Fix Released -- 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: Fix Released 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 11:19:12 D-wan-61-1 systemd-remount-fs[44]: mount: can't find
[Touch-packages] [Bug 1734410] Re: systemd: handle undelegated cgroup2 hierarchy
There is no /sys/fs/cgroup/unified on xenial, closing. ** Changed in: systemd (Ubuntu Xenial) Status: Incomplete => 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/1734410 Title: systemd: handle undelegated cgroup2 hierarchy Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Invalid 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 1645037] Re: apparmor_parser hangs indefinitely when called by multiple threads
** No longer affects: apparmor (Ubuntu)
** No longer affects: linux (Ubuntu Xenial)
--
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 linux package in Ubuntu:
Fix Released
Status in linux source package in Yakkety:
Won't Fix
Status in linux source package in Zesty:
Fix Released
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/linux/+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 1668049] Re: lxd cannot shutdown container
Is this still an issue? -- 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 11:19:12 D-wan-61-1 systemd-remount-fs[44]: mount: can't find LABEL=cloudimg-rootfs Feb 26 11:19:12 D-wan-61-1
[Touch-packages] [Bug 1555760] Re: Too many levels of symbolic links /proc/sys/fs/binfmt_misc
I've not seen this issue in quite a long time at least on bionic/focal, so will tentatively mark it as fix released. If someone still hits this, please tell us on what release and we'll add some SRU tasks. ** Changed in: binfmt-support (Ubuntu) Status: Confirmed => Fix Released ** Changed in: systemd (Ubuntu) Status: Incomplete => Fix Released -- 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/1555760 Title: Too many levels of symbolic links /proc/sys/fs/binfmt_misc Status in binfmt-support package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Bug description: At first I thought this was an LXD issue, but it turns out the issue is in systemd https://github.com/lxc/lxd/issues/1727#issuecomment-194416558 ls -l /proc/sys/fs/binfmt_misc fails with error: Too many levels of symbolic links I restarted binfmt manually by running: sudo /usr/sbin/update-binfmts --disable sudo /usr/sbin/update-binfmts --enable I think using systemd to do this would have also worked: sudo service binfmt-support restart To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/binfmt-support/+bug/1555760/+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 1634199] Re: In 16.10, LXD won't work with enforced dsnmasq profile
** Changed in: apparmor (Ubuntu) Status: New => Fix Released -- 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/1634199 Title: In 16.10, LXD won't work with enforced dsnmasq profile Status in AppArmor: Fix Released Status in apparmor package in Ubuntu: Fix Released Bug description: After upgrading to 16.0, LXD networking stopped working due to enforced dnsmasq profile. audit: type=1400 audit(1476709813.572:4291): apparmor="DENIED" operation="truncate" profile="/usr/sbin/dnsmasq" name="/var/lib/lxd/networks/lxdbr0/dnsmasq.leases" pid=13540 comm="dnsmasq" requested_mask="w" denied_mask="w" fsuid=0 ouid=0 To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1634199/+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 1519499] Re: Shutdown failure: Assertion 'sd_id128_randomize() >= 0' failed at ../src/core/dbus.c:657, function bus_on_connection(). Aborting.
** Changed in: systemd (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 systemd in Ubuntu. https://bugs.launchpad.net/bugs/1519499 Title: Shutdown failure: Assertion 'sd_id128_randomize() >= 0' failed at ../src/core/dbus.c:657, function bus_on_connection(). Aborting. Status in systemd package in Ubuntu: Fix Released Bug description: This is a follow-up on this issue here: https://github.com/lxc/lxd/issues/1336 I cannot stop a LXD container gently and as it seems the issue lies within ubuntu/systemd which does not handle SIGPWR correctly. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1519499/+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 1648143] Re: tor in lxd: apparmor="DENIED" operation="change_onexec" namespace="root//CONTAINERNAME_" profile="unconfined" name="system_tor"
** Changed in: apparmor (Ubuntu) Status: Confirmed => Invalid ** No longer affects: apparmor (Ubuntu Xenial) ** No longer affects: apparmor (Ubuntu Yakkety) -- 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/1648143 Title: tor in lxd: apparmor="DENIED" operation="change_onexec" namespace="root//CONTAINERNAME_" profile="unconfined" name="system_tor" Status in apparmor package in Ubuntu: Invalid Status in linux package in Ubuntu: Fix Released Status in tor package in Ubuntu: Invalid Status in linux source package in Xenial: Fix Released Status in tor source package in Xenial: Invalid Status in linux source package in Yakkety: Fix Released Status in tor source package in Yakkety: Invalid Bug description: Environment: Distribution: ubuntu Distribution version: 16.10 lxc info: apiextensions: storage_zfs_remove_snapshots container_host_shutdown_timeout container_syscall_filtering auth_pki container_last_used_at etag patch usb_devices https_allowed_credentials image_compression_algorithm directory_manipulation container_cpu_time storage_zfs_use_refquota storage_lvm_mount_options network profile_usedby container_push apistatus: stable apiversion: "1.0" auth: trusted environment: addresses: 163.172.48.149:8443 172.20.10.1:8443 172.20.11.1:8443 172.20.12.1:8443 172.20.22.1:8443 172.20.21.1:8443 10.8.0.1:8443 architectures: x86_64 i686 certificate: | -BEGIN CERTIFICATE- -END CERTIFICATE- certificatefingerprint: 3048baa9f20d316f60a6c602452b58409a6d9e2c3218897e8de7c7c72af0179b driver: lxc driverversion: 2.0.5 kernel: Linux kernelarchitecture: x86_64 kernelversion: 4.8.0-27-generic server: lxd serverpid: 32694 serverversion: 2.4.1 storage: btrfs storageversion: 4.7.3 config: core.https_address: '[::]:8443' core.trust_password: true Container: ubuntu 16.10 Issue description -- tor can't start in a non privileged container Logs from the container: - Dec 7 15:03:00 anonymous tor[302]: Configuration was valid Dec 7 15:03:00 anonymous systemd[303]: tor@default.service: Failed at step APPARMOR spawning /usr/bin/tor: No such file or directory Dec 7 15:03:00 anonymous systemd[1]: tor@default.service: Main process exited, code=exited, status=231/APPARMOR Dec 7 15:03:00 anonymous systemd[1]: Failed to start Anonymizing overlay network for TCP. Dec 7 15:03:00 anonymous systemd[1]: tor@default.service: Unit entered failed state. Dec 7 15:03:00 anonymous systemd[1]: tor@default.service: Failed with result 'exit-code'. Dec 7 15:03:00 anonymous systemd[1]: tor@default.service: Service hold-off time over, scheduling restart. Dec 7 15:03:00 anonymous systemd[1]: Stopped Anonymizing overlay network for TCP. Dec 7 15:03:00 anonymous systemd[1]: tor@default.service: Failed to reset devices.list: Operation not permitted Dec 7 15:03:00 anonymous systemd[1]: Failed to set devices.allow on /system.slice/system-tor.slice/tor@default.service: Operation not permitted Dec 7 15:03:00 anonymous systemd[1]: message repeated 6 times: [ Failed to set devices.allow on /system.slice/system-tor.slice/tor@default.service: Operation not permitted] Dec 7 15:03:00 anonymous systemd[1]: Couldn't stat device /run/systemd/inaccessible/chr Dec 7 15:03:00 anonymous systemd[1]: Couldn't stat device /run/systemd/inaccessible/blk Dec 7 15:03:00 anonymous systemd[1]: Failed to set devices.allow on /system.slice/system-tor.slice/tor@default.service: Operation not permitted Logs from the host audit: type=1400 audit(1481119378.856:6950): apparmor="DENIED" operation="change_onexec" info="label not found" error=-2 namespace="root//lxd-anonymous_" profile="unconfined" name="system_tor" pid=12164 comm="(tor)" Steps to reproduce - install ubuntu container 16.10 on a ubuntu 16.10 host install tor in the container Launch tor To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1648143/+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 1709536] Re: snapd 2.26.14 on ubuntu-core won't start in containers anymore
** Changed in: layer-snap Status: New => 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/1709536 Title: snapd 2.26.14 on ubuntu-core won't start in containers anymore Status in Snap Layer: Invalid Status in snapd: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Fix Released Status in systemd source package in Artful: Fix Released Bug description: [Impact] Systemd treats a failure to apply the requested Nice value as critical to unit startup. Unprivileged LXD containers do not allow the use of negative nice values. snapd will fail to start inside containers now that snapd uses a negative Nice value. Aug 09 05:54:37 core systemd[1]: snapd.service: Main process exited, code=exited, status=201/NICE Aug 09 05:54:37 core systemd[1]: snapd.service: Unit entered failed state. Aug 09 05:54:37 core systemd[1]: snapd.service: Failed with result 'exit-code'. The fix is for systemd to ignore permission errors when attempting to setup such custom nice values in containers. I have confirmed that setting up a unit override by hand which sets Nice = 0 does resolve the problem. [Test Case] Boot a Xenial image in lxd: $ lxc launch xenial x1 $ lxc exec x1 -- systemctl --state=failed Observe failures for snapd : ● snapd.service loaded failed failed Snappy daemon ● snapd.socket loaded failed failed Socket activation for snapp Install updated systemd from -proposed and get status: (lxc exec reboot; lxc exec systemctl status) State: running Jobs: 0 queued Failed: 0 units [Regression Potential] Services will now run with a Nice value other than what was specified in the unit if it cannot be changed for some reason. To manage notifications about this bug go to: https://bugs.launchpad.net/layer-snap/+bug/1709536/+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 1876475] Re: lxc can't assign ipv4 address from lxc-container config file
Yes, different versions of different distros will have different behavior as to what they do with pre-existing network config. Point is, it's racy and unreliable, the only way to get guaranteed behavior is to make sure that nothing else attempts to manage the network when you've already pre-configured it. -- 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/1876475 Title: lxc can't assign ipv4 address from lxc-container config file Status in lxc package in Ubuntu: Invalid Bug description: I created and ran lxc-container with network config - others lxc-config on host system are the same like that (ipv4. addresses is different): __ # Template used to create this container: /usr/share/lxc/templates/lxc-ubuntu # Parameters passed to the template: # For additional config options, please look at lxc.container.conf(5) # Uncomment the following line to support nesting containers: #lxc.include = /usr/share/lxc/config/nesting.conf # (Be aware this has security implications) # Common configuration lxc.include = /usr/share/lxc/config/ubuntu.common.conf lxc.apparmor.profile = unconfined lxc.start.auto = 1 # Container specific configuration lxc.rootfs.path = dir:/var/lib/lxc/video/rootfs lxc.uts.name = video lxc.arch = amd64 # Network configuration lxc.net.0.type = veth lxc.net.0.flags = up lxc.net.0.link = lxcbr0 lxc.net.0.hwaddr = 4a:49:43:49:79:bf lxc.net.0.ipv4.address = 10.0.3.10/24 lxc.net.0.ipv4.gateway = 10.0.3.1 When container started - i can't see ip 10.0.3.10, it is not assigned after start: NAME STATE AUTOSTART GROUPS IPV4 IPV6 UNPRIVILEGED x RUNNING 1 - 10.0.3.2 -false y RUNNING 1 - 10.0.3.3 -false x1 RUNNING 1 - 10.0.3.7 -false x2 RUNNING 1 - 10.0.3.5 -false z3 RUNNING 1 - 10.0.3.4 -false z1 RUNNING 1 - 10.0.3.6 -false video RUNNING 0 - --false <-!!! Example (inside container "z1"): root@z1:/# lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 18.04.3 LTS Release: 18.04 Codename: bionic Example (inside problem container "video"): root@video:/# lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 20.04 LTS Release: 20.04 Codename: focal x,y,x1-3,z3,z1 - ubuntu 18 lts video - Ubuntu 20 LTS, host system ubuntu 20 lts. Host system: root@node:/var/lib/lxc/video# lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 20.04 LTS Release: 20.04 Codename: focal BUT! When I restarts all host-system, "video" container assigns ipv4 address after it. And if I stop the "video" container again (lxc-stop) and start the "video" container again (lxc-start -d -n video) - it losts ipv4 address and can't assign it again (from cli). root@node:/home/alex# dpkg -l | grep lxc ii liblxc-common 1:4.0.2-0ubuntu1 amd64Linux Containers userspace tools (common tools) ii liblxc1 1:4.0.2-0ubuntu1 amd64Linux Containers userspace tools (library) ii lxc 1:4.0.2-0ubuntu1 all Transitional package - lxc -> lxc-utils ii lxc-templates 3.0.4-3ubuntu1 amd64Linux Containers userspace tools (templates) ii lxc-utils 1:4.0.2-0ubuntu1 amd64Linux Containers userspace tools rc lxctl 0.3.1+debian-4 all Utility to manage LXC ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: lxc 1:4.0.2-0ubuntu1 ProcVersionSignature: Ubuntu 5.4.0-28.32-generic 5.4.30 Uname: Linux 5.4.0-28-generic x86_64 ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 CasperMD5CheckResult: skip Date: Sat May 2 18:21:44 2020 PackageArchitecture: all ProcEnviron: SHELL=/bin/bash LANG=en_US.UTF-8 TERM=xterm XDG_RUNTIME_DIR= PATH=(custom, no user) SourcePackage: lxc UpgradeStatus: Upgraded to focal on 2020-05-02 (0 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 lxc.conf: lxc.network.link = lxcbr0 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1876475/+subscriptions -- Mailing list:
[Touch-packages] [Bug 1876475] Re: lxc can't assign ipv4 address from lxc-container config file
LXC always does the same thing, it preconfigures your network namespace. Now if the OS you're running in the container runs its own network configuration tool, that pre-made configuration will likely get reset or mangled. If you want to use those config keys, you need to make sure you're not running software in your container which will reset that pre-made configuration. ** 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/1876475 Title: lxc can't assign ipv4 address from lxc-container config file Status in lxc package in Ubuntu: Invalid Bug description: I created and ran lxc-container with network config - others lxc-config on host system are the same like that (ipv4. addresses is different): __ # Template used to create this container: /usr/share/lxc/templates/lxc-ubuntu # Parameters passed to the template: # For additional config options, please look at lxc.container.conf(5) # Uncomment the following line to support nesting containers: #lxc.include = /usr/share/lxc/config/nesting.conf # (Be aware this has security implications) # Common configuration lxc.include = /usr/share/lxc/config/ubuntu.common.conf lxc.apparmor.profile = unconfined lxc.start.auto = 1 # Container specific configuration lxc.rootfs.path = dir:/var/lib/lxc/video/rootfs lxc.uts.name = video lxc.arch = amd64 # Network configuration lxc.net.0.type = veth lxc.net.0.flags = up lxc.net.0.link = lxcbr0 lxc.net.0.hwaddr = 4a:49:43:49:79:bf lxc.net.0.ipv4.address = 10.0.3.10/24 lxc.net.0.ipv4.gateway = 10.0.3.1 When container started - i can't see ip 10.0.3.10, it is not assigned after start: NAME STATE AUTOSTART GROUPS IPV4 IPV6 UNPRIVILEGED x RUNNING 1 - 10.0.3.2 -false y RUNNING 1 - 10.0.3.3 -false x1 RUNNING 1 - 10.0.3.7 -false x2 RUNNING 1 - 10.0.3.5 -false z3 RUNNING 1 - 10.0.3.4 -false z1 RUNNING 1 - 10.0.3.6 -false video RUNNING 0 - --false <-!!! Example (inside container "z1"): root@z1:/# lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 18.04.3 LTS Release: 18.04 Codename: bionic Example (inside problem container "video"): root@video:/# lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 20.04 LTS Release: 20.04 Codename: focal x,y,x1-3,z3,z1 - ubuntu 18 lts video - Ubuntu 20 LTS, host system ubuntu 20 lts. Host system: root@node:/var/lib/lxc/video# lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 20.04 LTS Release: 20.04 Codename: focal BUT! When I restarts all host-system, "video" container assigns ipv4 address after it. And if I stop the "video" container again (lxc-stop) and start the "video" container again (lxc-start -d -n video) - it losts ipv4 address and can't assign it again (from cli). root@node:/home/alex# dpkg -l | grep lxc ii liblxc-common 1:4.0.2-0ubuntu1 amd64Linux Containers userspace tools (common tools) ii liblxc1 1:4.0.2-0ubuntu1 amd64Linux Containers userspace tools (library) ii lxc 1:4.0.2-0ubuntu1 all Transitional package - lxc -> lxc-utils ii lxc-templates 3.0.4-3ubuntu1 amd64Linux Containers userspace tools (templates) ii lxc-utils 1:4.0.2-0ubuntu1 amd64Linux Containers userspace tools rc lxctl 0.3.1+debian-4 all Utility to manage LXC ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: lxc 1:4.0.2-0ubuntu1 ProcVersionSignature: Ubuntu 5.4.0-28.32-generic 5.4.30 Uname: Linux 5.4.0-28-generic x86_64 ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 CasperMD5CheckResult: skip Date: Sat May 2 18:21:44 2020 PackageArchitecture: all ProcEnviron: SHELL=/bin/bash LANG=en_US.UTF-8 TERM=xterm XDG_RUNTIME_DIR= PATH=(custom, no user) SourcePackage: lxc UpgradeStatus: Upgraded to focal on 2020-05-02 (0 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 lxc.conf: lxc.network.link = lxcbr0 To manage notifications about
[Touch-packages] [Bug 1871487] Re: anon_inode:[eventfd] leaked on vgs invocation inside lxd container
The main leak was in dqlite and has now been included in master, the next rebuild of the snap (likely later today) will include it. ** Changed in: lxd (Ubuntu) Status: Incomplete => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lvm2 in Ubuntu. https://bugs.launchpad.net/bugs/1871487 Title: anon_inode:[eventfd] leaked on vgs invocation inside lxd container Status in lvm2 package in Ubuntu: Invalid Status in lxd package in Ubuntu: Fix Released Bug description: Steps to reproduce: $ lxc launch ubuntu-daily:f reproducer $ lxc shell reproducer $ vgs Expected behaviour: No output (the behaviour on an EC2 instance with no VGs). Actual behaviour: Outputs "File descriptor 25 (anon_inode:[eventfd]) leaked on vgs invocation. Parent PID 283: -bash" ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: lvm2 2.03.07-1ubuntu1 ProcVersionSignature: Ubuntu 5.0.0-1028.29~18.04.1-gcp 5.0.21 Uname: Linux 5.0.0-1028-gcp x86_64 NonfreeKernelModules: lkp_Ubuntu_5_0_0_1028_29_gcp_65 lkp_Ubuntu_5_0_0_1028_29_gcp_64 nf_tables lkp_Ubuntu_5_0_0_1028_29_gcp_63 ebtable_filter ebtables ufs msdos xfs binfmt_misc veth ip6t_MASQUERADE ip6table_nat nf_nat_ipv6 ipt_MASQUERADE xt_CHECKSUM xt_comment xt_tcpudp iptable_nat nf_nat_ipv4 nf_nat iptable_mangle bridge stp llc zfs zunicode zavl icp zcommon znvpair spl ip6table_filter ip6_tables iptable_filter bpfilter nls_iso8859_1 input_leds serio_raw sch_fq_codel ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq raid1 raid0 multipath linear crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 crypto_simd cryptd glue_helper virtio_net net_failover failover psmouse ApportVersion: 2.20.11-0ubuntu24 Architecture: amd64 Date: Tue Apr 7 20:19:14 2020 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=C.UTF-8 SHELL=/bin/bash SourcePackage: lvm2 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1871487/+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 1871487] Re: anon_inode:[eventfd] leaked on vgs invocation inside lxd container
https://github.com/lxc/lxd/pull/7167 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lvm2 in Ubuntu. https://bugs.launchpad.net/bugs/1871487 Title: anon_inode:[eventfd] leaked on vgs invocation inside lxd container Status in lvm2 package in Ubuntu: Invalid Status in lxd package in Ubuntu: Fix Released Bug description: Steps to reproduce: $ lxc launch ubuntu-daily:f reproducer $ lxc shell reproducer $ vgs Expected behaviour: No output (the behaviour on an EC2 instance with no VGs). Actual behaviour: Outputs "File descriptor 25 (anon_inode:[eventfd]) leaked on vgs invocation. Parent PID 283: -bash" ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: lvm2 2.03.07-1ubuntu1 ProcVersionSignature: Ubuntu 5.0.0-1028.29~18.04.1-gcp 5.0.21 Uname: Linux 5.0.0-1028-gcp x86_64 NonfreeKernelModules: lkp_Ubuntu_5_0_0_1028_29_gcp_65 lkp_Ubuntu_5_0_0_1028_29_gcp_64 nf_tables lkp_Ubuntu_5_0_0_1028_29_gcp_63 ebtable_filter ebtables ufs msdos xfs binfmt_misc veth ip6t_MASQUERADE ip6table_nat nf_nat_ipv6 ipt_MASQUERADE xt_CHECKSUM xt_comment xt_tcpudp iptable_nat nf_nat_ipv4 nf_nat iptable_mangle bridge stp llc zfs zunicode zavl icp zcommon znvpair spl ip6table_filter ip6_tables iptable_filter bpfilter nls_iso8859_1 input_leds serio_raw sch_fq_codel ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq raid1 raid0 multipath linear crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 crypto_simd cryptd glue_helper virtio_net net_failover failover psmouse ApportVersion: 2.20.11-0ubuntu24 Architecture: amd64 Date: Tue Apr 7 20:19:14 2020 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=C.UTF-8 SHELL=/bin/bash SourcePackage: lvm2 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1871487/+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 1871487] Re: anon_inode:[eventfd] leaked on vgs invocation inside lxd container
https://github.com/canonical/raft/pull/123 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lvm2 in Ubuntu. https://bugs.launchpad.net/bugs/1871487 Title: anon_inode:[eventfd] leaked on vgs invocation inside lxd container Status in lvm2 package in Ubuntu: Invalid Status in lxd package in Ubuntu: Incomplete Bug description: Steps to reproduce: $ lxc launch ubuntu-daily:f reproducer $ lxc shell reproducer $ vgs Expected behaviour: No output (the behaviour on an EC2 instance with no VGs). Actual behaviour: Outputs "File descriptor 25 (anon_inode:[eventfd]) leaked on vgs invocation. Parent PID 283: -bash" ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: lvm2 2.03.07-1ubuntu1 ProcVersionSignature: Ubuntu 5.0.0-1028.29~18.04.1-gcp 5.0.21 Uname: Linux 5.0.0-1028-gcp x86_64 NonfreeKernelModules: lkp_Ubuntu_5_0_0_1028_29_gcp_65 lkp_Ubuntu_5_0_0_1028_29_gcp_64 nf_tables lkp_Ubuntu_5_0_0_1028_29_gcp_63 ebtable_filter ebtables ufs msdos xfs binfmt_misc veth ip6t_MASQUERADE ip6table_nat nf_nat_ipv6 ipt_MASQUERADE xt_CHECKSUM xt_comment xt_tcpudp iptable_nat nf_nat_ipv4 nf_nat iptable_mangle bridge stp llc zfs zunicode zavl icp zcommon znvpair spl ip6table_filter ip6_tables iptable_filter bpfilter nls_iso8859_1 input_leds serio_raw sch_fq_codel ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq raid1 raid0 multipath linear crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 crypto_simd cryptd glue_helper virtio_net net_failover failover psmouse ApportVersion: 2.20.11-0ubuntu24 Architecture: amd64 Date: Tue Apr 7 20:19:14 2020 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=C.UTF-8 SHELL=/bin/bash SourcePackage: lvm2 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1871487/+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 1871487] Re: anon_inode:[eventfd] leaked on vgs invocation inside lxd container
Ok, can you post the output of "ls -lh /proc/PID/fd/" where PID is the PID of the "lxd --logfile ..." process and the PID of the "daemon.start" script (lxd's parent process)? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lvm2 in Ubuntu. https://bugs.launchpad.net/bugs/1871487 Title: anon_inode:[eventfd] leaked on vgs invocation inside lxd container Status in lvm2 package in Ubuntu: Invalid Status in lxd package in Ubuntu: Incomplete Bug description: Steps to reproduce: $ lxc launch ubuntu-daily:f reproducer $ lxc shell reproducer $ vgs Expected behaviour: No output (the behaviour on an EC2 instance with no VGs). Actual behaviour: Outputs "File descriptor 25 (anon_inode:[eventfd]) leaked on vgs invocation. Parent PID 283: -bash" ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: lvm2 2.03.07-1ubuntu1 ProcVersionSignature: Ubuntu 5.0.0-1028.29~18.04.1-gcp 5.0.21 Uname: Linux 5.0.0-1028-gcp x86_64 NonfreeKernelModules: lkp_Ubuntu_5_0_0_1028_29_gcp_65 lkp_Ubuntu_5_0_0_1028_29_gcp_64 nf_tables lkp_Ubuntu_5_0_0_1028_29_gcp_63 ebtable_filter ebtables ufs msdos xfs binfmt_misc veth ip6t_MASQUERADE ip6table_nat nf_nat_ipv6 ipt_MASQUERADE xt_CHECKSUM xt_comment xt_tcpudp iptable_nat nf_nat_ipv4 nf_nat iptable_mangle bridge stp llc zfs zunicode zavl icp zcommon znvpair spl ip6table_filter ip6_tables iptable_filter bpfilter nls_iso8859_1 input_leds serio_raw sch_fq_codel ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq raid1 raid0 multipath linear crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 crypto_simd cryptd glue_helper virtio_net net_failover failover psmouse ApportVersion: 2.20.11-0ubuntu24 Architecture: amd64 Date: Tue Apr 7 20:19:14 2020 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=C.UTF-8 SHELL=/bin/bash SourcePackage: lvm2 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1871487/+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 1871487] Re: anon_inode:[eventfd] leaked on vgs invocation inside lxd container
Can you show `lxc info` please as well as `ls -lh /proc/self/fd` inside that "reproducer" container? I just tested it here and I'm seeing: ``` root@bionic:~# ls -l /proc/self/fd total 0 lrwx-- 1 root root 64 Apr 9 20:57 0 -> /dev/pts/1 lrwx-- 1 root root 64 Apr 9 20:57 1 -> /dev/pts/1 lrwx-- 1 root root 64 Apr 9 20:57 2 -> /dev/pts/1 lr-x-- 1 root root 64 Apr 9 20:57 3 -> /proc/7458/fd ``` Which is the normal set of fds and so wouldn't trigger the LVM warning. ** Changed in: lvm2 (Ubuntu) Status: New => Invalid ** Changed in: lxd (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lvm2 in Ubuntu. https://bugs.launchpad.net/bugs/1871487 Title: anon_inode:[eventfd] leaked on vgs invocation inside lxd container Status in lvm2 package in Ubuntu: Invalid Status in lxd package in Ubuntu: Incomplete Bug description: Steps to reproduce: $ lxc launch ubuntu-daily:f reproducer $ lxc shell reproducer $ vgs Expected behaviour: No output (the behaviour on an EC2 instance with no VGs). Actual behaviour: Outputs "File descriptor 25 (anon_inode:[eventfd]) leaked on vgs invocation. Parent PID 283: -bash" ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: lvm2 2.03.07-1ubuntu1 ProcVersionSignature: Ubuntu 5.0.0-1028.29~18.04.1-gcp 5.0.21 Uname: Linux 5.0.0-1028-gcp x86_64 NonfreeKernelModules: lkp_Ubuntu_5_0_0_1028_29_gcp_65 lkp_Ubuntu_5_0_0_1028_29_gcp_64 nf_tables lkp_Ubuntu_5_0_0_1028_29_gcp_63 ebtable_filter ebtables ufs msdos xfs binfmt_misc veth ip6t_MASQUERADE ip6table_nat nf_nat_ipv6 ipt_MASQUERADE xt_CHECKSUM xt_comment xt_tcpudp iptable_nat nf_nat_ipv4 nf_nat iptable_mangle bridge stp llc zfs zunicode zavl icp zcommon znvpair spl ip6table_filter ip6_tables iptable_filter bpfilter nls_iso8859_1 input_leds serio_raw sch_fq_codel ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq raid1 raid0 multipath linear crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 crypto_simd cryptd glue_helper virtio_net net_failover failover psmouse ApportVersion: 2.20.11-0ubuntu24 Architecture: amd64 Date: Tue Apr 7 20:19:14 2020 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=C.UTF-8 SHELL=/bin/bash SourcePackage: lvm2 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1871487/+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
Considering fixed as we now have 4.0.1 in the archive, if this still happens, let us know. ** Changed in: lxc (Ubuntu) Status: New => 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/1857046 Title: lxc 3.0.4-0ubuntu2 ADT test failure with linux 5.5.0-2.3 Status in lxc package in Ubuntu: Fix Released 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 1870539] Re: package liblxc-common 3.0.4-0ubuntu2 failed to install/upgrade: a tentar sobre-escrever '/usr/share/man/ja/man1/lxc-user-nic.1.gz', que também está no pacote lxc-uti
This has already been fixed in 4.0.1-0ubuntu1 ** Changed in: lxc (Ubuntu) Status: New => 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/1870539 Title: package liblxc-common 3.0.4-0ubuntu2 failed to install/upgrade: a tentar sobre-escrever '/usr/share/man/ja/man1/lxc-user-nic.1.gz', que também está no pacote lxc-utils 3.0.4-0ubuntu2 Status in lxc package in Ubuntu: Fix Released Bug description: EU estava utilizando normalmente o Ubuntu e começou a dar este erro toda vez que inicializo o sistema. ProblemType: Package DistroRelease: Ubuntu 20.04 Package: liblxc-common 3.0.4-0ubuntu2 ProcVersionSignature: Ubuntu 5.4.0-21.25-generic 5.4.27 Uname: Linux 5.4.0-21-generic x86_64 ApportVersion: 2.20.11-0ubuntu22 AptOrdering: liblxc1:amd64: Install liblxc-common:amd64: Install lxc-utils:amd64: Install NULL: ConfigurePending Architecture: amd64 Date: Fri Apr 3 09:40:14 2020 ErrorMessage: a tentar sobre-escrever '/usr/share/man/ja/man1/lxc-user-nic.1.gz', que também está no pacote lxc-utils 3.0.4-0ubuntu2 InstallationDate: Installed on 2020-03-20 (14 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20200220) ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-5.4.0-21-generic root=UUID=a587e5d5-e952-4c03-8a86-2af704b07304 ro quiet splash vt.handoff=7 Python3Details: /usr/bin/python3.8, Python 3.8.2, python3-minimal, 3.8.2-0ubuntu1 PythonDetails: N/A SourcePackage: lxc Title: package liblxc-common 3.0.4-0ubuntu2 failed to install/upgrade: a tentar sobre-escrever '/usr/share/man/ja/man1/lxc-user-nic.1.gz', que também está no pacote lxc-utils 3.0.4-0ubuntu2 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/1870539/+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 1869330] Re: Hangs after eoan -> focal release upgrade on shutdown
Wrong package as that's against the LXD snap and not any archive package. The issue sounds like: https://github.com/lxc/lxd-pkg-snap/issues/39 If you have any idea on how to reliably reproduce the issue, please comment in the Github issue as it's something we'd really like to get rid of... ** Bug watch added: github.com/lxc/lxd-pkg-snap/issues #39 https://github.com/lxc/lxd-pkg-snap/issues/39 ** 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/1869330 Title: Hangs after eoan -> focal release upgrade on shutdown Status in lxc package in Ubuntu: Invalid Bug description: Hi, I upgraded one of my machines from eoan to focal today and the reboot after the upgrade hang with: ``` A stop job s running for Service for snap application lxd.daemon (xxx / 10min) ``` Attached is the output of "sudo journalctl -u snap.lxd.daemon.service" This machines does not use lxd heavily but it does have a running snapcraft-core20-test container To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1869330/+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
This is now fixed in all channels and our own validation now checks for this too. ** Changed in: lxc (Ubuntu) Status: New => 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/1869661 Title: lxc 3.23 (?) breaks nested lxd with snaps Status in lxc package in Ubuntu: Fix Released 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 1867535] Re: [FFe] LXC 4.0.0 LTS
The release announcement finally got pushed out here: https://discuss.linuxcontainers.org/t/lxc-4-0-lts-has-been-released/7182 The main new features are: - cgroups: Full cgroup2 support - cgroups: Freezer support in CGroup2 - cgroups: eBPF device controller support in CGroup2 - config: Add lxc.autodev.tmpfs.size configuration key - config: Add lxc.selinux.context.keyring key - config: Add lxc.keyring.session - file utils: Add fopen_cached() and fdopen_cached - api: Add new init_pidfd() member - memory utils: Add new cleanup api - lxc-usernsexec: Make it easy to map own uid - seccomp: Add s390 support - syscalls: Improve manual syscall implementations - network: Improved network device creation and removal - network: Allow moving wireless devices Only one symbol was added compared to 3.2.1: - init_pidfd (to retrieve the pidfd of the init process) And a total of 5 since 3.0.0: - mount (to inject mounts into a running container) - umount (to remove mounts from a running container) - seccomp_notify_fd (to support syscall interception) - init_pidfd (to retrieve the pidfd of the init process) - lxc_has_api_extension (to check whether particular feature/options are present) No rebuilds are needed and all reverse dependencies of liblxc are know to work properly. LXC upstream has auto-generated PPAs that are used on all of our CI systems (running 18.04) so we have been testing those upgrades continuously and don't expect any issue. No configuration keys were removed in this release (unlike 3.0) and so no config updates are required for our users. Existing 3.0 users can upgrade to 4.0, running containers will keep working and the default configurations used by 4.0 are even backward compatible to 3.0, so a downgrade is even an option if needed. As mentioned above, the main benefit of getting 4.0 in Ubuntu is to get the 5 years of upstream security updates. Even though LXC is in universe, it's still quite widely used and actively maintained in Ubuntu by us. It's also worth noting that we've had all LXD users running the LXD snap run LXC 4.0 for the past week with only one regression found in the attach logic. This has since been fixed and will be cherry-picked in the package that's to be uploaded to Ubuntu. We realize we're getting late in the cycle, ideally we'd like this uploaded as soon as possible so it can get built, go through autopkgtest and land in the archive as soon as the freeze lifts (if it's covered by the freeze at all, not sure). -- 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/1867535 Title: [FFe] LXC 4.0.0 LTS Status in lxc package in Ubuntu: New Bug description: LXC 4.0 LTS will be tagged in the next week or so. LXC in Ubuntu is currently in universe as its main user is a snap nowadays (LXD) and builds directly from the upstream versions. We haven't written the changelog yet, but one thing worth noting is that it is 100% backward compatible, we do not break API and don't need to rebuild any of the rdepend for it. The main reason to want it in 20.04 LTS is because LXC 4.0 is itself an LTS with a matching 5 years of support. It also adds support for cgroupv2 which we expect to become more and more needed in the coming months/years. It'd be great if the release team could make a decision based on this already, if not, I will update the bug with the changelog and diff once we do have the release out. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1867535/+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
Hmm, I thought we pushed all the nesting fixes to stable on Friday. Our own nesting tests are all clean but it's possible we're not hitting this particular exec case. -- 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 1659590] Re: containers won't start after lxc and apparmor upgrades in trusty
** Changed in: lxc (Ubuntu) Status: Incomplete => 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/1659590 Title: containers won't start after lxc and apparmor upgrades in trusty Status in lxc package in Ubuntu: Fix Released Bug description: On January 19 lxc and apparmor were upgraded on our VPN servers: 2017-01-19 06:30:36 upgrade libdbus-1-3:amd64 1.6.18-0ubuntu4.4 1.6.18-0ubuntu4.5 2017-01-19 06:30:37 upgrade python3-lxc:amd64 1.0.8-0ubuntu0.4 1.0.9-0ubuntu2 2017-01-19 06:30:38 upgrade libapparmor1:amd64 2.8.95~2430-0ubuntu5.3 2.10.95-0ubuntu2.5~14.04.1 2017-01-19 06:30:38 upgrade libapparmor-perl:amd64 2.8.95~2430-0ubuntu5.3 2.10.95-0ubuntu2.5~14.04.1 2017-01-19 06:30:38 upgrade apparmor:amd64 2.8.95~2430-0ubuntu5.3 2.10.95-0ubuntu2.5~14.04.1 2017-01-19 06:30:39 upgrade lxc-templates:amd64 1.0.8-0ubuntu0.4 1.0.9-0ubuntu2 2017-01-19 06:30:40 upgrade liblxc1:amd64 1.0.8-0ubuntu0.4 1.0.9-0ubuntu2 2017-01-19 06:30:40 upgrade lxc:amd64 1.0.8-0ubuntu0.4 1.0.9-0ubuntu2 2017-01-19 06:30:41 upgrade libseccomp2:amd64 2.1.0+dfsg-1 2.1.1-1ubuntu1~trusty3 2017-01-19 06:30:42 upgrade dbus:amd64 1.6.18-0ubuntu4.4 1.6.18-0ubuntu4.5 The day after, the servers were rebooted and the application containers running the OpenVPN instances failed to start: + lxc-execute -n network-vpn -f /server/network.vpn/lxc/lxc.conf -- /server/network.vpn/lxc/lxc-start.sh lxc-execute: utils.c: safe_mount: 1391 No such file or directory - Failed to mount proc onto /proc lxc-execute: conf.c: tmp_proc_mount: 4132 No such file or directory - failed to mount /proc in the container. lxc-execute: lsm/apparmor.c: apparmor_process_label_get: 80 No such file or directory - opening /proc/1/attr/current lxc-execute: lsm/apparmor.c: apparmor_process_label_set: 191 No such file or directory - failed to change apparmor profile to lxc-container-default lxc-execute: sync.c: __sync_wait: 57 An error occurred in another process (expected sequence number 5) lxc-execute: start.c: __lxc_start: 1149 failed to spawn 'network-vpn' lxc-execute: cgmanager.c: cgm_remove_cgroup: 523 call to cgmanager_remove_sync failed: invalid request lxc-execute: cgmanager.c: cgm_remove_cgroup: 525 Error removing hugetlb:lxc/network-vpn lxc-execute: cgmanager.c: cgm_remove_cgroup: 523 call to cgmanager_remove_sync failed: invalid request lxc-execute: cgmanager.c: cgm_remove_cgroup: 525 Error removing perf_event:lxc/network-vpn lxc-execute: cgmanager.c: cgm_remove_cgroup: 523 call to cgmanager_remove_sync failed: invalid request lxc-execute: cgmanager.c: cgm_remove_cgroup: 525 Error removing blkio:lxc/network-vpn lxc-execute: cgmanager.c: cgm_remove_cgroup: 523 call to cgmanager_remove_sync failed: invalid request lxc-execute: cgmanager.c: cgm_remove_cgroup: 525 Error removing freezer:lxc/network-vpn lxc-execute: cgmanager.c: cgm_remove_cgroup: 523 call to cgmanager_remove_sync failed: invalid request lxc-execute: cgmanager.c: cgm_remove_cgroup: 525 Error removing devices:lxc/network-vpn lxc-execute: cgmanager.c: cgm_remove_cgroup: 523 call to cgmanager_remove_sync failed: invalid request lxc-execute: cgmanager.c: cgm_remove_cgroup: 525 Error removing memory:lxc/network-vpn lxc-execute: cgmanager.c: cgm_remove_cgroup: 523 call to cgmanager_remove_sync failed: invalid request lxc-execute: cgmanager.c: cgm_remove_cgroup: 525 Error removing name=systemd:lxc/network-vpn lxc-execute: cgmanager.c: cgm_remove_cgroup: 523 call to cgmanager_remove_sync failed: invalid request lxc-execute: cgmanager.c: cgm_remove_cgroup: 525 Error removing cpuacct:lxc/network-vpn lxc-execute: cgmanager.c: cgm_remove_cgroup: 523 call to cgmanager_remove_sync failed: invalid request lxc-execute: cgmanager.c: cgm_remove_cgroup: 525 Error removing cpu:lxc/network-vpn lxc-execute: cgmanager.c: cgm_remove_cgroup: 523 call to cgmanager_remove_sync failed: invalid request lxc-execute: cgmanager.c: cgm_remove_cgroup: 525 Error removing cpuset:lxc/network-vpn We had to downgrade lxc, apparmor and related packages to the latest version from trusty-security instead of trusty-updates to get the VPN up and running again. Details: No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 14.04.5 LTS Release: 14.04 Codename: trusty 3.13.0-107-generic #154-Ubuntu SMP Tue Dec 20 09:57:27 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux Any clue about what's going on? Thanks, Alex To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1659590/+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 1575757] Re: Can't install kernel-nfs-server inside lxc container
There's nothing particularly safe for us to do here out of the box. Using an alternative profile or appending to the profile (in LXD's case) is your best bet. ** Changed in: lxc (Ubuntu) Status: Confirmed => 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/1575757 Title: Can't install kernel-nfs-server inside lxc container Status in lxc package in Ubuntu: Invalid Bug description: I'm trying to virtualize a package that depends on NFS by installing it in an LXC container. The commands sudo apt-get install nfs-kernel-server sudo lxc-create -n nfstest -t download -- -d ubuntu -r xenial -a amd64 sudo lxc-start -n nfstest sudo lxc-attach -n nfstest apt-get update sudo lxc-attach -n nfstest apt-get install nfs-kernel-server should install NFS server software inside the container, but instead fail with ... Not creating home directory `/var/lib/nfs'. nfs-utils.service is a disabled or a static unit, not starting it. Setting up nfs-kernel-server (1:1.2.8-9ubuntu12) ... A dependency job for nfs-server.service failed. See 'journalctl -xe' for details. nfs-server.service couldn't start. Creating config file /etc/exports with new version Creating config file /etc/default/nfs-kernel-server with new version A dependency job for nfs-server.service failed. See 'journalctl -xe' for details. invoke-rc.d: initscript nfs-kernel-server, action "start" failed. dpkg: error processing package nfs-kernel-server (--configure): subprocess installed post-installation script returned error exit status 1 Processing triggers for libc-bin (2.23-0ubuntu3) ... Processing triggers for ureadahead (0.100.0-19) ... Processing triggers for systemd (229-4ubuntu4) ... Errors were encountered while processing: nfs-kernel-server E: Sub-process /usr/bin/dpkg returned an error code (1) sudo lxc-attach -n nfstest journalctl -xe reports: Apr 27 15:42:59 nfstest systemd[1]: Failed to mount NFSD configuration filesystem -- Subject: Unit proc-fs-nfsd.mount has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Unit proc-fs-nfsd.mount has failed. -- The result is failed. Presumably this is intended, and there is a way to configure lxc to allow running nfs servers inside it (there are rumors of success on the web), but https://help.ubuntu.com/lts/serverguide/lxc.html is silent on the issue, and doesn't even mention the word nfs. Likewise, https://help.ubuntu.com/lts/serverguide/network-file-system.html doesn't even mention lxc. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: lxc 2.0.0-0ubuntu2 ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6 Uname: Linux 4.4.0-21-generic x86_64 ApportVersion: 2.20.1-0ubuntu2 Architecture: amd64 CurrentDesktop: Unity Date: Wed Apr 27 08:19:41 2016 InstallationDate: Installed on 2016-03-26 (32 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Beta amd64 (20160323) PackageArchitecture: all SourcePackage: lxc UpgradeStatus: No upgrade log present (probably fresh install) 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/1575757/+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 1389954] Re: Make .lxc domain name resolution easier to discover and enable
** Changed in: lxc (Ubuntu) Status: Confirmed => Triaged -- 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/1389954 Title: Make .lxc domain name resolution easier to discover and enable Status in lxc package in Ubuntu: Triaged Bug description: The lxc package on ubuntu does almost nothing to help a user enable DNS resolution for containers via dnsmaq, let alone discover that it is possible. How about enabling it by default? I think all it would take is adding server=/lxc/10.0.3.1 to a file in /etc/NetworkManager/dnsmasq.d/ and uncommenting LXC_DOMAIN="lxc" in /etc/default/lxc-net. Even if there's a good reason not to enable this by default, shouldn't it at least be clearly documented someplace obvious instead of buried in a system config file with a misleading comment that mentions the wrong dnsmasq file to edit? (The one currently mentioned by /etc/default/lxc-net does nothing on ubuntu desktop systems, because ubuntu's NetworkManager starts dnsmasq with a special config directory.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1389954/+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 1569679] Re: lxc failed to do lxc-checkpoint again
** Changed in: lxc (Ubuntu) Status: Confirmed => 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/1569679 Title: lxc failed to do lxc-checkpoint again Status in lxc package in Ubuntu: Invalid Bug description: When doing lxc-checkpoint, it replies: lxc-checkpoint: criu.c: do_dump: 879 dump failed with 1 Checkpointing xxx failed. About my ENV: # uname -a Linux ubuntu 4.4.0-18-generic #34-Ubuntu SMP Wed Apr 6 14:01:02 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux # lsb_release -a Distributor ID: Ubuntu Description: Ubuntu Xenial Xerus (development branch) Release: 16.04 Codename: xenial # apt-cache policy lxc lxc: Installed: 2.0.0-0ubuntu1 Candidate: 2.0.0-0ubuntu1 Version table: *** 2.0.0-0ubuntu1 500 500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages 100 /var/lib/dpkg/status # apt-cache policy criu criu: Installed: 2.0-2ubuntu3 Candidate: 2.0-2ubuntu3 Version table: *** 2.0-2ubuntu3 500 500 http://archive.ubuntu.com/ubuntu xenial/universe amd64 Packages 100 /var/lib/dpkg/status ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: lxc 2.0.0-0ubuntu1 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-0ubuntu1 Architecture: amd64 Date: Wed Apr 13 12:44:20 2016 PackageArchitecture: all ProcEnviron: LANGUAGE=zh_CN:zh TERM=xterm-256color PATH=(custom, no user) LANG=zh_CN.UTF-8 SHELL=/bin/bash SourcePackage: lxc UpgradeStatus: No upgrade log present (probably fresh install) 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/1569679/+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 1240757] Re: Bridge not created if bind9 is on
** Changed in: lxc (Ubuntu) Status: Triaged => Won't Fix -- 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/1240757 Title: Bridge not created if bind9 is on Status in bind9 package in Ubuntu: Triaged Status in lxc package in Ubuntu: Won't Fix Status in lxd package in Ubuntu: Won't Fix Bug description: LXC will not create the lxcbr0 bridge if bind9 is on, as it can not take the 10.0.3.1 address. If bind9 is stopped, then LXC successfully creates the bridge. Expected result: LXC will create the bridge, even if bind9 is on. --- ApportVersion: 2.9.2-0ubuntu8.3 Architecture: i386 DistroRelease: Ubuntu 13.04 InstallationDate: Installed on 2013-06-29 (110 days ago) InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release i386 (20130424) MarkForUpload: True Package: lxc PackageArchitecture: i386 ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-3.8.0-31-generic root=UUID=4c07e19b-cf33-4cbd-ab6d-fe300398b22b ro quiet splash vt.handoff=7 ProcVersionSignature: Ubuntu 3.8.0-31.46-generic 3.8.13.8 RelatedPackageVersions: bind9utils 1:9.9.2.dfsg.P1-2ubuntu2.1 apparmor 2.8.0-0ubuntu11 Tags: raring Uname: Linux 3.8.0-31-generic i686 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo modified.conffile..etc.bind.named.conf.local: [modified] mtime.conffile..etc.bind.named.conf.local: 2013-08-01T12:03:20.742316 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1240757/+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 1861880] Re: lxc-attach command does not return error exit code if the command is failed
** 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/1861880 Title: lxc-attach command does not return error exit code if the command is failed Status in lxc package in Ubuntu: Fix Committed Status in lxc package in Debian: Fix Released Bug description: lxc-attach command does not return error exit code if the command is failed on Ubuntu Focal : root@scribe:~# lxc-start --version 3.0.4 root@scribe:~# lxc-attach --logpriority=DEBUG --name=addc -- exit lxc-attach: addc: attach.c: lxc_attach_run_command: 1489 No such file or directory - Failed to exec "exit" root@scribe:~# echo $? 0 The problem is fixed upstream : https://github.com/lxc/lxc/issues/3104 and by Debian : https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=934983 ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: lxc-utils 3.0.4-0ubuntu2 ProcVersionSignature: Ubuntu 5.4.0-12.15-generic 5.4.8 Uname: Linux 5.4.0-12-generic x86_64 ApportVersion: 2.20.11-0ubuntu16 Architecture: amd64 Date: Tue Feb 4 16:01:30 2020 InstallationDate: Installed on 2020-01-10 (25 days ago) InstallationMedia: Ubuntu-Server 20.04 LTS "Focal Fossa" - Alpha amd64 (20200105) 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 lxc-net.default: USE_LXC_BRIDGE="true" LXC_BRIDGE="br0" LXC_ADDR="192.0.2.1" LXC_NETMASK="255.255.255.0" LXC_NETWORK="192.0.2.0/24" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1861880/+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
** 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/1858799 Title: lxc ADT test failure on Bionic with linux-raspi2-5.3 arm64 Status in lxc package in Ubuntu: Fix Committed 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 1760848] Re: lxc-create can't create bionic container on xenial
We're now using distrobuilder to build pre-made images avoiding the mess that was those scripts. ** 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/1760848 Title: lxc-create can't create bionic container on xenial Status in lxc package in Ubuntu: Fix Released Bug description: I did run: lxc-create -t ubuntu -n ubu18.04 -- template-options -r bionic which fails in the end: (...) Download complete Copy /var/cache/lxc/bionic/rootfs-amd64 to /var/lib/lxc/ubu18.04/rootfs ... Copying rootfs to /var/lib/lxc/ubu18.04/rootfs ... Generating locales (this might take a while)... de_DE.UTF-8... done Generation complete. mv: Aufruf von stat für '/var/lib/lxc/ubu18.04/rootfs/etc/init/ssh.conf' nicht möglich: Datei oder Verzeichnis nicht gefunden lxc-create: lxccontainer.c: create_run_template: 1295 container creation template for ubu18.04 failed lxc-create: tools/lxc_create.c: main: 318 Error creating container ubu18.04 I've seen that when creating a xenial container this is the point where new sshd keys get created. dpkg -l 'lxc*' ||/ Name Version +++-==-==- ii lxc2.0.8-0ubuntu1~16.04.2 ii lxc-common 2.0.8-0ubuntu1~16.04.2 ii lxc-templates 2.0.8-0ubuntu1~16.04.2 ii lxc1 2.0.8-0ubuntu1~16.04.2 ii lxcfs 2.0.8-0ubuntu1~16.04.2 un lxcguest un lxctl lsb_release -rd Description: Ubuntu 16.04.4 LTS Release: 16.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1760848/+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 1866124] Re: ps -eo lxc no longer shows a task's lxc container
** 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/1866124
Title:
ps -eo lxc no longer shows a task's lxc container
Status in lxc package in Ubuntu:
Invalid
Status in procps package in Ubuntu:
New
Bug description:
When I use the ps command's "lxc" format specifier, for example:
ps -eo pid,lxc,command
The second output column is supposed to show "the name of the lxc
container within which a task is running. If a process is not running
inside a container, a dash ('-') will be shown." [1]
This worked fine until I upgraded from ubuntu 19.04 to 19.10, which
brought me from lxc 3.03 to 3.04. Now, that column always contains a
dash instead of the container name, even for processes that are
running inside a container. The "lxc" format specifier seems to be
broken now.
[1]
https://manpages.ubuntu.com/manpages/eoan/man1/ps.1.html#standard%20format%20specifiers
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1866124/+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 1659590] Re: containers won't start after lxc and apparmor upgrades in trusty
anyone still affected by this? ** Changed in: lxc (Ubuntu) Status: Confirmed => Incomplete -- 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/1659590 Title: containers won't start after lxc and apparmor upgrades in trusty Status in lxc package in Ubuntu: Incomplete Bug description: On January 19 lxc and apparmor were upgraded on our VPN servers: 2017-01-19 06:30:36 upgrade libdbus-1-3:amd64 1.6.18-0ubuntu4.4 1.6.18-0ubuntu4.5 2017-01-19 06:30:37 upgrade python3-lxc:amd64 1.0.8-0ubuntu0.4 1.0.9-0ubuntu2 2017-01-19 06:30:38 upgrade libapparmor1:amd64 2.8.95~2430-0ubuntu5.3 2.10.95-0ubuntu2.5~14.04.1 2017-01-19 06:30:38 upgrade libapparmor-perl:amd64 2.8.95~2430-0ubuntu5.3 2.10.95-0ubuntu2.5~14.04.1 2017-01-19 06:30:38 upgrade apparmor:amd64 2.8.95~2430-0ubuntu5.3 2.10.95-0ubuntu2.5~14.04.1 2017-01-19 06:30:39 upgrade lxc-templates:amd64 1.0.8-0ubuntu0.4 1.0.9-0ubuntu2 2017-01-19 06:30:40 upgrade liblxc1:amd64 1.0.8-0ubuntu0.4 1.0.9-0ubuntu2 2017-01-19 06:30:40 upgrade lxc:amd64 1.0.8-0ubuntu0.4 1.0.9-0ubuntu2 2017-01-19 06:30:41 upgrade libseccomp2:amd64 2.1.0+dfsg-1 2.1.1-1ubuntu1~trusty3 2017-01-19 06:30:42 upgrade dbus:amd64 1.6.18-0ubuntu4.4 1.6.18-0ubuntu4.5 The day after, the servers were rebooted and the application containers running the OpenVPN instances failed to start: + lxc-execute -n network-vpn -f /server/network.vpn/lxc/lxc.conf -- /server/network.vpn/lxc/lxc-start.sh lxc-execute: utils.c: safe_mount: 1391 No such file or directory - Failed to mount proc onto /proc lxc-execute: conf.c: tmp_proc_mount: 4132 No such file or directory - failed to mount /proc in the container. lxc-execute: lsm/apparmor.c: apparmor_process_label_get: 80 No such file or directory - opening /proc/1/attr/current lxc-execute: lsm/apparmor.c: apparmor_process_label_set: 191 No such file or directory - failed to change apparmor profile to lxc-container-default lxc-execute: sync.c: __sync_wait: 57 An error occurred in another process (expected sequence number 5) lxc-execute: start.c: __lxc_start: 1149 failed to spawn 'network-vpn' lxc-execute: cgmanager.c: cgm_remove_cgroup: 523 call to cgmanager_remove_sync failed: invalid request lxc-execute: cgmanager.c: cgm_remove_cgroup: 525 Error removing hugetlb:lxc/network-vpn lxc-execute: cgmanager.c: cgm_remove_cgroup: 523 call to cgmanager_remove_sync failed: invalid request lxc-execute: cgmanager.c: cgm_remove_cgroup: 525 Error removing perf_event:lxc/network-vpn lxc-execute: cgmanager.c: cgm_remove_cgroup: 523 call to cgmanager_remove_sync failed: invalid request lxc-execute: cgmanager.c: cgm_remove_cgroup: 525 Error removing blkio:lxc/network-vpn lxc-execute: cgmanager.c: cgm_remove_cgroup: 523 call to cgmanager_remove_sync failed: invalid request lxc-execute: cgmanager.c: cgm_remove_cgroup: 525 Error removing freezer:lxc/network-vpn lxc-execute: cgmanager.c: cgm_remove_cgroup: 523 call to cgmanager_remove_sync failed: invalid request lxc-execute: cgmanager.c: cgm_remove_cgroup: 525 Error removing devices:lxc/network-vpn lxc-execute: cgmanager.c: cgm_remove_cgroup: 523 call to cgmanager_remove_sync failed: invalid request lxc-execute: cgmanager.c: cgm_remove_cgroup: 525 Error removing memory:lxc/network-vpn lxc-execute: cgmanager.c: cgm_remove_cgroup: 523 call to cgmanager_remove_sync failed: invalid request lxc-execute: cgmanager.c: cgm_remove_cgroup: 525 Error removing name=systemd:lxc/network-vpn lxc-execute: cgmanager.c: cgm_remove_cgroup: 523 call to cgmanager_remove_sync failed: invalid request lxc-execute: cgmanager.c: cgm_remove_cgroup: 525 Error removing cpuacct:lxc/network-vpn lxc-execute: cgmanager.c: cgm_remove_cgroup: 523 call to cgmanager_remove_sync failed: invalid request lxc-execute: cgmanager.c: cgm_remove_cgroup: 525 Error removing cpu:lxc/network-vpn lxc-execute: cgmanager.c: cgm_remove_cgroup: 523 call to cgmanager_remove_sync failed: invalid request lxc-execute: cgmanager.c: cgm_remove_cgroup: 525 Error removing cpuset:lxc/network-vpn We had to downgrade lxc, apparmor and related packages to the latest version from trusty-security instead of trusty-updates to get the VPN up and running again. Details: No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 14.04.5 LTS Release: 14.04 Codename: trusty 3.13.0-107-generic #154-Ubuntu SMP Tue Dec 20 09:57:27 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux Any clue about what's going on? Thanks, Alex To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1659590/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help :
[Touch-packages] [Bug 1776381] Re: lxc-test-api-reboot will hang with autopkgtest
It's not currently failing based on recent logs anyway. ** 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/1776381 Title: lxc-test-api-reboot will hang with autopkgtest Status in ubuntu-kernel-tests: Confirmed Status in lxc package in Ubuntu: Invalid 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 1843383] Re: lxc, please bump epoch to 1
*** This bug is a duplicate of bug 1837537 *** https://bugs.launchpad.net/bugs/1837537 ** This bug has been marked a duplicate of bug 1837537 FTBFS since lxc has different version numbers in Debian and 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/1843383 Title: lxc, please bump epoch to 1 Status in lxc package in Ubuntu: New Bug description: A lot of stuff from Debian is bd-uninstallable because of the missing epoch on the Ubuntu package. e.g. lua-lxc, and general packages using liblxc1 at runtime (python3-lxc and something else). I think bumping epoch (whilst bad in general), would be a big improvement in this case (also MergeOMatic will stop being unhelpful with lxc merges) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1843383/+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 1794523] Re: lxc-net.service is not properly ordered with network-online.target
Hmm, no, that would be wrong. Wants=/Requires= would cause lxc-net to not start if network- online.target is missing or if it fails. We only want to start after it if it does exist, which is what After does. ** Changed in: lxc (Ubuntu) Status: New => Incomplete -- 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/1794523 Title: lxc-net.service is not properly ordered with network-online.target Status in lxc package in Ubuntu: Incomplete Bug description: I made several tests and I figure out that the lxc-net.service is missing a Wants= directive to be properly ordered against network- online.target. As I understand the systemd.unit manpage, to be properly ordered a unit must define a Requires=/Wants= in addition to an After=/Before=. Regards. Distributor ID: Ubuntu Description: Ubuntu 18.04.1 LTS Release: 18.04 Codename: bionic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1794523/+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 1840639] Re: Version 3.0.3 breaks lxc-usernsexec
What are your subuid/subgid allocations like? ** Changed in: lxc (Ubuntu) Status: New => Incomplete -- 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/1840639 Title: Version 3.0.3 breaks lxc-usernsexec Status in lxc package in Ubuntu: Incomplete Bug description: Affected version: 3.0.3 Last working version: 3.0.1 Upgrade from 3.0.1 to 3.0.3 for lxc packages breaks lxc-usernsexec with message 'Failed to find subuid or subgid allocation' even those allocation is fine. Downgrading back to 3.0.1 fixes the problem. Steps to reproduce: Set up 3.0.1 lxc to work. (lxc-usernsexec whoami should show 'root') Upgrade to 3.0.3 Run lxc-usernsexec whoami Expected result: root Actual result: Failed to find subuid or subgid allocation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1840639/+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 1828255] Re: It's too easy to accidentally delete a container rather than a snapshot
There is configurable prompting for those that want it. We also refuse
to delete running containers.
** Changed in: lxc (Ubuntu)
Status: New => 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/1828255
Title:
It's too easy to accidentally delete a container rather than a
snapshot
Status in lxc package in Ubuntu:
Fix Released
Bug description:
The command to delete a container is:
lxc delete {container}/{snapshot}
Unfortunately, if the "/" is omitted, this command deletes {container}
without any sort of prompting. It would be very helpful to add a
prompt/verification when deleting the entire container to avoid
mishaps. Don't ask me how I know that they happen.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1828255/+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
