Yes I can always make an iso of the burn cd , but I wondered why the method Tom gave didn't work, and now your've answered it. Thanks.
I don't mind doing it the long way round but I just wanted to make sure I was not the person making a mistake.
John
Jason Greenwood wrote:
John,
Ok, sounds like the same thing I have encountered. Write the CD to an ISO image on your HDD. If you don't want to do this via the CLI, perhaps the easiest way to do it is to use the Copy CD function within K3B. Once you click the tab to copy a cd, tick the box that says create ISO image only. Once it has completed writing the CD to an ISO, run the md5 sum on that ISO and you should be able to get a result. Remember, CD burning in Linux is not an exact science.
From our local LUG archive (more details for you): ============= The implementation of the isofs in Linux is quite bad (e.g. the method of making inodes will prevent hardlinked files from ever being stored properly on an isofs). The kernel also has the habit (ever since the first version) of reading too much data from the device, i.e. it reads past end of file on the disk. Needless to say this can cause I/O errors (oh what a surprise). For this reason only cdrecord has a -pad option, which simply writes additional zeros past the end of the filesystem onto the disk. Of course, this also stuffs your md5 sums. Another bug in the kernel is that it can't properly detect end-of-file on CD media. These additional zeros will screw your md5.
For the record, all these are 100% identical:
cat /dev/cdrom | md5sum md5sum < /dev/cdrom dd if=/dev/cdrom bs=2k | md5sum dd </dev/cdrom bs=2k | md5sum
plus any more combinations everyone can think of. They either all work, or not at all. For current 2.4.18/2.4.19 kernels, they don't work reliably. Depending on how many blocks there are on the CD, reading will work, or fal with an I/O error (when the kernel tries to read past the end of the recorded bit stream on the media). Even if the read goes ok, unless you have happened to read precisely the correct number of bytes your md5 is screwed anyway. I have had kernels where cat /dev/cdrom resulted in a complete crash (kernel panick) right at the very end of reading.
In my experience the only way to get reliable md5 sums with cds is to take matters into my own hands. Download the scriptutils package/tar from my web site and use
writecd --blockread /dev/cdrom | md5sum
or cook your own. The trick is
dd bs=2k if=/dev/cdrom count=`isoinfo -i /dev/cdrom -d | awk ...`
This will force reading of the correct number of blocks from the disk media (or any disk file). Note it will only work with an isofs on the CD, not with any other filesystem.
Recently I got too fed up with this Linux isofs crap that I started to put ext2 onto the cds. Much easier and trouble free: create a 650MB or 700MB file filled with zeros (by reading from /dev/zero). Run mkfs -t ext2, don't forget -m0 as there really isn't any point in reserving blocks for the super user on a read-only filesystem. Loop-mount. Master your cd with cp, or rsync, or tar, or whatever, but no need to mess with mkisofs. Unmount. cdrecord file to cd, finished. Won't be readable by microsofties, but for my backups that's just as well.
==================================
Cheers
Jason
--
John Richard Smith
[EMAIL PROTECTED]
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
