Usally the writing of a CD under Linux is done in 2 steps:
mkisofs/mkhybrid-utilitycdwrite or
cdrecordIt is also possible to combine the 2 steps into one via a pipe but that is discouraged because it's not reliable. See below.
After following all steps of the second chapter your system should be able to deal with the task of writing CDs. This section can be used as a proof that everything works as intended.
Issue the command dmesg. It should report the messages of the
Linux-kernel including those printed while booting (limitation: only the
last 200) and contain some information about the CD-Writer connected to the
SCSI-bus.
Simple example:
Vendor: YAMAHA Model: CDR100 Rev: 1.11
Type: WORM ANSI SCSI revision: 02
Detected scsi CD-ROM sr1 at scsi0, channel 0, id 3, lun 0
This machine has 4 SCSI-devices connected to it (you can't see it so I tell
you), with SCSI-id's from 0 to 3. The writer is the 4th physically present
SCSI-device and therefore connected to /dev/sgd (the fourth
generic SCSI-device when counting is started with the letter a). In this
case the command
cdwrite --eject --device /dev/sgd
opens the tray and is a test if everything is set up properly. A more complicated example:
scsi0 : AdvanSys SCSI 1.5: ISA (240 CDB)
scsi1 : Adaptec 1542
scsi : 2 hosts.
Vendor: HP Model: C4324/C4325 Rev: 1.20
Type: CD-ROM ANSI SCSI revision: 02
Detected scsi CD-ROM sr0 at scsi0, channel 0, id 2, lun 0
Vendor: IBM Model: DPES-31080 Rev: S31Q
Type: Direct-Access ANSI SCSI revision: 02
Detected scsi disk sda at scsi1, channel 0, id 0, lun 0
scsi : detected 1 SCSI cdrom 1 SCSI disk total.
SCSI device sda: hdwr sector= 512 bytes.
In this example two SCSI-controllers host 1 SCSI-device each. What a waste (they are able to host up to 7 devices each). It's not my setup so stop asking if I have too much money ... Anyway for the purpose of being an overlookable example this setup is just excellent. :-)
In the above example the CD-Writer has SCSI-id 2 but it is associated with
the first generic SCSI-device /dev/sga because it's the first
physically present SCSI-device which Linux has detected. Hopefully this
shows clearly that the SCSI-id of a device has nothing to do with the
associated generic device.
Two questions are left: what happens if you catch the wrong device? If you neither specify the option "--<MANUFACTURER>" nor write any data to the device, usally a warning message is printed and nothing bad happens:
bash> cdwrite --eject --device /dev/sgb
Unknown CD-Writer; if this model is compatible with any
supported type, please use the appropriate command line
flag.
Manufacturer: IBM
Model: DPES-31080
Revision: S31Q
In this case the device /dev/sbg is a SCSI harddisk (from IBM).
If you write data to the wrong device, you overwrite the original content of it and probably irrecoverable damage your system. Be careful, it already happened to me by accident.
Usally this takes up longer than one expects. Remember that missing files cannot be added once the CD is written. :-)
Also keep in mind that a certain amount of the free space of a CD is used for storing the information of the iso9660-filesystem (usally a few MB).
The term iso9660 refers to the format in which data is organised on the CD. To be more precise: it's the filesystem on the CD.
Of course the appearance of files stored in this format is unified by the Linux-kernel as for every other filesystem, too. So if you mount a CD into the directory tree, you cannot distinguish it's files from other files ... beside the fact that they are not writeable ... even not for root. :-) (The mechanism used to unify the appearance of files is called virtual filesystem, short VFS.)
The features of the iso9660 filesystem are not so rich compared to those of the extended-2 filesystem which is normally used under Linux. On the other hand, the CD is only writable once and some features make no sense anyway. The limitations of the iso9660-filesystem are:
Before any storage medium (e.g. floppy disk, harddisk or CD) can be used, it must get a filesystem (DOS speak: get formatted). This filesystem is responsible for organising and incorporating the files that should be stored on the medium.
Well, a writable CD is only writable once so if we would write an empty filesystem to it, it would get formated - but remain completely empty forever. :-)
So what we need is a tool that creates the filesystem while copying the
files to the CD. This tool is called mkisofs. A sample usage
looks as follows:
mkisofs -r -o cd_image private_collection/
`---------' `-----------------'
| |
write output to take directory as input
The option '-r' sets the permissions of all files to be public readable on
the CD and enables Rock Ridge extensions. That is what one usually wants
and use of this option is recommended until you know what you're doing
(hint: without '-r' the mount-point gets the permissions of
private_collection!).
If you are running a Linux kernel prior to
2.0.31, you should add the option '-K' to work around a bug in the
filesystem code. You need the patched version of mkisofs
for it. This option is equivalent to the option '-P' of cdwrite.
Please see the manual-page of mkisofs for details. Users of a more
recent version of Linux have to worry about neither.
mkisofs will try to map all filenames to the 8.3-format used by
DOS to ensure highest possible compatibility. In case of naming conflicts
(different files have the same 8.3-name), numbers are used in the filenames
and information about the chosen filename is printed via STDERR (usually
the screen).
DON'T PANIC:
Under Linux you will never see these 8.3 filenames because Linux makes use of the Rock Ridge extensions which contain the original file-information (permissions, filename, etc.).
Now you may wonder why the output of mkisofs is not directly sent
to the writer-device. This has two reasons:
mkisofs knows nothing about driving CD-writers (see
section 2.3.)Because the timing of the CD-writer is a critical point, we don't feed it
directly from mkisofs (remember Linux is not a real-time operating
system and tasks can be timed badly). Instead it is recommended to store
the output of mkisofs in a separate file on the harddisk. This
file is then an 1:1-image of the later CD and is actually written to the CD
with the tool cdwrite in a second step.
The 1:1-image gets stored in a huge file so you need the same amount of free disk space that your collected software already eats up. That's a drawback.
One could think of creating an extra partition for that and writing the image to that partition instead to a file. I vote against such a strategy because if you write to the wrong partition (due to a typo), you can lose your complete Linux-system. Furthermore, it's a waste of disk-space because the CD-image is temporary data that can be deleted after writing the CD.
Linux has the ability to mount files as if they were disk-partitions. This
feature is useful to check the directory layout of the CD-image is ok. To
mount the file cd_image created above on the directory
/cdrom, give the command
mount -t iso9660 -o ro,loop=/dev/loop0 cd_image /cdrom
Now you can inspect the files under /cdrom - they appear exactly
as they were on a real CD. To umount the CD-image, just say umount
/cdrom. Warning: If you did not use the option '-K' for mkisofs then
the last file on /cdrom may not be fully readable.
Note:
some ancient versions ofmountare not able to deal with loopback-devices. If you have such an old version ofmountit is a hint to upgrade your Linux-system.Several people already suggested to put information about how to get the newest mount-utilities into this mini-HOWTO. I always refuse this. If your Linux-Distribution ships with an ancient
mount: report it as a bug. If your Linux-Distribution is not easily upgradable: report it as a bug.If I included all the information that is necessary to work around bugs in bad designed Linux-Distributions, this mini-HOWTO would be a lot bigger and harder to read.
The german computer magazine "c't" has a list of tips regarding the blank CDs in their november 1996 issue:
Not much more left to do. Before showing you the last command, let me warn you that CD-writers want to be fed with a constant stream of data because they have only small data-buffers. So the process of writing the CD-image to the CD mustn't be interupted or a corrupt CD will be the result.
To be sure nothing can interupt this process, throw all users of the system and unplug the ethernet-cable ... Read the Bastard operator from hell to learn about the right attitude to do so. ;-)
If you are mentally prepared, dress up in a black robe, multiply the SCSI-id of the CD-writer with it's SCSI-revision and light as many candles, speak two verses of the ASR-FAQ and finally type
cdwrite --device /dev/sgd cd_image
or
cdrecord -v speed=2 dev=4,0 cd_image
depending on which software you want to use. Of course you have to replace the example SCSI device with the device your writer is connected to.
Please note that no writer can re-position it's laser and can't continue at the original spot on the CD when it gets disturbed. Therefore any strong vibrations or even a shock will completly destroy the CD you are writing.
... remember you can still use corrupt CDs as coasters. :-)