Re: [Bug-xorriso] bug#33639: ISO installer image is broken on i686

[Thomas Schmitt]

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