X509: certificate has expired or is not yet valid

I just put a core18 image onto an SD using the RPI Imager. I put it in a Pi4 and it boots fine to the “press enter to configure” screen. I connected to the wireless network, disabled ipv6 and used dhcp for ipv4. It asked for my SSO email address, and I get this.

I waited some time (while writing this post) and tried again and it worked. Looks like NTP issue? Perhaps the store login part of the setup should wait for the clock to update before trying to login? I don’t think I did anything out of the ordinary.

Once I got it setup and logged in over ssh:

popey@localhost:~$ snap changes
ID   Status  Spawn                      Ready                      Summary
1    Done    58 days ago, at 16:25 UTC  58 days ago, at 16:26 UTC  Initialize system state
2    Error   58 days ago, at 16:26 UTC  58 days ago, at 16:26 UTC  Initialize device
3    Done    today at 10:17 UTC         today at 10:17 UTC         Initialize device
4    Done    today at 10:17 UTC         today at 10:23 UTC         Auto-refresh 4 snaps
5    Done    today at 10:32 UTC         today at 10:32 UTC         Refresh all snaps: no updates

Note the “58 days ago”.

to avoid a too massive clock drift on unconnected images we have the fixrtc script in the initrd, that tries to force the clock to the creation time of the file system … once the network connection is up it should fully update the clock to the current date …

as it happens
http://cdimage.ubuntu.com/ubuntu-core/18/stable/current/
shows the creation date of the images as being 58 ago :slight_smile:

seems we have a race condition here between ntp (or rather systemd-networkd|-timesyncd) and subiquity as you guessed …

Do the pi images use ntpd, or ntp-client, or both, or some other mechanism for NTP? For systems that never have the correct time on boot, i.e. do not have an RTC with battery, the standard mechanism on bootup or network establishment is (or rather was when I last did it myself):

  1. boot
  2. establish network
  3. run ntp-client to set initial time
  4. start ntpd to continually monitor and adjust time as needed

If you rely on ntpd alone then this will take some time between starting up and actually setting a meaningful time because it does two things: it monitors the current offset with multiple servers, once a baseline is established it gradually smears the clock to cause the time to eventually coalesce. This smearing of time is the main reason we should run an initial ntp-client call before starting the ntpd because smearing takes some protracted period to achieve a reasonable approximation of local time - it is not instant where ntp-client is.

I think it’s just because it got on the network during subiquity first run, and I typed in my (short) email address and pressed enter before ntp had a chance to run. Perhaps NTP should be force-run between joining the network and signing into SSO.

the latter … they use systemd-timesyncd … i dont think there is any way to force syncronization with timesyncd …

what you can do is query the status …

ogra@cm3:~$ systemctl status systemd-timesyncd.service|grep Status
   Status: "Synchronized to time server 91.189.89.199:123 (ntp.ubuntu.com)."

but relying on that would make non-networked installs hang forever (though given that you can not do the SSO dance without network anyway thats probably neglectable)