From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 06 12:30:04 2018 Received: (at 33639) by debbugs.gnu.org; 6 Dec 2018 17:30:04 +0000 Received: from localhost ([127.0.0.1]:35975 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gUxTQ-0001h8-FC for submit@debbugs.gnu.org; Thu, 06 Dec 2018 12:30:04 -0500 Received: from mout.gmx.net ([212.227.15.15]:53745) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gUxTN-0001g7-Qr for 33639@debbugs.gnu.org; Thu, 06 Dec 2018 12:30:02 -0500 Received: from scdbackup.webframe.org ([91.8.172.165]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M5cMq-1hNzth3xbE-00xdzR; Thu, 06 Dec 2018 18:29:54 +0100 Date: Thu, 06 Dec 2018 18:29:19 +0100 From: "Thomas Schmitt" To: bug-xorriso@gnu.org Subject: Re: bug#33639: ISO installer image is broken on i686 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit References: <87k1kmipqk.fsf@gnu.org> In-Reply-To: <87k1kmipqk.fsf@gnu.org> Message-Id: <12559682391379993357@scdbackup.webframe.org> X-Provags-ID: V03:K1:81zAYHfDe1seI8XoQx3+DvWYfoKDYy1ouIHBW2HMHUI3aPGKGUu RReUXMZ60R6r3swqrnjCtw1L6fsmfqzKhSkuDPNb37uqFYaa/iIxCkf0KcvOU8yfnqJxUJe 5e/5YrHuVSNFGCeuSJdvFm9WMtwpVXe1HTK4SWdCaQQ9eTPeKR/dujhI92mnaGawHcZzJnt Y5F8tncG4yCj1KGoT+/xw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:vK5lvJEGJbs=:ZGouydoEQTTCjoW6sY5n6p swFSg/868EmbVe2AmfyFE8yDUY6H0nytlBm8+xy9WdJTdu7VJIkCJ4114yqLgMFLsqpd22oDe qeLLTXiIlAKfvQ+z0HN9p3Xw2N1jmwOCSRe0WpWdAzIrpG5zELCfWS6E+7NOPyaIK60hs+SUy MWy/WY2bokwhlkf3Aej1ZSuFJzphDQdqQRDAUXTk02etyli5qnzdr9/GOdW/IsPKoo5aUUU0K RJAttxZu+vqc4zURiP3GVnNTR7ULGgi0BQcsQ0W630NYrOfxF9IVx/nS5FlB8TFnk3iqnuoHL /YNpNbJinV5YMJ+7y+hkuUpvjquqRP5MwPehBToB/mLIR+ZPgyS1GuZNHCCu47fs7Dqp5fQfM 7AZNyAKmg6XfbrgnwDkxuGEcPbm+AmuWPImWYTXupFFtLeqhCx9k2fI5APL8rJcrS368tjSjr Xcr49ePIajIinSKUz+lTrweVslj2MepIX868mQho/MmLp30uqeteqfknLxRgSnAfLVtgT4bjp 1U4CjhMDJ4eXT7D2R8Xe2qKmWUflD1GbKuRQomEWrmcudpBK3TTqzGhB55rqSP3qyYtHO638s pf8xvGDMFRsUq2QD5FNOxziir7gOH/jK4qY/IXbB0HgBkehg2eSkb07CkVasQkcruTUtCWVRd 1jtUMC160Ou7MdaQptR1MXiMlcnSrdvOJ8rkN7j1IB0hWGJ14yC/8Q6Qd6l6hlAmsgB3DgS9c cQ8e1BUqFWbJWW06Pgx7rq3CMij22VHmxzpYA2qN1QeAUmi8f4+ttYjijF9qF2WKPkoofzC/4 t3OK7k8L2nBbvdwnOhHl81oulewHF0cbsY7EXXRxPOENggWtPxrhZU4UtHC6Dawyh3Wszg+tr eSSn5LQyYzqIQ9YUmnQaToSWJn9SGpZ8fyOmdC4lOFlTV5EkzlUAFBJChBhiaX X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 33639 Cc: 33639@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) 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