As an example, on my pi, the initrd logs have the date as something from Nov 2019, then systemd detects this when it runs as /init after the initrd, and sets the time forward to when systemd was built to Feb 2020, which is better but still not good enough.
If I install a snap, then the mtime of /var/lib/snapd/ is updated to when I installed something, so I think that proves that if we had the initramfs change the time of the system to the mtime of /run/mnt/host/var/lib/snapd/ in run mode we would be much much closer.
I think actually we could try doing this in "the-tool" and eventually push this into snapd where it has better visibility for snapd early boot sequence hacks/tricks. I will try this out locally to see if it helps some of the issue I have been seeing with my pi booting and not being able to connect to network.
As an example, on my pi, the initrd logs have the date as something from Nov 2019, then systemd detects this when it runs as /init after the initrd, and sets the time forward to when systemd was built to Feb 2020, which is better but still not good enough.
If I install a snap, then the mtime of /var/lib/snapd/ is updated to when I installed something, so I think that proves that if we had the initramfs change the time of the system to the mtime of /run/mnt/ host/var/ lib/snapd/ in run mode we would be much much closer.
I think actually we could try doing this in "the-tool" and eventually push this into snapd where it has better visibility for snapd early boot sequence hacks/tricks. I will try this out locally to see if it helps some of the issue I have been seeing with my pi booting and not being able to connect to network.