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
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
shows the creation date of the images as being 58 ago
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):
boot
establish network
run ntp-client to set initial time
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)
