bug#33639: ISO installer image is broken on i686

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

Florian Pelz wrote:
> fdisk /gnu/store/4nrwajlpab4s8pdph4d77ww7716sa3ir-image.iso
> [...]
> GPT PMBR size mismatch (3231107 != 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 = 807777 ISO 9660 blocks
But the perceived size is
  3200392 / 4 = 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 = 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 web.

> ls -l on the result reports 1638600704.

  1638600704 / 2048 = 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 varying
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