** Description changed: [impact] nspawn fails on armhf [test case] - TBD + setup a bionic armhf system, and get a focal img/filesystem to use with + systemd-nspawn, e.g. + + $ wget https://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-armhf-root.tar.xz + $ mkdir f + $ cd f + $ tar xvf ../focal-server-cloudimg-armhf-root.tar.xz + + install systemd-container, and start nspawn; then test anything that + uses the time, e.g. just run python: + + $ systemd-nspawn + Spawning container f on /root/f. + Press ^] three times within 1s to kill container. + root@f:~# python3 + Fatal Python error: pyinit_main: can't initialize time + Python runtime state: core initialized + PermissionError: [Errno 1] Operation not permitted + + Current thread 0xf7bbd310 (most recent call first): + <no Python frame> + [regression potential] any regression would likely break nspawn creation of containers, particularly on armhf, but possibly on other archs [scope] this is needed only in bionic. this is fixed upstream by commit 6ca677106992321326427c89a40e1c9673a499b2 which was included first in v244, so this is fixed already in focal and later. [original description] Recent Linux kernels introduced a number of new syscalls ending in _time64 to fix Y2038 problem; it appears recent glibc, including the version in focal, test for the existence of these. systemd-nspawn in bionic (237-3ubuntu10.38) doesn't know about these so blocks them by default. It seems however glibc isn't expecting an EPERM, causing numerous programs to fail. In particular, running do-release-upgrade to focal in an nspawn container hosted on bionic will break as soon as the new libc has been unpacked. Solution (tested here) is to cherrypick upstream commit https://github.com/systemd/systemd/commit/6ca677106992321326427c89a40e1c9673a499b2 A newer libseccomp is also needed but this is already being worked on, see bug #1876055. It's a pretty trivial fix one the new libseccomp lands, and there is precedent for SRU-ing for a similar issue in bug #1840640. https://patchwork.kernel.org/patch/10756415/ is apparently the upstream kernel patch, which should give a clearer idea of which architectures are likely to be affected - I noticed it on armhf.
** Description changed: [impact] nspawn fails on armhf [test case] setup a bionic armhf system, and get a focal img/filesystem to use with systemd-nspawn, e.g. $ wget https://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-armhf-root.tar.xz $ mkdir f $ cd f $ tar xvf ../focal-server-cloudimg-armhf-root.tar.xz install systemd-container, and start nspawn; then test anything that uses the time, e.g. just run python: - $ systemd-nspawn + $ systemd-nspawn Spawning container f on /root/f. Press ^] three times within 1s to kill container. root@f:~# python3 Fatal Python error: pyinit_main: can't initialize time Python runtime state: core initialized PermissionError: [Errno 1] Operation not permitted Current thread 0xf7bbd310 (most recent call first): <no Python frame> - [regression potential] - any regression would likely break nspawn creation of containers, - particularly on armhf, but possibly on other archs + any regression would likely break nspawn creation or operation of + containers, particularly on armhf, but possibly on other archs [scope] this is needed only in bionic. this is fixed upstream by commit 6ca677106992321326427c89a40e1c9673a499b2 which was included first in v244, so this is fixed already in focal and later. [original description] Recent Linux kernels introduced a number of new syscalls ending in _time64 to fix Y2038 problem; it appears recent glibc, including the version in focal, test for the existence of these. systemd-nspawn in bionic (237-3ubuntu10.38) doesn't know about these so blocks them by default. It seems however glibc isn't expecting an EPERM, causing numerous programs to fail. In particular, running do-release-upgrade to focal in an nspawn container hosted on bionic will break as soon as the new libc has been unpacked. Solution (tested here) is to cherrypick upstream commit https://github.com/systemd/systemd/commit/6ca677106992321326427c89a40e1c9673a499b2 A newer libseccomp is also needed but this is already being worked on, see bug #1876055. It's a pretty trivial fix one the new libseccomp lands, and there is precedent for SRU-ing for a similar issue in bug #1840640. https://patchwork.kernel.org/patch/10756415/ is apparently the upstream kernel patch, which should give a clearer idea of which architectures are likely to be affected - I noticed it on armhf. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1883447 Title: nspawn on some 32-bit archs blocks _time64 syscalls, breaks upgrade to focal in containers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1883447/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
