Mailinglist Archive: opensuse-factory (757 mails)

< Previous Next >
Re: [opensuse-factory] tagmedia question
  • From: Volker Kuhlmann <hidden@xxxxxxxxxxxxxxx>
  • Date: Tue, 9 May 2006 14:16:40 +1200
  • Message-id: <20060509021640.GA5704@xxxxxxxxxxxxxxx>
> --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

Of course, when you (or someone else) burn on Mickeysoft, you're sunk

Option 3: actually fix the kernel. Perhaps in 2016 ;)


Volker Kuhlmann is list0570 with the domain in header Please do not CC list postings to me.

< Previous Next >