Re: Partial success and strange partial failure -was [Re: Physically have install DVD set. Want ISO's from which they came.]
Hi,
> I would like to have more information about this "read ahead bug", but
> I cannot find a full bug report or similar technical discussion of it.
dd count= will not save you from it. It is in the block device
driver of Linux for CD reading.
CD media can bear sectors which do not represent data blocks.
(Most known is the CD-DA format. You cannot dd a bought music CD.)
The CD write type TAO produces a CD track, which at its end has two
CD sectors which do not represent data blocks either. Nevertheless
they are announced by the medium's table-of-content as part of the
track.
Linux reads CD tracks in large chunks (i assume 128 KB). Believing to
know the number of readable blocks from the table-of-content, it often
tries to read the unreadable last two blocks of a TAO track.
This read attempt of the last track chunk then fails, which is ok
so far. There are no user data in those blocks. Everything is stored
in the blocks before.
But Linux is not smart enough to repeat the read attempt with only
the number of blocks which are required from filesystem driver or
from userland process. Instead it cries "I/O error" and drops the
whole last chunk (with up to 126 KB valid data, i believe).
Therefore, all CD burn programs on Linux add padding by default,
to keep all valuable data out of the last chunk.
A wrong diagnosis by Joerg Schilling in the last century lead to
the default size of 300 KB padding. Actually it depends on the
chunk size of the Linux driver.
And actually, it could have been fixed in Linux long time ago.
Pressed CD-ROMs and CDs written with write type SAO do not trigger
this read-ahead-bug.
... whew, history.
> which if any source file will eventually contain a fix for it?
As said, the bug is normally avoided by adding sacrifices to the
end of the track. 150 blocks of zeros to please the god of bugs.
But reading this yields too many blocks, instead of too few.
So MD5 will be wrong, if not appropriately truncated.
> Does it also affect udf file systems?
It affects any kind of data, written with CD write type TAO.
UDF read-write filesystems are usually written onto formatted
CD-RW, where TAO is not applicable.
Nevertheless, TAO can happen when you burn a filesystem image file
onto CD. You can avoid the problem by using option -sao with
cdrecord, wodim, or xorrecord.
> Thomas states that "Debian i386 images are ISO 9660 filesystems" so I
> assume that this bug workaround is still required for them.
It rather works around the fact that most media types let you
read more data than just the user payload. Either because of the
traditional 300 KB padding, or because the medium type demands
alignment to full 32 KB, or because the medium does not tell
the size of the last burn session at all (e.g. DVD+RW, BD-RE).
So if your MD5 sum shall match, then you must enforce that it is
computed from the same number of bytes as the original ISO image
has. That's the job of dd option count=.
> Can you recommend anywhere I can read to learn more
> about the Debian DVD filesystems?
The i386 ISOs are more or less what is described in
http://www.syslinux.org/wiki/index.php/ISOLINUX
plus all the files of Debian d-i, beginning with kernel and
initial RAM-disk, and ending at the package files.
They get treated by xorriso like would be done by
http://www.syslinux.org/wiki/index.php/Doc/isolinux#HYBRID_CD-ROM.2FHARD_DISK_MODE
Debian ISOs get created by an expert package called "debian-cd",
which has its own mailing list:
https://lists.debian.org/debian-cd/
The options used with the mkisofs-emulation of xorriso are recorded
in the file
/.disk/mkisofs
of each bootable Debian ISO image. Have "man xorrisofs" ready.
The amd64 ISOs additionally have EFI boot equipment. Inspired by
http://mjg59.dreamwidth.org/11285.html
My knowledge on byte-level is collected in
http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/view/head:/doc/boot_sectors.txt
Have a nice day :)
Thomas
Reply to: