root@test:~/f# dpkg -l|grep systemd-container
ii systemd-container 237-3ubuntu10.44 armhf
systemd container/nspawn tools
root@test:~/f# 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 0xf7aea310 (most recent call first):
<no Python frame>
root@test:~/f# dpkg -l|grep systemd-container
ii systemd-container 237-3ubuntu10.45 armhf
systemd container/nspawn tools
root@test:~/f# systemd-nspawn
Spawning container f on /root/f.
Press ^] three times within 1s to kill container.
root@f:~# python3
Python 3.8.5 (default, Jan 27 2021, 15:41:15)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>
** 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.
+ setup a bionic armhf system (note that if lxd is used to setup armhf
+ container under arm64 system, the armhf container must have
+ 'security.nesting' set to true) 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 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.
** Tags removed: verification-needed verification-needed-bionic
** Tags added: verification-done verification-done-bionic
--
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/1883447
Title:
nspawn on some 32-bit archs blocks _time64 syscalls, breaks upgrade to
focal in containers
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Bionic:
Fix Committed
Status in systemd source package in Focal:
Fix Released
Bug description:
[impact]
nspawn fails on armhf
[test case]
setup a bionic armhf system (note that if lxd is used to setup armhf
container under arm64 system, the armhf container must have
'security.nesting' set to true) 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 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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1883447/+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
