From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Thomas Schmitt" Subject: bug#33639: ISO installer image is broken on i686 Date: Sat, 08 Dec 2018 13:42:53 +0100 Message-ID: <14249682530673393275@scdbackup.webframe.org> References: <87k1klar3e.fsf@gnu.org> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:56794) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gVbxl-0007In-JG for bug-guix@gnu.org; Sat, 08 Dec 2018 07:44:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gVbxi-0003QG-Dn for bug-guix@gnu.org; Sat, 08 Dec 2018 07:44:05 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:33467) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gVbxi-0003Q2-A6 for bug-guix@gnu.org; Sat, 08 Dec 2018 07:44:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87k1klar3e.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: 33639@debbugs.gnu.org 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