systemd: set time epoch for reproducible builds
PATCH 1/1 systemd: set time epoch for reproducible builds
Systemd embeds a timestamp which is used to impose a minimum bound on the system time during boot. Normally this comes from stat'ing the NEWS file included with the systemd source, but this makes the build non-reproducible. Pass in $SOURCE_DATE_EPOCH to use a deterministic timestamp when reproducible builds are enabled.
--- package/systemd/systemd.mk | 5 +++++ 1 file changed, 5 insertions(+)
package/systemd/systemd.mk +5 -0
@@ -40,6 +40,11 @@ SYSTEMD_CONF_OPTS += \ --with-default-dnssec=no \ --without-python +ifeq ($(BR2_REPRODUCIBLE),y) +SYSTEMD_CONF_OPTS += \ + --with-time-epoch=$(SOURCE_DATE_EPOCH) +endif + SYSTEMD_CFLAGS = $(TARGET_CFLAGS) -fno-lto # Override paths to a few utilities needed at runtime, to
Signature · 1 line
2.15.0
PATCH 1/1 systemd: set time epoch for reproducible builds
Hello,
Quoted 7 lines · John Keeping
Systemd embeds a timestamp which is used to impose a minimum bound on the system time during boot. Normally this comes from stat'ing the NEWS file included with the systemd source, but this makes the build non-reproducible. Pass in $SOURCE_DATE_EPOCH to use a deterministic timestamp when reproducible builds are enabled.
Signed-off-by John Keeping <[email protected]>
Hum, systemd uses 'stat -c %Y NEWS', which returns:
%Y time of last data modification, seconds since Epoch
I just extracted the systemd tarball with Buildroot, and:
output/build/systemd-234 (master)$ stat NEWS
File: NEWS
Size: 378872 Blocks: 744 IO Block: 4096 regular file
Device: 10302h/66306d Inode: 34473900 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ thomas) Gid: ( 1000/ thomas)
Access: 2017-11-17 10:51:07.369562977 +0100
Modify: 2017-07-12 16:01:10.000000000 +0200
Change: 2017-11-17 10:51:07.510563710 +0100
Birth: -
So the modification date is July 12th, and not today. So for a given systemd release, the output of "stat -c %Y NEWS" is therefore stable, and will not change.
Look:
$ stat -c %Y NEWS 1499868070
$ date -d @1499868070 +%Y-%m-%d 2017-07-12
So I'm not sure why your patch would be necessary. Could you check what's going on?
Thanks!
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
PATCH 1/1 systemd: set time epoch for reproducible builds
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas Petazzoni <[email protected]> writes:
Hi,
Quoted 8 lines
$ stat -c %Y NEWS 1499868070$ date -d @1499868070 +%Y-%m-%d 2017-07-12So I'm not sure why your patch would be necessary. Could you check what's going on?
Exactly my thought as well. Tar should restore the modification time. If you use OVERRIDE_SRCDIR things may naturally be different though, I'm not sure git/rsync handles that correct.
Signature · 1 line
Bye, Peter Korsgaard
PATCH 1/1 systemd: set time epoch for reproducible builds
In reply to John KeepingHello,
Quoted 10 lines · John Keeping
Systemd embeds a timestamp which is used to impose a minimum bound on the system time during boot. Normally this comes from stat'ing the NEWS file included with the systemd source, but this makes the build non-reproducible. Pass in $SOURCE_DATE_EPOCH to use a deterministic timestamp when reproducible builds are enabled.
Signed-off-by John Keeping <[email protected]>--- package/systemd/systemd.mk | 5 +++++ 1 file changed, 5 insertions(+)
Following the feedback from Peter Korsgaard and myself, and the lack of additional justification, I've marked this patch as "Rejected" in our patch tracking system.
John: don't hesitate to get back to us with a more detailed explanation of the issue if you have not been convinced by Peter's explantion and mine.
Thanks!
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 systemd: set time epoch for reproducible builds
Quoted 12 lines · Thomas Petazzoni
Quoted 10 lines · John Keeping
Systemd embeds a timestamp which is used to impose a minimum bound on the system time during boot. Normally this comes from stat'ing the NEWS file included with the systemd source, but this makes the build non-reproducible. Pass in $SOURCE_DATE_EPOCH to use a deterministic timestamp when reproducible builds are enabled.
Signed-off-by John Keeping <[email protected]>--- package/systemd/systemd.mk | 5 +++++ 1 file changed, 5 insertions(+)
Quoted 7 lines
Following the feedback from Peter Korsgaard and myself, and the lack of additional justification, I've marked this patch as "Rejected" in our patch tracking system.
John: don't hesitate to get back to us with a more detailed explanation of the issue if you have not been convinced by Peter's explantion and mine.
I'm convinced!
The original problem I was investigating wasn't actually reproducible builds, but was related to the time set by systemd when the hardware clock has an invalid time. It seems that e2fsck will update the superblock timestamp when it is in the future, which means that programming an ext4 filesystem image will trigger systemd-fsck-root.service to attempt a reboot halfway through the first boot.
I've solved this by setting options.broken_system_clock in e2fsck.conf, but not before going down the root of trying to get systemd and the rootfs to agree on a timestamp, which resulted in this patch to make the timestamp included in systemd consistent with the rest of buildroot.