From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Thomas Schmitt" Subject: bug#33639: ISO installer image is broken on i686 Date: Thu, 06 Dec 2018 18:29:19 +0100 Message-ID: <12559682391379993357@scdbackup.webframe.org> References: <87k1kmipqk.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]:36166) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gUxUU-0003UH-1e for bug-guix@gnu.org; Thu, 06 Dec 2018 12:31:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gUxUP-0001RV-2c for bug-guix@gnu.org; Thu, 06 Dec 2018 12:31:09 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:59950) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gUxUM-0001Q8-HD for bug-guix@gnu.org; Thu, 06 Dec 2018 12:31:03 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87k1kmipqk.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, > 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. The only component that comes to my mind is the fifo between them. The default fifo size is 4 MiB. Quite suspicious. Try to reduce its size to the minimum by adding these grub-mkrescue arguments: -- -- -fs 64k -padding 64k If the fifo is to blame, then a padding of 64k should suffice to protect the valuable blocks from a premature end. -------------------------------------------------------------------- A bit off topic: > the documentation of “-padding” suggests > that this kind of problem is not uncommon. It's normal purpose is to work around a traditional Linux kernel bug: CDs written with write type Track-At-Once bear two unreadable blocks at the end. Most CD drives report these blocks as part of the data range. When Linux shall read a single block for isofs, it reads a larger chunk. The chunk is not large enough to reach over the nominal end of the data range, but it can reach the unreadable end blocks by mistake. In this case Linux does not only miss the end blocks but also valid payload blocks which are part of the filesystem. This yields I/O error. The developer of cdrecord and the kernel people mistake this problem for a "fuzziness" of a CD end by at most 2 seconds of audio play time. This is wrong from reading the specs and from making experiments. However, cdrecord introduced the tradition to add 150 blocks of padding which would 2 seconds of sound. As long as the read chunk of Linux is smaller than that, the padding protects the operating system from touching the lead-out blocks of the TAO track. This cannot happen on hard disk or any optical media type other than CD. If you write the CD by Session-At-Once it cannot happen. If you have one of the rare CD drives which do not count the lead-out blocks to the readable size of the CD, it cannot happen. (Currently 1 of my 7 drives tells the truth.) But who am i to stand against all others ? So xorriso, too, adds 300 KiB of padding by default. Have a nice day :) Thomas