14019 2020-08-21 12:19:51 +0000 Default the target time to the time of the build host 2025-12-03 07:30:29 +0000 1 1 7 Build System, Metadata & Runtime Runtime build-appliance unspecified x86 Multiple RESOLVED FIXED Medium enhancement 5.3 1 matthewzmd mingli.yu bunk louis.rannou matthewzmd randy.macleod richard.purdie --- --- No (bug/feature does not impact docs) oldest_to_newest 88008 0 matthewzmd 2020-08-21 12:19:51 +0000 This bug is discovered in WR Linux built with meta-qt5 on a rpi4. The current behavior is, when building on a hardware target (rpi4 & intel-x86-64 in my case), the system time gets defaulted to some time in the past. It impacted meta-qt5's qtcreator, as some of the files in /usr/lib64/mkspecs/common/* have a modification date from the build host, therefore resulting make complaining: `make: Warning: File '/usr/lib64/mkspecs/common/gcc-base.conf' has modification time Xs in the future.` It also makes a general sense to have the target sharing the same system time with the build host. 88009 1 matthewzmd 2020-08-21 12:21:18 +0000 I'll also confirm that it happens on poky + meta-qt5 when I have time. 88010 2 randy.macleod 2020-08-21 12:35:51 +0000 The idea is that near the end of image construction on the build host, we'd touch a file in the target FS being built. Then on the target, check on first boot that the target time is later than the reference file's timestamp. Timezones for the build host and deployed target may be different and that could be a problem but we'll see if we can handle that. I'd assume that we are using UTC and GMT when building but I haven't checked. 88016 3 richard.purdie 2020-08-22 07:24:46 +0000 Have a look at meta/classes/rootfs-postcommands.bbclass:ROOTFS_POSTPROCESS_COMMAND += "rootfs_update_timestamp; " and /etc/timestamp also: meta/recipes-core/initscripts/initscripts-1.0/save-rtc.sh:TIMESTAMP_FILE=/etc/timestamp meta/recipes-core/initscripts/initscripts-1.0/bootmisc.sh:TIMESTAMP_FILE=/etc/timestamp 88017 4 bunk 2020-08-22 07:37:06 +0000 (In reply to comment #2) > The idea is that near the end of image construction on the build host, we'd > touch a file in the target FS being built. Then on the target, check on > first boot that the target time is later than the reference file's > timestamp. I assume you are talking about non-systemd distributions? systemd does this already. 88018 5 randy.macleod 2020-08-22 11:01:03 +0000 Systemd is the init system in this case. The RPI4 doesn't have a battery-backed clock unless you buy an extra part. Matthew will use the meta-rpi layer rather than the WR BSP to see if the problem still happens and we can debug from there. 88019 6 bunk 2020-08-22 11:11:31 +0000 (In reply to comment #5) > Systemd is the init system in this case. > > The RPI4 doesn't have a battery-backed clock unless you buy an extra part. > > Matthew will use the meta-rpi layer rather than the WR BSP to see if the > problem still happens and we can debug from there. He should get one of these two messages logged: https://github.com/systemd/systemd/blob/master/src/core/main.c#L1582-L1586 94992 7 richard.purdie 2023-02-23 15:25:27 +0000 Url is now https://github.com/systemd/systemd/blob/main/src/core/main.c#L1634 94994 8 richard.purdie 2023-02-23 15:28:59 +0000 We need to ensure the timestamp of https://github.com/systemd/systemd/blob/main/src/shared/clock-util.c#L134 i.e. #define EPOCH_FILE "/usr/lib/clock-epoch" is correct 102279 9 louis.rannou 2025-06-17 12:42:52 +0000 I think this is resolved by https://git.openembedded.org/openembedded-core/commit/meta/recipes-core/systemd/?id=0f51fee4a5408c17cbaf827053f13d6c3b9dbc2c 102292 10 randy.macleod 2025-06-18 19:21:30 +0000 Louis, That seems like a good patch for systemd. Can you check sysvinit since that's still our default init? ../Randy 103465 11 mingli.yu 2025-12-03 07:30:29 +0000 With systemd: https://git.openembedded.org/openembedded-core/commit/meta/recipes-core/systemd/?id=0f51fee4a5408c17cbaf827053f13d6c3b9dbc2c With sysvinit: we can set below logic in conf/local.conf REPRODUCIBLE_TIMESTAMP_ROOTFS = "" And then the target will get a more reasonable sane time based on below logic. # Can be used to create /etc/timestamp during image construction to give a reasonably # sane default time setting rootfs_update_timestamp () { if [ "${REPRODUCIBLE_TIMESTAMP_ROOTFS}" != "" ]; then # Convert UTC into %4Y%2m%2d%2H%2M%2S sformatted=`date -u -d @${REPRODUCIBLE_TIMESTAMP_ROOTFS} +%4Y%2m%2d%2H%2M%2S` else sformatted=`date -u +%4Y%2m%2d%2H%2M%2S` fi echo $sformatted > ${IMAGE_ROOTFS}/etc/timestamp bbnote "rootfs_update_timestamp: set /etc/timestamp to $sformatted" }