To have a "not too old" time immediately after boot is accomplished by sysfixtime, derived from most recent file date found.
Using a cron job, which touches a file like /etc/timestamp every day/hour, helps, not to be too far off after boot.
However, this does NOT help for the very first boot after flashing openwrt. Because there is no /etc/timestamp,
and initial system time might be even weeks "too old". I suspect, in this case initial system time is derived from build date of kernel.
To help here, I do the following procedure, when flashing a custom image, without keeping any settings, and having image available as /tmp/fw.bin:
...
cd /tmp
echo 1 > /etc/timestamp
tar c -z -f /etc/timestamp.tar.gz /etc/timestamp
sysupgrade -n -v -f /etc/timestamp.tar.gz fw.bin
This will cause an almost correct initial system time after running sysfixtime on reboot.
I suggest a similar, default procedure to integrate into sysupgrade, OR a new option, at least.
2 Likes
Hi,
Thanks for sharing this procedure; it's really helpful for those creating custom OpenWRT images.
I completely agree that the main problem is the first boot after flashing, when /etc/timestamp doesn't exist and sysfixtime can't reliably correct the time.
A solution that could make the process simpler and more standardized would be to add a new option to sysupgrade (as you have already proposed, as an always active option it would be better). This option, for example “--create-timestamp”, could:
Automatically create a /etc/timestamp file during flashing or firmware upgrade.
Ensure that sysfixtime finds a valid timestamp on the first boot and sets a "nearly correct" initial time.
This would automate the workaround you described manually, avoiding extra steps for the user and improving the overall first-boot experience.
I think this would be a great addition to sysupgrade, either as a default option or as an optional flag.
I wish you a Merry Christmas 
Thanks again for sharing!
1 Like