Print-friendly Version

Linux How-To: Burning CDs and Validating ISO Images

Bob Netherton, November, 2004

This cookbook is designed to help notebook users burn ISO images onto CDs and validate the contents.

While burning ISO images onto CDRs is a part of the Linux culture, not all of the distributions address validation of this process in the same manner. We need to burn ISO images with increasing regularity, and we may be burning them from a platform running Linux or the Solaris OS. So let's take a few minutes and review the process and see what we can do to validate the bits that actually make it to the optical disc.

The fundamental question is, how do you know your burn was successful?

The trivial answer would be, the exact same way you validate your ISO image download from the network, by using MD5 checksums. Unfortunately the answer is not quite as simple as that. In other words, a rather obscure problem might prevent you from validating a CDR in this manner, and it could leave you very frustrated.

First, here's an example where I am burning the Sun Java Desktop System beta documentation ISO image. The unimportant lines have been edited out for readability.

First, let's select a CD-RW device:

# cdrecord --scanbus
Cdrecord 2.0 (i686-pc-linux-gnu) Copyright (C) 1995-2002 Jörg Schilling
Linux sg driver version: 3.1.24
Using libscg version 'schily-0.7'

scsibus2:
        2,0,0   200) 'SONY    ' 'DVD RW DRU-510A ' '1.0a' Removable CD-ROM
        2,1,0   201) 'SAMSUNG ' 'CD-R/RW SW-248F ' 'R602' Removable CD-ROM

Now, let's burn the ISO image to a CDR. Four important cdrecord options can make your experience a lot more pleasurable.

• speed=<n>: This will set the speed of the write. Unless forced, cdrecord will limit this by the media speed, if it can be determined. In this example I am using 40x CDRs, and a 48x capable IDE writer.
• driveropts=burnfree: This enables buffer underrun protection. This is the most frequent cause of failed burns (which we affectionately call coasters). Most modern drives have a form of underrun protection and this command option enables support for it. Many other tools, such as cdrdao, enable burnfree by default; cdrecord does not.
• -dao: This tells cdrecord to write the disc in 'session at once' mode, sometimes called 'disc at once'. This will tell the laser to burn the lead out area so that no more data can be written to the device, effectively closing it permanently. Like burnfree, the default is not your favor, as we will see in a few minutes. For now, let's use -dao and see what happens.
• -eject: This will eject the CD-ROM media at the end of the write operation. If you forget to do this, you will not be able to calculate the correct MD5 checksum, and you will be left thinking you are having problems burning CDs.

Time to burn the CD.

# cdrecord -v dev=2,1,0 speed=40 driveropts=burnfree -dao -eject MadHatter-Beta-Docs.iso

Cdrecord 2.0 (i686-pc-linux-gnu) Copyright (C) 1995-2002 Jörg Schilling
TOC Type: 1 = CD-ROM
scsidev: '2,1,0'

Starting to write CD/DVD at speed 40 in real SAO mode for single session.


BURN-Free was 11 times used.
cdrecord: fifo had 1760 puts and 1760 gets.
cdrecord: fifo was 0 times empty and 911 times full, min fill was 95%.

So now let's compare checksums.

# md5sum /dev/cdrom3 MadHatter-Beta-Docs.iso
8831242df75ea5bdc2c56e7f0e9830d3  /dev/cdrom3
8831242df75ea5bdc2c56e7f0e9830d3  MadHatter-Beta-Docs.iso

Outstanding! No coaster.

So what's the big deal?

If I had not specified -dao (session at once mode) and taken the cdrecord default recording mode (track at once), the following would have happened:

# md5sum /dev/cdrom
md5sum: /dev/cdrom: Input/output error

Further stubborn attempts at verification might produce something like:

# dd if=/dev/cdrom bs=2048 | md5sum
dd: reading `/dev/cdrom': Input/output error
269860+0 records in
269860+0 records out
7c996f932254bfae7a24a1fba14e57bb  -

And you would be convinced you had a coaster.

The problem is that the last block may be confused with the lead out area, and some drives will not read it properly. Thus your MD5 checksums will fail. You can pad the last blocks using the -pad option of cdrecord, but your checksums still might not match as you have added additional data to the CD that was not present in the original ISO image.

Of course you could loopback mount the original ISO image, mount the newly burned CDR, and do something like this:

# mount -o ro,loop -t iso9660 `pwd`/MadHatter-Beta-Docs.iso /mnt
# mount -o ro -t iso9660 /dev/cdrom /media/cdrom
# diff -r /media/cdrom /mnt

If nothing is reported, you are good to go. If you are doing this on a laptop with a single ATA drive and not much memory, you don't want to do this very often. It is a rather resource-intensive way of validating your ISO image. But then again, you may find the sound of popcorn popping in a microwave oven pleasurable.

So the moral of the story is to remember to pad the last block with -pad or better yet, write your CDRs in 'session at once' mode using -dao, and then use md5sum to compare with the original ISO binary image.

So far we have talked about Linux; what about the Solaris OS?

A patch (107645) for the Solaris 7 OS fixes the partial-last-block read problem. It was integrated into the Solaris 8 OS, so later releases do not have this particular problem.

As for MD5 checksums on the Solaris platform, find a copy of gmd5sum (it is on the companion CD).

One last note, make sure you enable DMA mode on your CD writer device. Most Linux distributions, including the Java Desktop System, turn DMA off by default. You can enable DMA via boot options, a Yast2 setting, or by the DEVICES_FORCE_IDE_DMA_ON variable in /etc/sysconfig/hardware.

You can increase the responsiveness of a laptop by enabling 32-bit EIDE support and unmasking interrupts.

# hdparm -d1 -c1 -u1 /dev/hdc

This enables DMA and 32-bit EIDE support, and it allows disk interrupts to be interrupted.

Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License.