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.
I'll also confirm that it happens on poky + meta-qt5 when I have time.
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.
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
(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.
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.
(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
Url is now https://github.com/systemd/systemd/blob/main/src/core/main.c#L1634
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
I think this is resolved by https://git.openembedded.org/openembedded-core/commit/meta/recipes-core/systemd/?id=0f51fee4a5408c17cbaf827053f13d6c3b9dbc2c
Louis, That seems like a good patch for systemd. Can you check sysvinit since that's still our default init? ../Randy
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" }