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 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/22323666239272333...@scdbackup.webframe.org