[Top][All Lists]

[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: Thu, 06 Dec 2018 18:29:19 +0100


> Based on this and on a suggestion Ricardo made on IRC, I passed
> “-padding 10m” and that solved the problem.  \o/

Ouchers. Do all files bear their expected content ?
Especially the last one: /var/guix/db/db.sqlite

If so, then something truncates the output stream of libisofs via libburn.
The only component that comes to my mind is the fifo between them.
The default fifo size is 4 MiB. Quite suspicious.

Try to reduce its size to the minimum by adding these grub-mkrescue

  -- -- -fs 64k -padding 64k

If the fifo is to blame, then a padding of 64k should suffice to protect
the valuable blocks from a premature end.

A bit off topic:

> the documentation of “-padding” suggests
> that this kind of problem is not uncommon.

It's normal purpose is to work around a traditional Linux kernel bug:

CDs written with write type Track-At-Once bear two unreadable blocks at
the end. Most CD drives report these blocks as part of the data range.
When Linux shall read a single block for isofs, it reads a larger chunk.
The chunk is not large enough to reach over the nominal end of the data
range, but it can reach the unreadable end blocks by mistake.
In this case Linux does not only miss the end blocks but also valid
payload blocks which are part of the filesystem. This yields I/O error.

The developer of cdrecord and the kernel people mistake this problem
for a "fuzziness" of a CD end by at most 2 seconds of audio play time.
This is wrong from reading the specs and from making experiments.
However, cdrecord introduced the tradition to add 150 blocks of padding
which would 2 seconds of sound.
As long as the read chunk of Linux is smaller than that, the padding
protects the operating system from touching the lead-out blocks of the
TAO track.

This cannot happen on hard disk or any optical media type other than CD.
If you write the CD by Session-At-Once it cannot happen. If you have one
of the rare CD drives which do not count the lead-out blocks to the
readable size of the CD, it cannot happen. (Currently 1 of my 7 drives
tells the truth.)

But who am i to stand against all others ?
So xorriso, too, adds 300 KiB of padding by default.

Have a nice day :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]