[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#33639: ISO installer image is broken on i686
From: |
Thomas Schmitt |
Subject: |
bug#33639: ISO installer image is broken on i686 |
Date: |
Sat, 08 Dec 2018 13:42:53 +0100 |
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
- bug#33639: ISO installer image is broken on i686, (continued)
- bug#33639: ISO installer image is broken on i686, Ludovic Courtès, 2018/12/18
- bug#33639: ISO installer image is broken on i686, Thomas Schmitt, 2018/12/18
- bug#33639: ISO installer image is broken on i686, Ludovic Courtès, 2018/12/19
- bug#33639: ISO installer image is broken on i686, Thomas Schmitt, 2018/12/19
- bug#33639: ISO installer image is broken on i686, Thomas Schmitt, 2018/12/20
- bug#33639: ISO installer image is broken on i686, Ludovic Courtès, 2018/12/21
- bug#33639: ISO installer image is broken on i686, Thomas Schmitt, 2018/12/21
- bug#33639: ISO installer image is broken on i686, Ludovic Courtès, 2018/12/06
- bug#33639: ISO installer image is broken on i686, Thomas Schmitt, 2018/12/06
- bug#33639: ISO installer image is broken on i686, Ludovic Courtès, 2018/12/07
- bug#33639: ISO installer image is broken on i686,
Thomas Schmitt <=
bug#33639: ISO installer image is broken on i686, swedebugia, 2018/12/06