From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Subject: bug#33639: ISO installer image is broken on i686 Date: Fri, 07 Dec 2018 23:51:01 +0100 Message-ID: <87k1klar3e.fsf@gnu.org> References: <87k1kmipqk.fsf@gnu.org> <12559682391379993357@scdbackup.webframe.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:50407) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gVOyY-0002Zy-Ub for bug-guix@gnu.org; Fri, 07 Dec 2018 17:52:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gVOyX-0007zv-TZ for bug-guix@gnu.org; Fri, 07 Dec 2018 17:52:02 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:33145) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gVOyX-0007zf-Oa for bug-guix@gnu.org; Fri, 07 Dec 2018 17:52:01 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <12559682391379993357@scdbackup.webframe.org> (Thomas Schmitt's message of "Thu, 06 Dec 2018 18:29:19 +0100") 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: Thomas Schmitt Cc: bug-xorriso@gnu.org, 33639@debbugs.gnu.org Hello! "Thomas Schmitt" skribis: >> Based on this and on a suggestion Ricardo made on IRC, I passed >> =E2=80=9C-padding 10m=E2=80=9D and that solved the problem. \o/ > > Ouchers. Do all files bear their expected content ? > Especially the last one: /var/guix/db/db.sqlite It looks good, and there are no I/O errors left (I mounted it and run =E2=80=9Ctar=E2=80=9D over it.) Note that the image is now available here: https://alpha.gnu.org/gnu/guix/guixsd-install-0.16.0.i686-linux.iso.xz (I haven=E2=80=99t tried smaller padding.) > 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. OK, I=E2=80=99ll try to test this, but note that I=E2=80=99ll be largely un= available for a week. >> the documentation of =E2=80=9C-padding=E2=80=9D 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. I see, thanks for explaining! Ludo=E2=80=99.