bug#33639: ISO installer image is broken on i686

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

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