Troubleshooters.Com and T.C Linux Library Present

Coasterless CD Burning

Copyright (C) 2002, 2003, 2004, 2005 by Steve Litt
[ Linux Library | Troubleshooters.Com | Email Steve Litt | Copyright Notice ]
[ See also Installing Your ATAPI CDRW Drive in Linux ]

Contents:

Executive Summary


Editor's Note:

9/15/2005: The -dao argument to cdrecord makes your recordings even more likely to be universally readable. Thank you to Dillon Jones for pointing this out to me.

12/27/2004: Recent developments in the Linux world have made even -pad insufficient for many burning tasks. I now also recommend padsize=63s. I'd like to thank Troubleshooters.Com readers Jim Prior and Enrique Perez-Terron for pointing this out to me.

2/17/2004: Until 2/17/2003 the contents of this page were inaccurate. Until that date, this page presented procedures that tended to produce correct CD's, but in fact just played the odds. As of 2/17/2003, this page displays procedures which we now believe (but we've been wrong before) completely addresses CD burning, image making and verification. A big thank you goes out to John Desmond, who was nice enough to let me know about the isoinfo program. An additional thank you goes to Tony Becker, who first let me know that dd was indeed better than cat for CD device reading, because dd gives complete control over block size and quantity.



A "coaster" is defined as a defective CD. It's called a coaster because its only use is as a coaster to put drinks on.

CD burning can seem iffy -- intermittent with respect to time, hardware, and many other things. We're really dealing with two problems:

  1. CD burns that are wrong or non-portable
  2. CD reads that are inaccurate
The burning problem is solved by adding the padsize=63s and -pad arguments to the cdrecord program. The reading problem is solved by deducing the block size and number of blocks from the isoinfo program.

You will meet many people who do not perceive a problem, and will assume the problem is yours personally. It is not. Depending on hardware and software, a great many people cannot successfully burn and checksum a CD, and have it come out correctly. A great many people cannot copy a CD to an iso file without changing the checksum. But if you work with enough CD's on enough systems, you will run into this problem, and when you do, this page contains the solution.

Sections of this page show how to use the -pad and padsize= arguments to the cdrecord utility, and also a script called rawread that consistently reads the right amount of data off the CDROM device.

Disclaimer

Obviously, you use this document at your own risk. I am not responsible for any damage or injury caused by your use of this document, or caused by errors and/or omissions in this document. If that's not acceptable to you, you may not use this document. By using this document you are accepting this disclaimer.

Accurately Reading a CD Device

Accurate CD device reads are essential to CD creation. For instance, when you test your newly burned CD with md5sum, the data you read from /dev/cdrom must be accurate, or you'll get a false error alarm. Also, many CD's are burned off ISO images created from other CDs. If those original CD's were read incorrectly, then the resulting ISO's are incorrect, and every duplicate made from those ISO's is incorrect. Accurate CD reading is essential.

Most bad CD device reads are caused by either:
  1. Reading too few or too many blocks of the CD device
  2. Inability to read the last block. 
This section explains how to consistently read the correct number of blocks.

The only reliable method I've found to find the true end of the CD is with the isoinfo utility. Specifically, you use the -d and -i options.  -d prints information from the primary volume  descriptor. -i specifies the path of the image to investigate, typically /dev/cdrom. Here's an example, using CD1 of the Red Hat 5.1 I bought directly from Red Hat:

[slitt@mydesk slitt]$ isoinfo -d -i /dev/cdrom
CD-ROM is in ISO 9660 format
System id: LINUX
Volume id: Red Hat Linux/Intel 5.1.5
Volume set id:
Publisher id: Red Hat Software, (888) RED-HAT1
Data preparer id: Red Hat Software, (888) RED-HAT1
Application id: Red Hat Linux/Intel 5.1.5
Copyright File id:
Abstract File id:
Bibliographic File id:
Volume set size is: 1
Volume set seqence number is: 1
Logical block size is: 2048
Volume size is: 329989
NO Joliet present
Rock Ridge signatures version 1 found
[slitt@mydesk slitt]$

In the preceding, notice the lines saying "Logical block size is: 2048" and "Volume size is: 329989". This means there are 329989 blocks on the ISO, each of which is 2048 bytes. For this CD, you can read exactly the right amount of data from it with the following dd command:
dd if=/dev/cdrom bs=2048 count= 329989
The preceding command reads all valid data from the CD to stdout.

This is great, but requires the user to manually run isoinfo, copy the values to the dd command, and run the dd command. Too much work. The following is a bash script, which I call rawread, that reads any CD to stdout:

#!/bin/sh
device=$1

blocksize=`isoinfo -d -i $device | grep "^Logical block size is:" | cut -d " " -f 5`
if test "$blocksize" = ""; then
echo catdevice FATAL ERROR: Blank blocksize >&2
exit
fi

blockcount=`isoinfo -d -i $device | grep "^Volume size is:" | cut -d " " -f 4`
if test "$blockcount" = ""; then
echo catdevice FATAL ERROR: Blank blockcount >&2
exit
fi

command="dd if=$device bs=$blocksize count=$blockcount conv=notrunc,noerror"
echo "$command" >&2
$command

The preceding script (which I call rawread) parses the output of isoinfo for the blocksize and blockcount, assigns them to variables, and then runs the proper dd command to copy data from the device (first argument of the rawread command) to stdout.

To use this script to create an iso, do the following:
rawread /dev/cdrom > myiso.iso
 To use this script to check the md5sum of the CD, do the following:
rawread /dev/cdrom | md5sum
To summarize, many supposed CD writing problems are actually CD device reading problems, either an incorrect CD device read during checksum testing of that CD, or incorrect creation of the ISO from which the CD was created. Most inaccurate reads are caused either by reading too few or too many blocks, or by padding errors on the CD itself. The padding errors are a CD burning problem which is discussed later on this page, but the inaccurate block count can be corrected by acquiring the block size and block count from the isoinfo program, and then using those values in the dd command. This section presented a script, called rawread , which automates the isoinfo to dd process, correctly reading all the data on the device defined by its argument to stdout. By using the rawread command defined in this section, you'll be assured of reading the correct number of blocks on the CD.

Writing a CD

My experience is that once your CD writer is set up correctly and get your write speed right, the vast majority of write problems, especially the intermittent ones, come from lack of the -dao, -pad or padsize= arguments to the cdrecord program. This section explains the phenomenon and how to fix it.

If you're having problems with CDRW setup, see Installing Your ATAPI CDRW Drive in Linux.

The following command tells you the SCSI number of your CDRW, and also assures you that your CD works:

cdrecord -scanbus
If everything's working, the result should look something like this:
 
[slitt@mydesk slitt]$ cdrecord -scanbus
Cdrecord 1.9 (i586-mandrake-linux-gnu) Copyright (C) 1995-2000 Jörg Schilling
Linux sg driver version: 3.1.17
Using libscg version 'schily-0.1'
scsibus0:
        0,0,0     0) 'ATAPI   ' 'CD-R/RW CRW6206A' '1.2A' Removable CD-ROM
        0,1,0     1) *
        0,2,0     2) *
        0,3,0     3) *
        0,4,0     4) *
        0,5,0     5) *
        0,6,0     6) *
        0,7,0     7) *
[slitt@mydesk slitt]$

As you can see, in this example my SCSI device number is 0,0,0. Later versions of Mandrake (Mandrake 9.0, for instance), for some reason place the CD on 0,3,0., so don't assume it will always be 0,0,0.

NOTE

Later versions of the Linux kernel require you to identify the device differently. For instance, on my Mandrake 10 box I need to identify it like this:
dev=ATA:1,0,0
rather than the old fashioned
dev=1,0,0


First, find the right speed, which is the lower of the CDRW drive's capability or the CDR/CDRW media's capability. Remember that your writer has less speed capability for rewritables, so use that lower speed when writing CDRW media. With CDRW's, always blank the CD:

cdrecord dev=0,0,0 speed=10 blank=fast padsize=63s -pad -dao -v -eject
The preceding command blanks only the necessary parts of the disk (blank=fast) at a speed of 10, and it does this to device 0,0,0 (change this if your cdrecord -scanbus indicated a different number). Obviously, change the 10 if your rewrite speed (lesser of device or media) is not 10.

NOTE

You can blank the CD at the same time as you record just by including the blank=fast argument in the cdrecord command to burn the CD.

Next, burn the CD from the ISO:

cdrecord dev=0,0,0 speed=10 padsize=63s -pad -dao -v -eject myimage.iso
Unless your CDRW device has a hardware "burnproof" or "buffer underflow prevention" feature, do not do other work on the machine while burning the CD. At 10x speed the burn will take only 7 minutes, so this isn't much of an imposition. Likewise, unless you have these features, do not burn at fast speeds when the source ISO is on a network drive.
 
NOTE

There are many ways to burn a CD, including applications like xcdroast and gtoaster. Most are good, so use whichever suits your needs. Just remember the basic principles from this section:

  • Burn at the right speed
  • Pad properly (padsize=63s and -pad)
  • Use disk at once (-dao)
  • Unless your burner prevents buffer underflow, do no other work while you're burning.

Make sure the CD is properly padded

According to the cdrecord program's man page, Linux has a read-ahead buffer bug as described in the following exerp from the cdrecord man page:

       -pad   If  the track is a data track, 15 sectors of zeroed data will be
added to the end of this and each subsequent data track. In
this case, the -pad option is superseded by the padsize= option.
It will remain however as a shorthand for padsize=15s. If the
-pad option refers to an audio track, cdrecord will pad the
audio data to be a multiple of 2352 bytes. The audio data
padding is done with binary zeroes which is equal to absolute
silence.

-pad remains valid until disabled by -nopad.

padsize=#
Set the amount of data to be appended as padding to the next
track to #. Opposed to the behavior of the -pad option, the
value for padsize= is reset to zero for each new track. See fs=
option for possible arguments. Use this option if your CD-drive
is not able to read the last sectors of a track or if you want
to be able to read the CD on a Linux system with the ISO-9660
filesystem read ahead bug. If an empty file is used for track
data, this option may be used to create a disk that is entirely
made of padding.

Note the bolded text in the preceding man page. Those "I/O  error" messages you get toward the end of a CD are caused by a known bug which can be worked around by adding the -pad  and padsize=63s arguments to your cdrecord command.

Depending on the configuration of the ISO image from which the CD is burned, those I/O errors might result in corruption of the last file on the CD, or all files might be correct but the md5sum result of /dev/cdrom might differ from that of the original ISO. Often a CD burned without the -pad or padsize= argument will md5sum perfectly on one machine, and inaccurately on another.

WARNING

The mkisofs program also has  a -pad  argument, and it is the default for the same reasons described  above. Unless you have an excellent reason, never defeat that default.

Those not experiencing problems often don't use -pad and/or padsize=63s because it doesn't seem to be needed. Then, when they loan out their installation CD's, the installs fail on some machines. Ughhh.

So unless you have an excellent reason not to, always use -pad and padsize=63s. The command should look something like this:
cdrecord dev=0,0,0 speed=10 padsize=63s -pad -dao -v -eject /home/myuid/myiso.iso

Disk at Once

Your CD recordings will be much more likely to be universally readable if recorded in the disk at once mode rather than the default track at once. Note that disk at once is synonomous with session at once. To specify disk at once, you use the -dao argument to cdrecord. This argument helps clarify to CD readers where the last block is.
cdrecord dev=0,0,0 speed=10 padsize=63s -pad -dao -v -eject /home/myuid/myiso.iso

Summary

To burn a CD correctly, you must take care of the following:

The padding is what most people miss. They miss it because in a great many situations lack of padding causes no problem. But when it does, it takes the form of a hard to troubleshoot intermittent. Always pad.

Once your CD is burned, you need to test it to verify it's an exact copy of the ISO image from which it was made. Read on...

Testing a CD:

The definitive test for a CD you just burned is to compare its checksum with that of the ISO from which it was burned. Recalling the rawread script from the Accurately Reading a CD Device section, your CD is an accurate reproduction of the ISO file if the numbers produced by these two commands match:
md5sum myiso.iso
rawread /dev/cdrom | md5sum
If they match, you've burned a winner.

But sometimes you need to verify the ISO itself. Read on...

Verifying an ISO

Garbage in, garbage out.

If your ISO is wrong, every CD you burn from that ISO will be wrong. If you're making SWAG for your LUG's booth at a regional trade show, this could be several hundred coasters. Worse yet, these coasters might be "almost right", and either bomb during installation or possibly install faulty Linux. Your ISO images must be verified to be correct.

There are different verification methods depending on the way the ISO came into being. When downloading an ISO image of a free software distribution, the web site usually publishes the md5sum value for that image. If humanly possible, for every ISO you have, find the published md5sum value and compare it to that.

This is vital because ISO images typically go through all sorts of generations. For instance, Bill downloads the Mandrake ISO for CD 1 on his T1 at work. Bill burns a Mandrake CD off the downloaded ISO and brings it to your LUGs Installfest. Unfortunately, Bill forgot to use the padsize=63s and -pad argument when using cdrecord.

At the Installfest, Phil uses the cat program to copy /dev/cdrom to myiso.iso, thereby getting the wrong block count, but he doesn't md5sum to verify. Phil burns several CD's off the ISO he made from Bill's CD, but unfortunately once he too forgets to use padsize=63s and -pad, or maybe -dao.

Will obtains one of Phil's CD's, and does everything right. He uses isoinfo to obtain the block size and count, and uses dd with the size and count to create an ISO. Fortunately for Will (actually unfortunately), his system reads even unpadded CD's correctly, so there are no I/O errors to clue him in that Phil forgot to pad. Will creates several properly padded CDs from that ISO, and for each CD he uses isoinfo and dd (or better yet, the rawread script described in the Accurately Reading a CD Device section of this page), to pipe the CD device to the md5sum utility, verifying that the checksum on the CD's are the same as the checksum on the ISO he made from Phil's CD. Will makes 20 such CD's and distributes them to his Installfestmates.

Unfortunately for Will and the 20 other people, although his CD's matched the ISO perfectly, the ISO did not match the original Mandrake ISO. In fact, successive errors by Bill and Phil further damaged the ISO. Some of those using Will's CD's encountered glitchy problems, and blamed it on either Linux or on Mandrake. Some using Will's CD's got perfect results, so Will never thought to check for bad data on his CD's. After all, the CD's all matched the checksum of his master ISO.

If there exists a published md5sum for a CD image, always check your master ISO against that published md5sum value. After all, garbage in, garbage out.

Sometimes there's no published checksum. If, for backup purposes, you create an ISO image of a crucial proprietary program, obviously there will be no published checksum. In that case, the best you can do is create an ISO from the proprietary program's install CD. And I mean a factory printed, non-counterfeit CD. If there have been additional generations, you probably already have garbage in. And of course, if there have been additional generations, you're violating copyright law and are subject to a $150,000 fine.

WARNING

You might be violating the law making any ISO copy of a proprietary install CD. Shrinkwrap licenses are all different, and surrounding laws such as DMCA, UCITA and CBDTPA influence the legality. Some licenses permit you to create a single copy for backup purposes, but if that backup is an ISO, where would you store it? And in the case of installable software, would your original install CD be considered the one and only backup? Are there consumer protection or fair use laws guaranteeing you the right for additional backups, and are those consumer protection or fair use laws trumped by laws such as DMCA, UCITA and CBDTPA?

I'm not a lawyer and don't even pretend to know the answers to any of these questions. Because of this uncertainty, and the possible $150,000 fine for violation, my advice to you is quickly rid yourself of proprietary software and use only Open Source (free software, free as in freedom).

When making an ISO from an existing factory created CD, create and verify the ISO against the CD using the rawread script (defined in the Accurately Reading a CD Device section) as follows:
rawread /dev/cdrom > myiso.iso
rawread /dev/cdrom | md5sum
md5sum myiso.iso
If the two checksums match, you can be fairly confident that your ISO is an exact duplicate of the original CD.

Summary

Much coaster production can be traced to one of two breaches:
  1. Reading too few or too many blocks of a good CD
  2. Producing a CD whose last one or several blocks cause I/O errors. 
Problem 1 is fixed by the rawread script defined in the Accurately Reading a CD Device section. Problem 2 is usually fixed by using the padsize=63s and -pad and -dao arguments to the cdrecord utility, and making sure to retain the mkisofs utility's default of -pad.

Because many free software CD's are duplicated over several generations, it's vital to burn from a known good ISO, hopefully an ISO whose md5sum value conforms to the value published by the software's website. When creating an ISO from an existing CD, be sure to use the raread script in order to get the right number of blocks into the new ISO, and then checksum against the published value.

When burning a CD, always use the padsize=63s and -pad and -dao arguments to cdrecord, and never negate the default -pad argument to the mkisofs program. Also, never burn while using other disk or CPU intensive software unless your CD writer hardware and software are set to prevent buffer underflow (such protection is sometimes called "burn-free"). Be sure you burn at a speed at or below the lower of your CD writer's maximum speed and the CD media's maximum speed. If you're using a rewritable CD, you must use the "rewrite" speed values.

Naturally, your CD writer must be set up correctly. If there are problems in that regard, see Installing Your ATAPI CDRW Drive in Linux.

If you follow all these suggestions, you will burn very few coasters, and at Installfests you will be widely respected.

See also: [ Linux Library | Troubleshooters.Com | Email Steve Litt | Copyright Notice ]

Copyright (C)2002, 2003, 2005 by Steve Litt. -- Legal