nspawn on some 32-bit archs blocks _time64 syscalls, breaks upgrade to focal in containers
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
systemd (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Bionic |
Fix Released
|
Low
|
Dan Streetman | ||
Focal |
Fix Released
|
Undecided
|
Unassigned |
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:/
$ mkdir f
$ cd f
$ tar xvf ../focal-
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 6ca677106992321
[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:/
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:/
description: | updated |
Changed in systemd (Ubuntu Bionic): | |
assignee: | nobody → Dan Streetman (ddstreet) |
importance: | Undecided → Low |
status: | New → In Progress |
description: | updated |
description: | updated |
Nice write down of the problem. Also provided solution. Here it goes onto the next state.