Hi, First an observation from digging in pcmemtest/1.5-2/build64/Makefile: What about target grub-memtest.iso ? It has its own xorriso run and EFI System Partition image. I guess they need treatment for reproducibility, too.
Felix Zielcke wrote: > Here's the output for the 64bit ISO: > [...] > │ │ │ 00179000: eb3c 906d 6b66 732e 6661 7400 0204 0100 .<.mkfs.fat..... > │ │ │ 00179010: 0200 0200 20f8 0600 2000 0200 0000 0000 .... ... ....... > │ │ │ -00179020: 0000 0000 8000 296c 13ae 4d4d 454d 5445 ......)l..MMEMTE > │ │ │ +00179020: 0000 0000 8000 29d6 8629 594d 454d 5445 ......)..)YMEMTE > │ │ │ 00179030: 5354 2d45 5350 4641 5431 3220 2020 0e1f ST-ESPFAT12 .. > [...] > │ │ │ -0017aa00: 4d45 4d54 4553 542d 4553 5008 0000 a750 MEMTEST-ESP....P > │ │ │ -0017aa10: 4b54 4b54 0000 a750 4b54 0000 0000 0000 KTKT...PKT...... > │ │ │ +0017aa00: 4d45 4d54 4553 542d 4553 5008 0000 0951 MEMTEST-ESP....Q > │ │ │ +0017aa10: 4b54 4b54 0000 0951 4b54 0000 0000 0000 KTKT...QKT...... > │ │ │ 0017aa20: 4546 4920 2020 2020 2020 2010 0000 186a EFI ....j The clear text looks like EFI System Partition (ESP). The byte address 0x00179000 = 1,544,192 would roughly match the end of an ISO 9660 filesystem which only has the 1440 KiB of /boot/floppy.img as payload. So it would be roughly at the start of the partition in the ISO created by -append_partition 2 0xef ./esp.img A partition editor listing like /sbin/fdisk -l memtestx64.iso or a run of xorriso -indev memtestx64.iso -report_system_area plain would tell where partition 2 begins and whether the byte addresses are located in there. Assumed that the differences are indeed inside partition 2: The content of the appended partition image does not get altered by xorriso. So i would expect that differences stem from the creation of ./esp.img. Do i get it right from https://sources.debian.org/src/pcmemtest/1.5-2/build64/Makefile/#L121 that esp.img stems from /sbin/mkdosfs -n MEMTEST-ESP -F12 -C esp.img 4096 mcopy -s -i esp.img iso/EFI :: ? Assumed yes: We see in the first difference the string "MEMTEST-ESPFAT12" which would match the "Partition Volume Label" and "File system type" fields as of https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#Extended_BIOS_Parameter_Block The differing byte would then be a part of "Volume ID (serial number)". In man mkdosfs i read -i volume-id Sets the volume ID of the newly created filesystem; volume-id is a 32-bit hexadecimal number (for example, 2e24ec82). The default is a number which depends on the filesystem creation time. So consider to add an option -i to the mkdosfs run and give it either a constant number or a number which gets reproducibly derived from variable SOURCE_DATE_EPOCH. ---------------------------------------------------------------------- The other difference could be a neighbor of "directory volume label", which Wikipedia mentions as a kind of mirror of "Partition Volume Label". If i get it right then this is in the name and extension fields of a "Directory entry". The differing bytes would then be the timestamps "Create time" at offset 0x0E and "Last Modified time" at offset 0x16. Probably the date fields at 0x10 and 0x18 could show differences, too. But i am far off my usual playground now. Maybe Chris already knows a good trick to enforce values for those time and date fields in FAT filesystems. Have a nice day :) Thomas
