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 is suspiciously near to the default fifo size. The content of cleartext files near the payload end looks plausible: /System/Library/CoreServices/.disk_label /System/Library/CoreServices/SystemVersion.plist Whether the last file's content is as expected can only be told by its reader program, i guess: /var/guix/db/db.sqlite So for now it indeed looks like plain truncation and not like a hickup somewhere in the middle of ISO writing. Several distros use xorriso to build their 32 bit ISOs. No complaints. So i asked on debian-cd and debian-live mailing lists whether the ISOs for 32-bit systems are indeed made on 32-bit systems. The answer is "All our images have been made on amd64 for years now." So i need a 32-bit GNU/Linux VM for regression tests. Being an untalented sysadmin, this can last a while. (First searching for old cheat sheets and then stepping into any possible puddle ...) I would still appreciate a test with minmally sized fifo. Its outcome would be a strong indication whether the Guix problem is related to the fifo at all. The result can be checked by executing xorriso -indev ...path.to.iso... and looking for message libisoburn: WARNING : ISO image size ...s larger than readable size ...s If the difference is in the range of only 32s, then the fifo stays main suspect. Also, the xorriso messages of a run with grub-mkrescue add-on arguments -- -- -report_about all would be very welcome. -------------------------------------------------------------------------- (Be invited to stop reading here. Only code musings follow.) I reviewed the fifo code in libisofs and found no obvious opportunity for a bug that would drop the final fifo content rather than offering it to libburn: https://dev.lovelyhq.com/libburnia/libisofs/raw/master/libisofs/buffer.c (iso_ring_buffer_read() is exposed to libburn via libisofs/ecma119.c function bs_read() which serves as struct burn_source member (*read)() as defined in libburn/libburn.h.) The condition for end of reading is a combination of - no data are available in the ring buffer - the writer has set the flag for having ended its work while (buf->size == 0) { ... if (buf->wend) { The member buf->size is of type size_t. I.e. good for at least 4 GiB - 1 before it rolls over. Neither the fifo size nor the transaction size come near to that number. buf->wend is unsigned int :2 with defined values 0 not finished, 1 finished ok, 2 finish with error Have a nice day :) Thomas
