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 17:59:39 +0100 Message-ID: <13661682393159200289@scdbackup.webframe.org> References: <87va46is9h.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]:52190) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gUx1U-0003TH-F5 for bug-guix@gnu.org; Thu, 06 Dec 2018 12:01:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gUx1M-0006f1-Kd for bug-guix@gnu.org; Thu, 06 Dec 2018 12:01:10 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:59937) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gUx1K-0006d2-LW for bug-guix@gnu.org; Thu, 06 Dec 2018 12:01:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87va46is9h.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, i see that probably the kernel log talks of blocks of 512 bytes. So the minimum missing size shrinks to 2.3 and 1.4 MiB, respectively. I wrote: > > Please consider local reasons for truncated ISO images. Ludovic Courtès wrote: > I’ve thought about this but that seem highly unlikely at this point. It still looks like writing of the ISO image aborted prematurely. Do you have the xorriso messages from the grub-mkrescue run ? (If there are none, add the following three arguments to the grub-mkrescue run: -- -- -report_about update The second "--" shall work around an intermediate version of grub-mkrescue which ate the first "--" instead of forwarding it to xorriso. ) Reasoning: > libisoburn: WARNING : ISO image size 475636s larger than readable size 473456s > File data lba: 0 , 475356 , 88 , 180224 , '/var/guix/db/db.sqlite' When the ISO is assessed by libisoburn, its nominal block count is 192 blocks higher than the end of the last file. Insofar ok. But the ISO image file is smaller than that. After the warning, libisoburn corrects the displayed size to the readable size. So the number in this subsequent message is rather insignificant: > Media summary: 1 session, 473456 data blocks, 925m data, 45.6g free (Only good that you also showed above warning message.) The nominal count is recorded in the Primary Volume Descriptor, the equivalent of a superblock. (Byte offset in the ISO file is 32768+80, first as 4 byte little-endian, then again as 4 byte big-endian.) The readable size is based on the byte size of the ISO file. At ISO production time, the nominal block count is determined by libisofs in a first dry-run. In the subsequent real production run, libisofs sticks to the determined file sizes of the first run, even if some file changed size inbetween. It would truncate or pad the copied file bytes to the planned size. Directory data are written as assessed in the first run. So from normal operation of libisofs it is guaranteed that the written amount of data is the same as the nominal amount. ----------------------------------------------------------------------- Possible glitches would be that libisofs skips to write some scheduled data blocks, or that libburn drops blocks which were submitted by libisofs. Both scenarios do not give me an idea how the difference between 32 bit and 64 bit systems could be involved. The theory of intermediately missing data blocks could be verified or defuted by checking the content of the last file which sits in the readable area. If it bears the expected content, then no blocks were skipped or dropped inbetween. So please look in the file listing for the last file which begins before block 473456 and does not step over that limit by adding its "Blocks" count (exact hit on the limit is ok). If the filesystem refuses to obtain it, then use dd bs=2048 skip=$Startlba count=$Blocks to cut it out from the ISO and then truncate it to the reported "Filesize". In any case compare its content with the original. If the contents match, then we have a flat premature end of file. In this case there should be error messages from xorriso or its libraries. (In case of GNU xorriso, the libraries are fixely compiled in from source.) Have a nice day :) Thomas