Set-time-epoch result in invalid date when board boot without internet connection

General Discussions
1

Hi,

I was hunting for an issue why when bumped to dunfell on orangepi zero date/time is set to 1.1.1970. It makes troubles for us as we on first run create some certificates (ok we can wait until date/time is valid) but also other files which are created have date 1.1.1970 which is bit awkward. I read in comment in meta-mender commit: 8d204ccc4ce2edfca3b9774b18319c3acbf83f95 that it help to not perform fsck on every boot but according systemd code when timestamp with build time is used then when date/time is synced timestamp is updated and we shouldn’t see an issue. Or am I missing something? Thanks.

2

Hi @MarekBelisko as I recall the default in systemd is to use the timestamp of one of it’s source files as the default date when building. This caused problems where the system would automatically run an fsck since the date was close to correct but not actually correct. Changing the epoch value to 1/1/1970 eliminated the fsck as it just assumed that the file was intentionally created with that date. Or something like that anyway. I don’t know if this is still a problem but I think even poky does it this way now.

You may want to wait until time is synced before doing these steps. Even if you don’t start at 1/1/1970, the time/date stamps will be older than real time since the images are always created before you run them.

Drew

3

I asked on systemd mailing list and Lennart propose to patch fsck :slight_smile: https://lists.freedesktop.org/archives/systemd-devel/2020-October/045486.html I’m not against idea to set epoch time just it can confuse users that they will see somewhere in journalctl or systemctl logs with epoch date :smiley: so maybe it should be documented somewhere so people are aware of that. Thanks

4

You can actually disable the fsck by setting the following:

# cat /etc/e2fsck.conf
[options]
        broken_system_clock = true

So imo we could remove this and leave it up to the user to set the e2fsck.conf appropriately if they do not have a working RTC.

On dunfell, reproducible builds where introduced and what ever SOURCE_DATE_EPOCH is set to, this will be the time epoch in all produced binaries that support this. This time will also be wrong (but maybe less wrong in your case?) and the only way to get a sane time at boot is to have a working RTC :slight_smile:

5

AFAIK in reproducible builds SOURCE_DATE_EPOCH should be set to actual date/time then systemd takes care about setting more less correct date/time until ntp is started and adjust date/time to correct one. Should I create PR with removal of systemd_%.bbappend and documenting how to set fsck? Thanks.

6

about setting more less correct date/time

Yes, emphasis on more or less :slight_smile:, but it still will not be correct as it be based on a timestamp generated during build.

Also note that systemd-timesync will create the following:

/var/lib/systemd/timesync/clock

The modification time of this file indicates the timestamp of the last successful synchronization (or at least the systemd build date, in case synchronization was not possible).

Which it should use, if you have ever synced time before.

I vote in favor

7

The override discussed in this thread is still in place on master, scarthgap, and kirkstone.

The override causes an error message from systemd on boot:

Aug 19 13:07:15 myhostname systemd[1]: Current system time is further ahead 15y after build time, but cannot correct: Invalid argument

@mirzak @TheYoctoJester can you please provide guidance on whether this override should be removed in favor of overriding fsck behavior? Thanks!