Comment 6 for bug 1878422

fixrtc is originally in ubuntus upstream initramfs-tools, it took us quite some work to get it there and foundations was the team asking us to put it there because "all initrd's in ubuntu have to be based on initramfs-tools" so that broken(non-existing RTCs are covered everywhere ...

Do we not use initramfs-tools as a base anymore in the core20 initrds ?

Also note that fixrtc looks at the filesystem creation time or last mount time in the superblock of the found rootfs, while the additional fixrtc-mount script is a snapd specific add-onn in the initramfs-tools-ubuntu-core package (which is only used in core initrds) ...

I doubt /var/lib/systemd/timesync/clock is of any help with "last mount time of superblock is in the future" rootfs mounting errors (and their fallout, that on some boards ends up in unbootable systems). Unless you plan to replace /init of the initrd with systemd now ...

Where does the var/lib/systemd/timesync/clock file get its initial time from on i.e. boards that have never (and probably will never) been connected to a network (we have such customers) ?

If the clock is too far off any gpg calls will simply fail during first boot
(IIRC snapd nowadays has a hardcoded hack that makes it ignore gpg timestamps during seeding, but application snaps that use gpg internally will not have this) ...
If the clock is too far off in the other direction you easily hit issues with key expiration dates ...

Note I'm not opposed to get rid of fixrtc, it has always been a hack, but it is a reliable and well tested mechanism that is being used on arm devices since nearly a decade and I'd like us to avoid situations like we had in core18 ... where *all* potential hacks blindly got removed without any replacements and it took us 6-12 months to even get the basic regressions fixed again (like keeping a persistent hostname over reboots etc) ...