Author Mike Andrew:

Setting up an
IDE CD BURNER in Linux fills mailgroups with queries. Here is what you need to know.


Device drivers for linux come in two forms:


Monolithic drivers are compiled into the kernel. An example of one would be the ide-cd.o driver (the ide hard disk driver). On ibm-pc's it is normally in the kernel, ready for use. Modular drivers are loaded as and when required by modprobe. It is the order in which these drivers are registered by the kernel that causes the heartache. Bear this in mind, and read on.

Confusion 101: Terminology

cdrom: A device that can read cd platters.
cd-r:    A device that can RECORD cd platters. Ie, a cd-burner.
cd-rw: A platter that can be re-written.
cd-w:  No such animal

Mailgroups are full of erroneous messages about cd-r. The author thinks he's referring to a Read only device, it is a Recordable  burner. In this context, there's no such thing as cd-w.

See device names below for confusion 103

Confusion 102:

IDE CD BURNER in Linux, and never will be.

Now that you've got over that hurdle, here's the reasons why.

ALL cd burning software relies on the console only application cdrecord. It is, the industry standard app for cd-anything. There will be no other because it is the killer app of it's class.

ALL gui applications (such as XCDROAST) ultimately communicate with cdrecord.

cdrecord communicates exclusively with scsi devices.

To get around this minor detail, a wedge driver called ide-scsi exists. As it's name suggests, it is an ide -> scsi emulator.

Once invoked, the cd(s) that exist on your ide channel(s) become scsi devices.

It is, as simple as that. You then use XCDROAST, or any other gui, or cdrecord itself, and communicate with the cd burner on (say) /dev/scd0 .

Now for the hard part.

ide-scsi is a wedge module. In a fair and reasonable world it is invoked like any other module

modprobe ide-scsi

The ways and means of using modprobe are outside the scope of this document. It is part of your kernel loading, involves/etc/modules.conf and you should look elsewhere on the SxS site if you need help in this basic as each distro invokes module loading differently.


The 'problem' with this wedge module is that it scans ALL unregistered devices on ALL ide channels and takes them over. ALL of them.

Thus everything on the ide channels that are unregistered by the kernel become emulated scsi devices.

An unregistered device is anything the kernel doesn't currently know about. It becomes registered via modprobe, or, if the 'module' has been compiled into the kernel (monolothic).

Every single device ever invented for the ide channel comes under one of the following modules.

ide-hd # for hard drives
ide-cd # for cds of all types
ide-floppy # for ls120's and zips
ide-tape  # for tape storage.

In the case of IBM PC's the ide-hd (hard disk driver) is compiled monolothic. Thus, it is pre-registered, thus no problem. Unless compiled monolithic (which would be unusual), zip, tapes, LS120's and cd's have to be 'registered' as part of the /etc/inittab process or thereafter using modprobe.

The end result is that either, you have loaded a device driver to register (some of) the above devices FIRST, or, ide-scsi will take them over.

Assuming you have all these devices, the order of load *could* be.

modprobe ide-floppy # for zip's and ls120's
modprobe ide-tape   #
modprobe ide-cd     #  OR
modprobe ide-scsi

Note the either or. You either want your cd's (plural) to remain as ide devices, OR, you want your cds (plural) to become scsi. If you choose to remain ide, using the ide-cd module, you CANNOT burn cd's. Period.


The above order of module loading will ensure that your zips and tapes will remain as ide controlled devices, if that is want you want. The reality is that both of these drivers are SCSI emulators and they in fact use truncated code from ide-scsi to achieve an identical result. Thus, you can cheerfully eliminate their need. ide-scsi will cover them with the exact same /dev/names. I have included the above modprobe list to orient you to what's happening, not, what you need to do.

The end result of all this is that by eliminating any reference to any of the ide-xxx type drivers in your /etc/modules.conf (or wherever device loading is instantiated /etc/rc.modules eg) and simply stating ide-scsi, your problems are over for modular drivers.

Because of the vagaries of control over when ide-cd gets loaded (if at all), and worse, if it gets loaded first (thus preventing ide-scsi from doing it's job), the append statement in your boot config is the catch all

append="hdb=ide-scsi hdd=ide-scsi"

(The grub statement is similar, read the SxS).

The above specifically states that BOTH cd drives /dev/hdb and /dev/hdd are to be emulated as scsi). Note here the different channels used (vs /dev/hdc and /dev/hdd). Depending on your hardware, placing cd's on the same channel can cause burns to fail due to timing constraints.

This would be a normal situation for a typical hardware setup of copying cd's from one to the other. Note most especially if you don't emulate your cdrom, it cannot be used in cd burning software, specifically cd -> cd copying. You must instead rely on the 'wasteful' file iso image method. And, again, even here, you might prefer the "wasteful iso image method", if you are experiencing data underruns.

To be pendantic, the append statement offers fine grain control over which specific /dev/hdX you wish to emulate, rather than everything.

Using append is:
Not required means, by careful review on your part of the /etc/inittab scripts (/etc/rc.d/rc.sysinit eg) you can avoid the loading of ide-cd. ide-cd is the animal causing you grief. Append IS REQUIRED, if your ide-cd has been compiled monolithic.

Example for Redhat RH7.x series

eliminate the append statement (and type /sbin/lilo)

edit /etc/rc.d/rc.local

remove any statement (if any) about ide-xxxxx (normally none)

add the statement


  Example for Caldera COL 2.x and 3.x series

eliminate the append statement (and type /sbin/lilo)

edit /etc/modules/default

remove any statement (if any) about ide-xxxxx (normally none)

add the statement


Confusion 104:

Device Names

Historically (and by convention), /dev/names are associated with their device driver modules.

Thus, the unfortunately named sr_mod.o is the SCSI, cd device driver, and the corresponding entries in the /dev tree are



These entries do not exist in a modern distribution

Instead, the preferred naming convention is



These entries invariably exist in a modern distro.

The confusion comes in newsgroups when recommended 'procedure' mentions one, or the other name, and the reader is left not realising two authors are talking about the same thing.

The confusion also occurs with applications, some (old versions of GCOMBUST eg) come hardwired to accept only /dev/srX , and if you're using devfs file system, it can only work (dynamically) with srX

The cure is simple

ln -s /dev/scdX /dev/srX

(X = some number)

Ie *simply* make both names mean the same thing.

Finally, for those interested in the topology, here is a mudmap of the two driver trees

IDE BASED                SCSI BASED
ISOFS.o            ISOFS.o
CDROM.o            CDROM.o
IDE-CD.o           SR_MOD.o
(/dev/hdc)         SCSI-MOD.o


And, to complete the topology, here are full blown ide and scsi topologies




ZIPs       DISKs             CDs


EXT2 NTFS     FAT       |   ISOFS
                                    |   CDROM

            | SCSI_MOD      |
            | ZIP/LS120      |

searchSearch Index