bug#33639: ISO installer image is broken on i686

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

Hi,

> https://alpha.gnu.org/gnu/guix/guixsd-install-0.16.0.i686-linux.iso.xz
> (I haven’t tried smaller padding.)

I downloaded it and get on "xorriso -indev":
  libisoburn: WARNING : ISO image size 481129s larger than readable size 479184s

So the lack of 2k blocks is 1945 = nearly 4 MiB.
This is suspiciously near to the default fifo size.

The content of cleartext files near the payload end looks plausible:
  /System/Library/CoreServices/.disk_label
  /System/Library/CoreServices/SystemVersion.plist
Whether the last file's content is as expected can only be told by
its reader program, i guess:
  /var/guix/db/db.sqlite

So for now it indeed looks like plain truncation and not like a hickup
somewhere in the middle of ISO writing.
  

Several distros use xorriso to build their 32 bit ISOs. No complaints.
So i asked on debian-cd and debian-live mailing lists whether the ISOs
for 32-bit systems are indeed made on 32-bit systems. The answer is
  "All our images have been made on amd64 for years now."

So i need a 32-bit GNU/Linux VM for regression tests.

Being an untalented sysadmin, this can last a while. (First searching
for old cheat sheets and then stepping into any possible puddle ...)


I would still appreciate a test with minmally sized fifo. Its outcome would
be a strong indication whether the Guix problem is related to the fifo
at all. The result can be checked by executing

  xorriso -indev ...path.to.iso...

and looking for message
  libisoburn: WARNING : ISO image size ...s larger than readable size ...s
If the difference is in the range of only 32s, then the fifo stays
main suspect.

Also, the xorriso messages of a run with grub-mkrescue add-on arguments

  -- -- -report_about all

would be very welcome.

--------------------------------------------------------------------------
(Be invited to stop reading here. Only code musings follow.)

I reviewed the fifo code in libisofs and found no obvious opportunity for
a bug that would drop the final fifo content rather than offering it to
libburn:
  https://dev.lovelyhq.com/libburnia/libisofs/raw/master/libisofs/buffer.c

(iso_ring_buffer_read() is exposed to libburn via libisofs/ecma119.c
 function bs_read() which serves as struct burn_source member (*read)()
 as defined in libburn/libburn.h.)

The condition for end of reading is a combination of
- no data are available in the ring buffer
- the writer has set the flag for having ended its work

        while (buf->size == 0) {
            ...
            if (buf->wend) {

The member buf->size is of type size_t. I.e. good for at least 4 GiB - 1
before it rolls over. Neither the fifo size nor the transaction size come
near to that number.
buf->wend is unsigned int :2 with defined values
  0 not finished, 1 finished ok, 2 finish with error


Have a nice day :)

Thomas