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

[Steve Dodd]

This bug also seems to generate "Assertion
'clock_gettime(map_clock_id(clock_id), &ts) == 0' failed at src/basic
/time-util.c:55, function now(). Aborting" in various places if you try
to boot an existing 20.04 container on bionic with systemd-nspawn.

-- 
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:
  Confirmed

Bug 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