The latest Ubuntu base image for armhf return random values for date/time

This (in my eyes) very critical bug is now "Unassigned" and "Undecided" for 14 days, although it can be reproduced within seconds.
For clarification: Ubuntu cannot be used on armhf processors

I was unable to reproduce with Ubuntu Focal 64 bit as the host. Could you provide the Host OS version. Focal is on a 5.4 kernel, and Bionic should have rolled to a 5.x kernel as well.

my guess at this time is your host is a 32bit (from the armv7l listing in the kernel). if you let me know the Host OS version (not just kernel) I can work on reproducing. I'm flashing a Bionic 18.0.4.5 32bit image now for testing

Hello John,

Thanks for the investigating. My test system is a Raspberry Pi 4 running Raspbian (Buster). But I can reproduce this problem on all my systems with armhf cpu. For example I have an industrial PLC (WAGO PFC200) with ARMv7-CPU and docker support which has exactly the same problem. So I am pretty sure that it is the docker image and not the host system.

Sorry, I had forgotten that: Yes my test systems are 32bit ARM systems. On 64bit systems the problem is not reproducible.

I tested with Ubuntu Bionic 32bit and was unable to reproduce. Also unable to reproduce with a Focal 32bit. Both of these are running the 5.4 kernel though, so it may just be affecting 4.X series kernels.

I'll flash a Raspbian Buster 32 bit and test on my Raspberry Pi 4

I've confirmed that running on kernel 4.19.97-v7l, available on the Raspbian image published on 2020-02-14 there are issues running `date`. it returns the Linux epoch date. the following containers are affected:

ubuntu/focal
ubuntu/groovy
debian/bullseye

there was not an issue with debian/buster, nor any of the other distros I tried.

Passing:

* alpine:latest
* opensuse:leap
* centos:7
* debian:buster

I then ran a dist-upgrade, which upgrade the kernel from 4.19 to 5.4.51.

I then ran `date` in the same containers.

* ubuntu:focal returned random date/times in the epoch year
* ubuntu:groovy returned epoch
* debian:bullseye return epoch

the previously passing containers all continued to work as expected.

Status changed to 'Confirmed' because the bug affects multiple users.

Bug is only at arm/v7
Tested on rpi3 with ubuntu 20.04 arm/v7 and arm64

Last working image is ubuntu:focal-20200115

Issue posted at:
https://github.com/boostorg/boost/issues/474

Can be related to the last commit:
http://changelogs.ubuntu.com/changelogs/pool/main/b/boost-defaults/boost-defaults_1.71.0.0ubuntu2/changelog

ubuntu 20.04 arm/v7 (rpi3)
$ docker run ubuntu:focal-20210119 date
Sun Feb 22 06:29:15 UTC 1970
$ docker run ubuntu:focal-20200115 date
Sat Jan 30 13:24:03 UTC 2021
$ date
Sat Jan 30 13:24:15 UTC 2021
ubuntu 20.04 arm64 (rpi3)
$ docker run ubuntu:focal-20210119 date
Sat Jan 30 13:27:28 UTC 2021
$ docker run ubuntu:focal-20200115 date
Sat Jan 30 13:28:26 UTC 2021
$ date
Sat Jan 30 13:28:38 UTC 2021

I can confirm on a pi4 :

Linux mediacenter 4.19.66-v7l+ #1253 SMP Thu Aug 15 12:02:08 BST 2019 armv7l GNU/Linux

Hello, this should be marked as critical for armv7 because it merely breaks the operating system. All HTTPS requests are impossible as the certicates are signed in the future.

Below example logs generated by an application running on this image - you feel like being in a TARDIS :)

Jul 01, 1971 16:44:24.-1261346 [0xaaffb430] ERROR - Error issuing curl_easy_perform(handle): 28
Mar 14, 1929 16:09:28.-1261346 [0xaaffb430] DEBUG - HTTP simulating 408 after curl timeout
Jan 01, 1970 01:00:45.-1261346 [0xaaffb430] DEBUG - [com.plexapp.system] HTTP reply status 408, with 0 bytes of content.
Jul 01, 1971 16:44:24.-1261346 [0xb2bfe430] ERROR - Error issuing curl_easy_perform(handle): 28
Jan 01, 1970 01:00:00.-1261346 [0xb2bfe430] DEBUG - HTTP simulating 408 after curl timeout
Jan 01, 1970 01:00:45.-1261346 [0xb2bfe430] ERROR - Error parsing content.
Aug 08, 1928 06:14:24.-1261346 [0xb2bfe430] ERROR - Error parsing XML: Error parsing file.
Dec 06, 1928 10:00:36.-1261346 [0xb2bfe430] DEBUG - Media Server: Tested all servers in 1296050206.7 seconds.
Sep 26, 1927 14:28:32.-1261346 [0xb07ff430] DEBUG - MyPlex: Updating device connections (from timer: 1)

Hello,

the linuxserver.io team has identified the problem : it's a libseccomp library problem on the host (debian) and not an ubuntu docker image problem. See here for more informations : https://docs.linuxserver.io/faq#libseccomp

Best regards

Hi,

Thanks for the link about libseccomp. After reading that link and a couple of bugs on Github about this it seems the root cause is due to containers of newer releases (e.g. 20.04), which make syscalls that hosts with older software might not know about.

To resolve then, users need to:

1) Use Docker version 19.03.9 or newer
2) Ensure the host has libseccomp version of 2.4.2 or higher. libseccomp is already 2.4.3 in all supported versions of Ubuntu and appears to have the newer syscalls listed.

I am marking this as invalid for the "cloud-images" project as it is clear this is not an Ubuntu docker image issue.

I am adding docker.io package to the affects, as the versions in bionic (19.03.6) and focal (19.03.8) are just behind the 19.03.9 version required with a fix.

I found the solution.

It solves many other problems as well.

do this, on your host system (rpi4 armv71 for me). Before building or starting containers...
```
curl http://ftp.us.debian.org/debian/pool/main/libs/libseccomp/libseccomp2_2.5.1-1_armhf.deb --output libseccomp2_2.5.1-1_armhf.deb
sudo dpkg -i libseccomp2_2.5.1-1_armhf.deb
```

see https://askubuntu.com/questions/1263284/apt-update-throws-signature-error-in-ubuntu-20-04-container-on-arm
for more details