IDE CD BURNERS
Author Mike Andrew:
Setting up an IDE CD
BURNER in Linux fills mailgroups with queries. Here is what you need to
know.
Orientation
Device drivers for linux come in two forms:
Monolithic
Modular
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:
The is NO SUCH THING AS AN 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.
]
However.
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.
Realitytime.
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.
LILO APPEND STATEMENT
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:
- Simple and quick.
- It is NOT required *.
- It WILL confuse for any systems with multiple cd's since
only those specified become scsi, the others cannot be used
(for burning).
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
/sbin/modprobe/ide-scsi
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
ide-scsi
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
/dev/sr0
/dev/sr1
etc
These entries do not exist in a modern
distribution
Instead, the preferred naming convention is
/dev/scd0
/dev/scd1
etc
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
IDE-SCSI.o
(/dev/scd0)
And, to complete the topology, here are full blown ide and
scsi topologies
VFAT
EXT2 NTFS FAT ISOFS
CDROM
SD_MOD
SCSI_MOD
PPA NCR53C8xx IDE-SCSI
ZIPs DISKs
CDs
TAPEs
CDs
-----------------------------------------------
VFAT
EXT2 NTFS FAT |
ISOFS
| CDROM
IDE-HD | IDE-FLOPPY | IDE-CD
| SCSI_MOD
|
| ZIP/LS120
|
Search
