From: "Ludovic Courtès" <ludo@gnu.org>
To: Thomas Schmitt <scdbackup@gmx.net>
Cc: bug-xorriso@gnu.org, 33639@debbugs.gnu.org
Subject: bug#33639: ISO installer image is broken on i686
Date: Fri, 07 Dec 2018 23:51:01 +0100 [thread overview]
Message-ID: <87k1klar3e.fsf@gnu.org> (raw)
In-Reply-To: <12559682391379993357@scdbackup.webframe.org> (Thomas Schmitt's message of "Thu, 06 Dec 2018 18:29:19 +0100")
Hello!
"Thomas Schmitt" <scdbackup@gmx.net> 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’.
next prev parent reply other threads:[~2018-12-07 22:52 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-06 0:02 bug#33639: ISO installer image is broken on i686 Ludovic Courtès
2018-12-06 7:19 ` Ludovic Courtès
2018-12-06 10:34 ` Ludovic Courtès
2018-12-06 14:08 ` Thomas Schmitt
2018-12-06 15:34 ` Ludovic Courtès
2018-12-06 16:59 ` Thomas Schmitt
2018-12-15 18:40 ` Thomas Schmitt
2018-12-15 19:24 ` Thomas Schmitt
2018-12-16 15:52 ` Ludovic Courtès
2018-12-16 16:52 ` Thomas Schmitt
2018-12-18 11:16 ` Ludovic Courtès
2018-12-18 21:45 ` Thomas Schmitt
2018-12-19 14:05 ` Ludovic Courtès
2018-12-19 14:51 ` Thomas Schmitt
2018-12-20 13:38 ` Thomas Schmitt
2018-12-21 20:44 ` Ludovic Courtès
2018-12-21 21:42 ` Thomas Schmitt
2019-04-07 20:18 ` pelzflorian (Florian Pelz)
2019-04-07 21:35 ` Thomas Schmitt
2019-04-08 8:50 ` Ludovic Courtès
2019-04-09 22:13 ` pelzflorian (Florian Pelz)
2019-04-10 11:17 ` Thomas Schmitt
2019-04-10 21:23 ` pelzflorian (Florian Pelz)
2019-04-12 21:26 ` Ludovic Courtès
2019-04-13 6:37 ` Thomas Schmitt
2019-04-13 13:46 ` pelzflorian (Florian Pelz)
2019-04-13 16:20 ` Thomas Schmitt
2019-04-14 21:43 ` Ludovic Courtès
2019-04-15 6:07 ` pelzflorian (Florian Pelz)
2019-04-15 8:16 ` Thomas Schmitt
2019-04-15 8:35 ` Thomas Schmitt
2019-04-19 11:40 ` bug#35283: ISO images are not reproducible Ludovic Courtès
2019-04-19 12:46 ` Thomas Schmitt
2019-04-20 22:57 ` Ludovic Courtès
2019-04-21 8:17 ` Thomas Schmitt
2019-04-21 16:42 ` Ludovic Courtès
2019-04-21 18:44 ` Thomas Schmitt
2019-04-20 23:03 ` bug#35283: [PATCH] mformat: initialize boot sector before writing it Ludovic Courtès
2019-04-21 16:32 ` bug#35283: [PATCH] grub-mkrescue: Allow users to specify a FAT serial number Ludovic Courtès
2019-04-14 15:47 ` bug#33639: ISO installer image is broken on i686 Ludovic Courtès
2019-04-15 16:54 ` pelzflorian (Florian Pelz)
2019-04-15 17:55 ` Thomas Schmitt
2019-04-16 9:57 ` Gábor Boskovits
2019-04-16 21:01 ` Ludovic Courtès
2019-04-17 9:03 ` pelzflorian (Florian Pelz)
2018-12-06 16:28 ` Ludovic Courtès
2018-12-06 17:29 ` Thomas Schmitt
2018-12-07 22:51 ` Ludovic Courtès [this message]
2018-12-08 12:42 ` Thomas Schmitt
2018-12-06 9:35 ` swedebugia
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k1klar3e.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=33639@debbugs.gnu.org \
--cc=bug-xorriso@gnu.org \
--cc=scdbackup@gmx.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).