[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-xorriso] bug#33639: ISO installer image is broken on i686
From: |
Ludovic Courtès |
Subject: |
Re: [Bug-xorriso] bug#33639: ISO installer image is broken on i686 |
Date: |
Fri, 07 Dec 2018 23:51:01 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) |
Hello!
"Thomas Schmitt" <address@hidden> skribis:
>> 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
It looks good, and there are no I/O errors left (I mounted it and run
“tar” over it.)
Note that the image is now available here:
https://alpha.gnu.org/gnu/guix/guixsd-install-0.16.0.i686-linux.iso.xz
(I haven’t tried smaller padding.)
> 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
> arguments:
>
> -- -- -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.
OK, I’ll try to test this, but note that I’ll be largely unavailable for
a week.
>> 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.
I see, thanks for explaining!
Ludo’.
- Re: [Bug-xorriso] bug#33639: ISO installer image is broken on i686, (continued)
- Re: [Bug-xorriso] bug#33639: ISO installer image is broken on i686, Thomas Schmitt, 2018/12/16
- Re: [Bug-xorriso] bug#33639: ISO installer image is broken on i686, Ludovic Courtès, 2018/12/18
- Re: [Bug-xorriso] bug#33639: ISO installer image is broken on i686, Thomas Schmitt, 2018/12/18
- Re: [Bug-xorriso] bug#33639: ISO installer image is broken on i686, Ludovic Courtès, 2018/12/19
- Re: [Bug-xorriso] bug#33639: ISO installer image is broken on i686, Thomas Schmitt, 2018/12/19
- Re: [Bug-xorriso] bug#33639: ISO installer image is broken on i686, Thomas Schmitt, 2018/12/20
- Re: [Bug-xorriso] bug#33639: ISO installer image is broken on i686, Ludovic Courtès, 2018/12/21
- Re: [Bug-xorriso] bug#33639: ISO installer image is broken on i686, Thomas Schmitt, 2018/12/21
Re: [Bug-xorriso] bug#33639: ISO installer image is broken on i686, Ludovic Courtès, 2018/12/06