> --pad=150 says to _NOT_ verify the last 150 sectors (that is, 300k) of the > iso. Instead, checkmedia assumes them to be all zero without actually > reading them. > > The reason is that many CD-drives have problems reading the last sectors of > an iso.
This is bordering on nonsense, sorry. The problem is in the Linux kernel, which tries to read blocks past the end of the last recorded block on the media, resulting in endless kernel I/O errors, and a permanently disabled DMA for this IDE device (yet another serious bug). My guess is Linux doesn't set up its DMA properly and reads the disk in N-block chunks, failing miserably when the total recording size has a chunk less than size N at the end. Any teenager can work out it's going to go bust on the last chunk. When you must read problematic disk like this, turn off DMA on that drive, it usually helps. You can do this when the reading is close to the end, to avoid reading the whole disk with your computer turned into a 80186 (mouse cursor movements: sometimes). As this problem has been around for over a decade and obviously nothing has changed, the same workarounds still apply. Option 1: make the ISO filesystem several blocks too large by adding zero-filled blocks at the end. As these blocks will never be accessed by the filesystem, you're save reading all your files. It's a pain in the arse though as soon as you read the whole ISO size back, eg for making md5 comparisons. The problem is that these additonal empty blocks still belong to the filesystem, so reading the whole filesystem is like very annoying again. > So, our CDs are created with an additional padding (= extra sectors) > at the end of the iso (150 sectors, as you might have guessed at this point). Looks like SUSE has chosen option 1. > You need to match the --pad given to tagmedia with what you give to mkisofs > and things should be fine. If not, checkmedia will return an md5sum error. See, you then also need to know how many blocks to ignore at the end for your precious checksums to work out, as you can't just look it up in the filesystem's size info. Indeed, SUSE-Linux-10.1-GM-x86_64-CD1.iso ends with 150 null-blocks, which are all part of the filesystem. The downloadable file has exactly the size of the filesystem, same goes for the md5 with it. Option 2: When you burn, make sure you burn additional null blocks AFTER THE END OF THE FILESYSTEM. You can a) dd bs=2048 count=150 if=/dev/zero >>yourimage.iso, or b) cdrecord padsize=150 -pad. With growisofs, you're onto a), unless you use a pipe/stdin construction. This 150%-reliably fixes up any Linux kernel-introduced trouble. One can argue about the 150, at some stage that was definitely not enough. Since I was so fed up with this rubbish I went to 2048 and haven't had trouble since. Of course, when you (or someone else) burn on Mickeysoft, you're sunk again. Option 3: actually fix the kernel. Perhaps in 2016 ;) Volker -- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
