Hi, Vagrant Cascadian wrote: > I haven't looked into it too deeply, but got the basically the same > results as currently showing on: > > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/pcmemtest.html
Looks again like the FAT directory entries. The byte address is sufficiently above the 1.4 MiB of ISO 9660 payload to be in partition 2. We see the directory names "BOOT" and "EFI", and the file name "BOOTX64" with extension "EFI". The differences are at offsets 0x0f, 0x10, 0x12, 0x17, 0x18 after the name start bytes. According to https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#Directory_entry that would be timestamp fields. 0x0f : belongs to the 16 bit of "Create time" beginning at offset 0x0e. Values as little endian: 0x9a91 <-> 0xaa91 Hour:Minute:Second 19:20:34 <-> 21:20:34 0x10 : 16 bit of "Create date". Values as little endian: 0x544c <-> 0x544d Year/Month/Day 2022/02/12 <-> 2022/02/13 0x12 : 16 bit of "Last access date". 2022/02/12 <-> 2022/02/13 0x17 : 16 bit of "Last modified time" beginning at 0x16. 19:20:34 <-> 21:20:34 0x18 : 16 bit of "Last modified date". 2022/02/12 <-> 2022/02/13 So for some reasons the timestamps of files do not stay stable. Since the timestamps of the filesystem label (a pseudo file name) staid stable, i would now rather suspect mcopy and not mkdosfs as culprit. ------------------------------------------------------------------------- So the task seems to be to find out how to force timestamps with this line from build*/Makefile: mcopy -s -i esp.img iso/EFI :: Google brings me to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837044 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900410 where Chris Lamb fought such effects and let mtools obey SOURCE_DATE_EPOCH. Was this change not enough ? Does tests.reproducible-builds.org use an older version of mcopy ? Have a nice day :) Thomas
