[Bug 1883447] Re: nspawn on some 32-bit archs blocks _time64 syscalls, breaks upgrade to focal in containers

Wed Mar 3 20:40:40 UTC 2021

** 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 at 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 at 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
Foundations Bugs, 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:
  In Progress
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [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
  Spawning container f on /root/f.
  Press ^] three times within 1s to kill container.
  root at 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