From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Thomas Schmitt" Subject: bug#35283: ISO images are not reproducible Date: Sun, 21 Apr 2019 10:17:59 +0200 Message-ID: <11935672730123242979@scdbackup.webframe.org> References: <87a7gk9tf4.fsf@gnu.org> Content-Type: text/plain; charset="utf-8" Return-path: Received: from eggs.gnu.org ([209.51.188.92]:42072) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hI7dr-00049X-1k for bug-guix@gnu.org; Sun, 21 Apr 2019 04:16:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hI7dq-00026R-3M for bug-guix@gnu.org; Sun, 21 Apr 2019 04:16:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:34037) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hI7dq-00026I-0f for bug-guix@gnu.org; Sun, 21 Apr 2019 04:16:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hI7dp-0006wO-PQ for bug-guix@gnu.org; Sun, 21 Apr 2019 04:16:01 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87a7gk9tf4.fsf@gnu.org> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: bug-xorriso@gnu.org Cc: 35283@debbugs.gnu.org Hi, > 833480cc1f vm: Reset file timestamps in ISO images. That's also a big solution for the problem of timestamps of synthetic files. I understand that your plan for reproducibility is to make timestamps completely insignificant. Radical but effective. But since you set in commit 6901b9248e SOURCE_DATE_EPOCH to 1980, why not use the same seconds value for the ISO file objects ? > 6901b9248e vm: Reset file timestamps of the EFI image in ISO images. Maybe the commit message should have mentioned that setting SOURCE_DATE_EPOCH not only influences mformat underneath grub-mkrescue, but also the run of xorriso, where it determines volume date timestamps and GPT individual UUIDs. (Other impacts of the variable get overridden by the -volume_date "all_file_dates" command in commit 833480cc1f.) > 52b5fe5bcf gnu: grub: 'grub-mkrescue' honors 'GRUB_FAT_SERIAL_NUMBER'. I still riddle why /efi.img in the 0.16.0 ISO has 1.4 MB of size but grub-mkrescue.c uses mformat -f 2880, which is supposed to produce a 2.8 MB FAT image. > 1b0b1651b1 gnu: mtools: 'mformat' initializes boot sector before writing How good are chances to bring such changes into upstream ? I ask in the advance assumption that we find a way to make the mformat image digestible for Florian's Macbook. (It is clear now that the difference between failure and success is in mformat versus mkfs.fat. But the exact point of failure is not found yet. I place my bet on the partition entry with start LBA 0.) Have a nice day :) Thomas