From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Thomas Schmitt" Subject: bug#33639: ISO installer image is broken on i686 Date: Wed, 19 Dec 2018 15:51:57 +0100 Message-ID: <17182683634737195681@scdbackup.webframe.org> References: <87tvj9wr1v.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]:42773) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gZdDk-0004Lr-K6 for bug-guix@gnu.org; Wed, 19 Dec 2018 09:53:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gZdDb-0004Wt-0O for bug-guix@gnu.org; Wed, 19 Dec 2018 09:53:09 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:49866) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gZdDa-0004WA-7O for bug-guix@gnu.org; Wed, 19 Dec 2018 09:53:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87tvj9wr1v.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, > It’s not reproducible because I “fixed” it: > https://git.savannah.gnu.org/cgit/guix.git/commit/?id=178be030c0e4fdeac5e1c968b5c99d84bb4691db (This adds "-padding 10m" to the run of xorriso.) No. The padding only moves the missing end piece into a region of the image file where it does not matter for the filesystem payload files. The ISO filesystem's meta data and the partition tables would still claim the missing bytes of the image file, if the problem occured. E.g. xorriso notices the mismatch in the ISO to which you pointed me for download and which was most probably produced with -padding 10m: $ xorriso -indev guixsd-install-0.16.0.i686-linux.iso ... libisoburn: WARNING : ISO image size 481129s larger than readable size 479184s ... libburn : SORRY : Read start address 481128s larger than number of readable blocks 479184 ... The GPT in the ISO says that its backup header is at 512-byte block 1,924,515 = block 481,128.75 in units of 2048 bytes. Highest file block is 475879 + 87 = 475966 File data lba: 0 , 475879 , 88 , 180224 , '/var/guix/db/db.sqlite' which is a bit more than than 10 MiB before the expected image file end. Given the lack of 1945 blocks at the image file end, the payload file end is still more than 6 MB away from the escarpment. ----------------------------------------------------------------------- But the ISO which i produced myself is healthy in that aspect. The used software version is obviously before the 10 MiB padding. The ISO contains as many bytes -r--r--r-- 2 root root 1024141312 Jan 1 1970 before_guix_pull.iso as the ISO filesystem believes to cover, including the padding: Media summary: 1 session, 500069 data blocks, 977m data, 2187m free Highest data file block is 499788 + 87 = 499875 : File data lba: 0 , 499788 , 88 , 180224 , '/var/guix/db/db.sqlite' which means that at most 194 blocks are expected to follow the end of this file, not 10 MiB. The GPT in the image says that its backup header block is at 512-byte address 2,000,275 which is 500,068.75 in blocks of 2048 bytes. So the inner size counters and image file size do match exactly. This was done with guix from guix-binary-0.16.0.i686-linux.tar.xz and with authorized ci.guix.info.pub. > guix pull --commit=676c3adc14f63df0f7a549e518ac87481c0f3e37 After "guix pull" the ISO production command indulges in building and testing endlessly. You will have to give me instructions how to get back to the ~ 12 minutes of ISO production time which i had before trying "guix pull". Have a nice day :) Thomas