Coasterless CD Burning
Copyright (C) 2002, 2003, 2004, 2005
by
Steve
Litt
[ 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:
- CD burns that are wrong or non-portable
- 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:
- Reading too few or too many blocks of the CD device
- 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:
- Set up your burner correctly.
- Burn at the right speed.
- While burning, do not perform other CPU or disk intensive work,
as
it will cause buffer underflow on burners without underflow protection.
- Always pad correctly with the padsize=63s and -pad
argument to cdrecord.
Without excellent reason, do not defeat the -pad default of
the mkisofs program.
- Always use disk at once. In the cdrecord program, you signify
disk at once (session at once) with -dao.
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:
- Reading too few or too many blocks of a good CD
- 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