bug#35283: ISO images are not reproducible

Hi, Ludovic Courtès wrote: > AFAICS, setting SOURCE_DATE_EPOCH didn’t have a noticeable impact on > Xorriso, or at least it was overridden by the “-volume_date” options > that I pass. Probably. Among the automatic grub-mkrescue options for xorriso's mkisofs emulation is

bug#35283: ISO images are not reproducible

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

bug#35283: ISO images are not reproducible

Hi, > Files added by ‘grub-mkrescue’ are “out of our control” so we would need > to patch ‘grub-mkrescue’ to honor SOURCE_DATE_EPOCH, for example. Google shows that patches have been proposed. But they seem not to have made it into the source. Vladimir Serbinko's answer here

bug#33639: ISO installer image is broken on i686

Hi, Florian Pelz wrote: > Well this is strange. I got fine ISO images each time (fine with no > complaints from xorriso or fdisk and bootable in QEMU without errors), > but after dd’ing them to different USB flash drives each time I get > kernel output when inserting the flash drive: > [

bug#33639: ISO installer image is broken on i686

Hi, it seems to help if you explicitely set the timestamps of the "/" directory export SOURCE_DATE_EPOCH=1555311212 xorriso -outdev test.iso -map x /x \ -alter_date b-c 19700101 / -- \ -alter_date c 19700101 / -- ISOs made with these xorriso commands

bug#33639: ISO installer image is broken on i686

Hi, I wrote: > > If all files and directories have the same names and the same content, > > then xorriso runs with the same arguments and the same SOURCE_DATE_EPOCH > > value are supposed to create byte-identical result ISOs. Ludovic Courtès wrote: > I’ve tried setting it but that doesn’t make

bug#33639: ISO installer image is broken on i686

Hi, Florian Pelz wrote: > Yes, it seems fixed, I can confirm. Way back in december, Ludovic Courtès wrote: >...> Based on this and on a suggestion Ricardo made on IRC, I passed >...> -padding 10m and that solved the problem. \o/ Please do not forget to remove this -padding command. Florian

bug#33639: ISO installer image is broken on i686

Hi, > apologies for blaming Xorriso, which presumably never had > anything to do with it! I will not complain that this time it was not my fault. Have a nice day :) Thomas

bug#33639: ISO installer image is broken on i686

Hi, Ludovic Courtès wrote: > > Florian: could you check whether the patch below solves the problem for > > you? Florian Pelz wrote: > No, sadly not. Given the smell of a race condition, i would next try to let the VM wait 10 or 15 seconds after xorriso is finished and before it shuts down. Not

bug#33639: ISO installer image is broken on i686

Hi, Florian Pelz wrote: > fdisk /gnu/store/4nrwajlpab4s8pdph4d77ww7716sa3ir-image.iso > [...] > GPT PMBR size mismatch (3231107 != 3200391) will be corrected by write. > For the corrupt iso with lstat call: > and corrupt images alike. The GPT Protective MBR counts with block size 512 up to the

bug#33639: ISO installer image is broken on i686

Hi, > ‘lstat’ Probably this. > but that’s not quite a “shell”. If i could reproduce the problem then i would want a long time visible message about how large the ISO image file is after grub-mkrescue has ended successfully. This would give an opportunity to compare the size as produced in the

bug#33639: ISO installer image is broken on i686

Hi, aside from my problems with the building and testing after "guix pull" i also stand puzzled in front of the 8 files named "/gnu/.../build/vm.scm" which all start grub-mkrescue. If i'd succeed in reproducing the ISO image file truncation: Which vm.scm file would i have to modify in order to

bug#33639: ISO installer image is broken on i686

Hi, > It’s not reproducible because I “fixed” it: > > https://git.savannah.gnu.org/cgit/guix.git/commit/?id=178be030c0e4fdeac5e1c968b5c99d84bb4691db (This adds "-padding 10m" to the run of xorriso.) No. The padding only moves the missing end piece into a region of the image file where it does

bug#33639: ISO installer image is broken on i686

Hi, > Oops, that was an omission that I’ve just fixed. Sometimes you need a clueless test user to clean the pipes. I now succeeded in running the ISO production command, but the truncation problem is not reproducible here. Please re-consider local reasons ... yada yada ... my main suspect

bug#33639: ISO installer image is broken on i686

Hi, Ludovic Courtès wrote: > If you’re testing in a VM you might just as well download the GuixSD VM > image from . There i only see only "x86_64" for QEMU, not "i686" like with ISO or Binary. > Did you actually run “guix archive --authorize <

bug#33639: ISO installer image is broken on i686

Hi, it comes to me that i can get nearer to the Guix ISO production: # apt-get install grub-pc grub-efi-amd64-bin grub-efi-ia32-bin mtools ... # grub-mkrescue -o /tmp/test.iso /gnu xorriso 1.4.6 : RockRidge filesystem manipulator, libburnia project. ... ISO image produced: 652920

bug#33639: ISO installer image is broken on i686

Hi, just to report that i did not forget this problem: I have now a qemu-system-i386 VM with Debian GNU/Linux from debian-9.6.0-i386-netinst.iso without desktop environment and reachable via SSH. Very minimal. (I only did "apt-get install build-essential" to feel not lonely without C compiler

bug#33639: ISO installer image is broken on i686

Hi, > https://alpha.gnu.org/gnu/guix/guixsd-install-0.16.0.i686-linux.iso.xz > (I haven’t tried smaller padding.) I downloaded it and get on "xorriso -indev": libisoburn: WARNING : ISO image size 481129s larger than readable size 479184s So the lack of 2k blocks is 1945 = nearly 4 MiB. This

bug#33639: ISO installer image is broken on i686

Hi, > Based on this and on a suggestion Ricardo made on IRC, I passed > “-padding 10m” and that solved the problem. \o/ Ouchers. Do all files bear their expected content ? Especially the last one: /var/guix/db/db.sqlite If so, then something truncates the output stream of libisofs via libburn.

bug#33639: ISO installer image is broken on i686

Hi, i see that probably the kernel log talks of blocks of 512 bytes. So the minimum missing size shrinks to 2.3 and 1.4 MiB, respectively. I wrote: > > Please consider local reasons for truncated ISO images. Ludovic Courtès wrote: > I’ve thought about this but that seem highly unlikely at this

bug#33639: ISO installer image is broken on i686

Hi, > [ 215.199357] loop0: rw=524288, want=1903876, limit=1899264 This looks much like a truncated ISO image. (For what reason ever.) There are at least 4612 blocks = ~ 9 MiB missing. In the original message of https://issues.guix.info/issue/33639 the the minimum missing size is about 5 MiB.