From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Thomas Schmitt" Subject: bug#33639: ISO installer image is broken on i686 Date: Sun, 07 Apr 2019 23:35:16 +0200 Message-ID: <2660367208964033194@scdbackup.webframe.org> References: <20190407201849.74qtwvazknbsaklg@pelzflorian.localdomain> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([209.51.188.92]:48959) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hDFQR-0001qr-G7 for bug-guix@gnu.org; Sun, 07 Apr 2019 17:34:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hDFQQ-0004v1-G7 for bug-guix@gnu.org; Sun, 07 Apr 2019 17:34:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:35257) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hDFQQ-0004ur-9x for bug-guix@gnu.org; Sun, 07 Apr 2019 17:34:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <20190407201849.74qtwvazknbsaklg@pelzflorian.localdomain> 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, Florian Pelz wrote: > fdisk /gnu/store/4nrwajlpab4s8pdph4d77ww7716sa3ir-image.iso > [...] > GPT PMBR size mismatch (3231107 !=3D 3200391) will be corrected by write= . > For the corrupt iso with lstat call: > and corrupt images alike. The GPT Protective MBR counts with block size 512 up to the GPT backup header block, not counting itself at block 0. So in blocks of 2048, the expected size is 3231108 / 4 =3D 807777 ISO 9660 blocks But the perceived size is 3200392 / 4 =3D 800098 ISO 9660 blocks I wrote: > > retrieve the last size messages of xorriso: > For the corrupt iso with lstat call: > ISO image produced: 807777 sectors > Written to medium : 807777 sectors at LBA 0 > Within the VM lstat consistently reports 1654327296 for non-corrupt > and corrupt images alike. 1654327296 / 2048 =3D 807777 So from the view of the VM the ISO is as large as xorriso believes to have written and as the GPT announces as position of the backup header block. > > and the size of > > the ISO image file size when it is finally ready for exposure in the w= eb. > ls -l on the result reports 1638600704. 1638600704 / 2048 =3D 800098 This matches the perceived size from the fdisk complaint. > On the non-corrupt image after adding the lstat call, both lstat > within the VM and ls -l outside the VM print the same size: 1654327296 The fact that the VM always sees the expected size but the host sees varyi= ng sizes supports the suspicion that at the end of the VM its i/o buffers or virtual disk are not always properly flushed to the i/o system of the host= . The varying success smells like a race condition. Have a nice day :) Thomas