I'm sorry, this was probably already covered and I'm just forgetful,
but why not do this in do_install?

Alex

On Tue, 12 Nov 2024 at 20:22, Gaël PORTAY <[email protected]> wrote:
>
> When systemd is started, it sets the system clock to epoch to ensure the
> system clock is reasonably initialized if no working RTC.
>
> As init process, systemd sets epoch very early to the more recent
> timestamp of[1]:
>  - the build time of systemd (-Dtime-epoch)
>  - the modification time ("mtime") of /var/lib/systemd/timesync/clock
>    (systemd-timesyncd)
>  - the modification time ("mtime") of /usr/lib/clock-epoch (systemd)
>
> The first epoch timestamp is hard-coded at build-time by the systemd
> recipe (using either SOURCE_DATE_EPOCH, git-tag, or NEWS modification
> time[2]).
>
> The second epoch timestamp is maintained at run-time if the system runs
> systemd-timesyncd.
>
> This implements the third epoch timestamp at image build-time, by
> touching the timestamp file /usr/lib/clock-epoch from the package
> post-install script.
>
> [1]: 
> https://github.com/systemd/systemd/commit/863098fdc9cd91e4f760085356ac02c4b7ba6df1
> [2]: https://github.com/systemd/systemd/blob/v256/meson.build#L804-L825
>
> Signed-off-by: Gaël PORTAY <[email protected]>
> ---
> Hello,
>
> With this patch, one can have a better sane default time set by systemd
> very very very early in the boot (i.e. even before systemd outputs its
> version!).
>
>         # dmesg
>         (...)
>         [    3.347641] Run /sbin/init as init process
>         [    3.350435]   with arguments:
>         [    3.350440]     /sbin/init
>         [    3.350443]   with environment:
>         [    3.350447]     HOME=/
>         [    3.350451]     TERM=linux
>         [    3.431275] EXT4-fs (mmcblk2p2): re-mounted. Opts: (null)
>         [    3.523997] EXT4-fs (mmcblk2p4): recovery complete
>         [    3.527828] EXT4-fs (mmcblk2p4): mounted filesystem with ordered 
> data mode. Opts: (null)
>         [    3.694440] systemd[1]: System time before build time, advancing 
> clock.
>         [    3.714755] systemd[1]: systemd 250.5+ running in system mode 
> (+PAM -AUDIT -SELINUX -APPARMOR +IMA -SMACK -SECCOMP -GCRYPT -GNUTLS +OPENSSL 
> +ACL +BLKID -CURL -ELFUTILS -FIDO2 -IDN2 -IDN -IPTC +KMOD -LIBCRYPTSETUP 
> +LIBFDISK -PCRE2 -PWQUALITY -P11KIT -QRENCODE -BZIP2 -LZ4 -XZ -ZLIB +ZSTD 
> -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=hybrid)
>
> Thus, one can do time-based related things offline or before the system
> clock is set by the network (if trusting the time does not matter that
> much for sure).
>
> This happens if the system has no hardware clock or if it is way too far
> in the past and if using an old versions of systemd; systemd v250.5 sets
> the system time to April 28, 2022 5:53:22 PM (1651168402).
>
> Also, please set REPRODUCIBLE_TIMESTAMP_ROOTFS to any appropriate value
> if enabling reproducible-builds (the default). Otherwise, bitbake sets
> the timestamp to Friday, March 9, 2018 12:34:56 PM (1520598896, i.e.
> REPRODUCIBLE_TIMESTAMP_ROOTFS[1]).
>
> **Important**: It works on scarthgap and kirkstone; "all" image files
> are timestamped to Tuesday, April 5, 2011 11:00:00 PM (1302044400, i.e.
> SOURCE_DATE_EPOCH_FALLBACK[2]) on master branch; that branch appears to
> not use REPRODUCIBLE_TIMESTAMP_ROOTFS anymore. Therefore, an update of
> the SOURCE_DATE_EPOCH_FALLBACK value should work (I guess).
>
>         root@qemux86-64:~# stat /usr/lib/clock-epoch /etc/timestamp
>           File: /usr/lib/clock-epoch
>           Size: 0               Blocks: 0          IO Block: 1024   regular 
> empty file
>         Device: fd00h/64768d    Inode: 837         Links: 1
>         Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    
> root)
>         Access: 2011-04-05 23:00:00.000000000 +0000
>         Modify: 2011-04-05 23:00:00.000000000 +0000
>         Change: 2011-04-05 23:00:00.000000000 +0000
>           File: /etc/timestamp
>           Size: 15              Blocks: 2          IO Block: 1024   regular 
> file
>         Device: fd00h/64768d    Inode: 510         Links: 1
>         Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    
> root)
>         Access: 2011-04-05 23:00:00.000000000 +0000
>         Modify: 2011-04-05 23:00:00.000000000 +0000
>         Change: 2011-04-05 23:00:00.000000000 +0000
>
>         SOURCE_DATE_EPOCH_FALLBACK ??= "1302044400"
>
>         Supports Unix timestamps in seconds, milliseconds, microseconds and 
> nanoseconds.
>         Assuming that this timestamp is in seconds:
>         GMT: Tuesday, April 5, 2011 11:00:00 PM
>         Your time zone: Wednesday, April 6, 2011 1:00:00 AM GMT+02:00 DST
>         Relative: 14 years ago
>
> [1]: 
> https://git.openembedded.org/openembedded-core/tree/meta/conf/bitbake.conf#n689
> [2]: 
> https://git.openembedded.org/openembedded-core/tree/meta/conf/bitbake.conf#n688
>
> Changes since v1:
>  - use pkg_postinst() to touch file /usr/lib/clock-epoch instead of the
>    rootfs post-command rootfs_systemd_timestamp()
>
> Note: v1 is titled "classes: rootfs-postcommands: set better sane time
> to systemd"
>
> https://patchwork.yoctoproject.org/project/oe-core/patch/[email protected]/
>
> Kind Regards,
> Gaël
>  meta/recipes-core/systemd/systemd_256.6.bb | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/meta/recipes-core/systemd/systemd_256.6.bb 
> b/meta/recipes-core/systemd/systemd_256.6.bb
> index 68f15ab065..f288bedc9e 100644
> --- a/meta/recipes-core/systemd/systemd_256.6.bb
> +++ b/meta/recipes-core/systemd/systemd_256.6.bb
> @@ -867,6 +867,10 @@ ALTERNATIVE_TARGET[runlevel] = "${base_bindir}/systemctl"
>  ALTERNATIVE_LINK_NAME[runlevel] = "${base_sbindir}/runlevel"
>  ALTERNATIVE_PRIORITY[runlevel] ?= "300"
>
> +pkg_postinst:${PN}:append () {
> +       touch $D${libdir}/clock-epoch
> +}
> +
>  pkg_postinst:${PN}:libc-glibc () {
>         if ${@bb.utils.contains('PACKAGECONFIG', 'myhostname', 'true', 
> 'false', d)}; then
>                 sed -e '/^hosts:/s/\s*\<myhostname\>//' \
> --
> 2.47.0
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#207066): 
https://lists.openembedded.org/g/openembedded-core/message/207066
Mute This Topic: https://lists.openembedded.org/mt/109541328/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

  • ... Gaël PORTAY via lists . openembedded . org
    • ... Alexander Kanavin via lists.openembedded.org

Reply via email to