[Future Technology Research Index] [SGI Tech/Advice Index] [Nintendo64 Tech Info Index]


[WhatsNew] [P.I.] [Indigo] [Indy] [O2] [Indigo2] [Crimson] [Challenge] [Onyx] [Octane] [Origin] [Onyx2]

Ian's SGI Depot: FOR SALE! SGI Systems, Parts, Spares and Upgrades

(check my current auctions!)

CDROM/CDRW Hints and Tips

Last Change: 10/Jan/2007

Recommended CDROM Units

Recommended CDRW Units

Using CDRW Units

Aliases and Scripts for Easier CDRW Authoring

Creating an image of an SGI EFS-format CD

Ejecting a Stuck CD

Hiding the 'rr-moved' Directory

Erasing/Blanking a CDRW Disc

Miscellaneous

I receive quite a few questions about CDROMs, the use of CDRW units, etc. Here I will summarise the most useful advice I can think of.

Recommended CDROM Units

Many people say Toshiba and Plextor are the brands to go for. However, I've had problems with the 40X Toshiba SCSI CDROM, and I saw some odd effects with the 40X Plextor. I strongly suspect that, in both cases, a firmware update (normally done with a PC) would fix these issues; however, if you're looking for a newer SCSI CDROM which will definitely work ok with no problems, then I recommend the 32X TEAC 532S CDROM. This is a very good model, works with anything, and I've never had any problems with it. More recently, I've also found the NEC 40X 3010A works just fine too; plus, the NEC is often available with a black front plate - ideal for installation in an Indigo2 or Origin system where the owner cares about aesthetic appearance.

If you're having problems with a CDROM, make sure the block size is 512, parity is ON, and check to see if termination may be an issue. Also make sure the SCSI ID is set correctly. Company web sites usually have detailed information on older models, or if not then a Google search will usually find the required information.

Note that some older SGI systems may not like CDROMs as recent as a 32X however, no matter what brand it is. I'm thinking here of Personal IRIS, POWER Series, IRIS Indigo, etc., whereas a system such as Indy/Indigo2 or later will be able to use newer CDROMs just fine. It's less of a problem when a system has already been installed and is ready to use; the problems tends to occur when doing an initial installation from the OS CDs. In particular, I've found that IRIS Indigo often doesn't like newer CDROMs when doing an OS install, especially the earlier R3000 Indigo. The problem is probably due to the PROM which can't deal with a newer CDROM correctly. I had to use an old 4X to do the initial install, but afterwards a 32X TEAC worked ok when the system was running (because it's then the OS, not the PROM, which is dealing with CDROM access).

Thus, with respect to early systems, especially for doing OS installations, it may be wise to locate an older 1X, 2X or 4X CDROM just in case the use of an older model is essential, but have a newer speedy model for all other uses.

Older CDROMs may be caddy-types, but both caddy and non-caddy models are not hard to find (I always have some available, including external units). The most common are Toshiba 2X or 4X units (the brand favoured by SGI for many years), typically the XM5401B or similar, but I come across NEC, Sony, etc. My personal favourite older CDROM is the Toshiba XM-4101B (not a caddy CDROM), typically dated around 1994. This model is not found so often on the 2nd-hand market, but it has one excellent feature which makes it well worth acquiring if possible, especially for Indigo2 owners: the central cylinder of the CD tray, on which the CDROM sits, holds the CD so securely that it's possible to use the CDROM vertically, or even upside down! The CD is held rigid because the central cylinder is slightly splayed outwards at the top, locking the CD in place much like some CD jewel cases do. Thus, for Indigo2 owners who have their system on foot stands, or anyone with a system which may have vertically aligned CDROM bay (eg. older high-end systems), this unit is a good choice, though obviously it's not very fast.

When considering a CDROM, it's best to stick with the more well-known brands, ie. TEAC, Plextor, Yamaha, NEC, specific Toshibas that are known to work, etc. I would avoid the more obscure makes - the firmware is more likely to be disliked by SGIs.

If you're looking for a unit specifically for reading CDROMs, then don't use a CDR or CDRW as a substitute. The firmware of CDRW units is such that, although they may work fine on an SGI for writing CDRs, they can often behave oddly when trying to read CDs; this is probably because CDRW firmware is often too PC-specific. Note that, as with CDROMs, a firmware upgrade (normally done with a PC that is SCSI-capable) may improve the situation; an example of this is given later.

Some CDRWs do work fine for reading CDs (eg. Yamaha 16/10/40 does pretty well), and certain models even work perfectly as a bootable device for OS installations (more on this later), but it's not worth the risk unless you're considering a model which is known to work ok. Besides, 2nd-hand CDRW units probably won't be that fast for reading CDs compared to a normal good CDROM; for example, the CD reading speed of a Yamaha 16/10/40 is definitely not as fast as a TEAC 32X 532S, even though the Yamaha has a theoretically higher speed.


Recommended CDRW Units

I started off doing CD-writing on SGIs with an original external Yamaha 8/4/24 unit (model number CRW8424SX) connected to an R4K/250 Indigo2. It worked very well, with excellent reliability and superb resilience to system load; I found it impossible to harm a CD-write session by doing other things at the same time, often running 100+ apps simultaneously while writing a CD as a perfect demonstration of the reliability and quality of SGIs and the IRIX OS.

I eventually upgraded to an Yamaha 8/8/24 which I came across by chance, selling on the 8/4/24. Note that, as originally shipped, the 8/4/24 was not a bootable device, but before I sold the unit I did a firmware upgrade which made it work just fine as a boot device for SGIs (the update .exe for PCs with SCSI is available on my depot page; the file is called s8410j_e.exe). By contrast, the 8/8/24 was already a bootable device. I suspect this difference may be found across product ranges from other manufacturers too, ie. newer models will probably work better for reading CDROMs than older models, and are more likely to work as a bootable device, although I've been told that some manufacturers have ended up breaking their early good firmware support for SGIs, eg. Plextor.

During 2003 I managed to obtain a Yamaha 16/10/40, which works ok as a bootable device too. In general though, if you want something faster than 8X, then similar recommendations apply to CDROMs: stick with the good brands and you should be fine. One caveat with newer models however: at 16X, the Yamaha is pushing data at a rate which is uncomfortably close to the reliable sustained speed of a FastSCSI2 bus in Indigo2. I found that it was no longer possible to do other things at the same time without occasionally harming the CD write session, but note that, unlike PCs, this is NOT due to any OS issue - it's just a physical limitation of the hardware. However, there is a way to improve the situation slightly, namely turn off any unnecessary service or application which is constantly using the main CPU. The main one I turn off is the local web server:

    /etc/init.d/sgi_apache stop

This makes writing a CD at 16X work just fine on an Indigo2, though it's still best to leave the system alone. There are four solutions to this:

Concerning newer CDRW units: as the above shows, at 16X one is approaching the limits of a FastSCSI2 bus in Indigo2. Thus, anything which is beyond 16X will very likely not work well on an old system using FastSCSI2 unless one uses either of the speed increasing methods described above. If absolute speed doesn't matter to you, then stick with an 8X. If you do need speed, then either increase the bandwidth as suggested above, or use a different system instead such as O2, Octane, Origin, or probably even a ChallengeS (since it's HVD buses are 20MB/sec, though HVD disks are hard to find). Using a newer system is probably the best solution due to the rareity of FC and USCSI option cards for Indigo2. Indeed, in the end, I upgraded to an R12K/300 Octane MXI which has evolved over time into my current system, an R14K/550 Octane2 V8.


Using CDRW Units

There are two aspects to using CDRW units: creating CD images for writing (or reading a CD to create an image) and writing the image.

The first step is to ensure the correct software is present. Make sure the latest versions of cdrecord, gcombust, mkisofs, etc. are installed. Check freeware.sgi.com and download/install the latest versions.

The main application for creating CD images from files/directories is mkisofs, while the main CD-writing application is cdrecord. If you prefer a GUI interface to these tools, then gcombust provides this option.

All these applications have man pages and/or online help, but there are a vast range of options possible, so what are the basics just to get started? I shall mostly discuss the use of mkisofs and cdrecord here by way of example.

The usual way of writing data to a CDR is to place the required files inside a directory and then use mkisofs to create a raw CD image which consists of the contents of that directory. This image is then written using cdrecord. For these examples, I shall assume the use of an Indigo2 which has an internal 32X CDROM on SCSI controller 0, ID 3 for reading CDs, and an external 8/4/24 CDRW for writing CDRs on SCSI controller 1, ID 4. If you're using a faster device such as a 16/10/40 on an Octane (which is what I now have) then adjust the speed to 16.

Suppose one has copied/downloaded a number of files and/or directories to a subdirectory in /var/tmp, perhaps like this:

  cd /var/tmp
  mkdir stuff
  cd stuff
  ftp somewhere.org  (and so on)

The most straightforward way to dump this data onto a CDR is as follows:

  cd /var/tmp
  mkisofs -R -o stuff.raw stuff
  cdrecord -v dev=1,4,0 speed=8 stuff.raw

and that's it! The general procedure is very simple: mkisofs creates the raw image file and then cdrecord writes it to the CDR (or CDRW disc; whichever).

The important aspects to note from the above are:

After the write operation is finished, one would then eject the CDR, eg.:

  eject /CDROM2

Note that CDROM2 would be specified for the setup described here since the internal CDROM would already be called 'CDROM'.


Aliases and Scripts for Easier CDRW Authoring

When writing CDRs it quickly becomes apparent that there are various ways one can make the process even easier. The first thing I did was to make an alias shortcut command for cdrecord, added to my .cshrc (I'll assume the use of an older device such as a Yamaha 8/8/24 here; adjust the speed setting if you're using a newer model):

  alias cdr 'cdrecord -v dev=1,4,0 speed=8'

This would allow the use of cdrecord shown earlier to be abbreviated thus:

  cdr stuff.raw

Ideal for the pathalogically lazy. 8)

But so much more is possible than this. First I became tired of manually entering 'eject /CDROM2' so I created an alias instead, using the raw SCSI device to make it more independent of how the CD devices may have been named by the OS:

  alias ej    'eject'
  alias e     'eject /dev/scsi/sc0d3l0'
  alias e2    'eject /dev/scsi/sc1d4l0'
'ej' is just a general eject command for use with a floppy drive if that is present.

Thus, to eject the CDR I just enter 'e2'. Much easier! And one can use shell symbols to make it happen automatically:

  cd /var/tmp
  mkisofs -R -o stuff.raw stuff
  cdr stuff.raw && e2

Al ot of this just saves typing, but is also faster, helps prevent errors, and begins to introduce aspects of convenience, eg. coming back to find the written CDR already ejected.

Later, I extended this idea to the setup I still use (though now the speed is all set to 16X), namely a script file called 'cdr' contained in /usr/local/bin (ie. cdr is not an alias in .cshrc anymore). The script contains the following (remember to make the script executable using 'chmod u+x'):

  #!/bin/sh
  cdrecord -v dev=1,4,0 speed=16 $1
  apanel -nodisplay -nofork -outlevels 255 && soundplayer -nodisplay -nofork /usr/local/misc/spiral.aifc
  sleep 2
  eject /dev/scsi/sc1d4l0

I should imagine you're wondering what the apanel/soundplayer command sequence is there for. Its function is to play a short sound file when the CD writing has finished, in this case a few seconds from the track, "Spiral", by Vangelis. This is done carefully though, in that the volume is set to maximum before the sound is played, neither the apanel or soundplayer GUI applications are displayed when the sound is being played, and the volume is set back to normal after the sound is played. Note that I have an alias called spir which does exactly this command sequence; I use spir quite often as a very simple way of letting me know when a task has completed, eg. a tar operation, or an xfsdump, or a dmconvert process.

After the sound is played, the system waits 2 seconds to give the CDRW time to settle, and then the CDR is ejected.

Thus, to write a CD for which I already have the image available, I just go into the appropriate directory containing the image file and enter:

  cdr filename

and away it goes. When it's finished a sound is played and the CD is ejected, all without the use of fancy GUI programs or other unnecessary bells and whistles. This kind of operation is a reminder of just how efficient the command line can be. And since it's just a text command, it can be used in other script files, batched, scheduled, left in the keyboard buffer to follow after other operations, etc.

cdrecord and mkisofs have a vast range of options available, but for most instances of writing a CD, the procedure shown here should do just fine, and the aliases or example scripts can help make the process very easy.


Creating an image of an SGI EFS-format CD

Sometimes one may wish to make a backup copy or clone of an SGI CD which is usually in EFS format. For those CDs which merely contain data, an iso copy of the CD will suffice. This could be done as follows, assuming the CDROM to be copied is mounted as /CDROM:

  mkdir /var/tmp/cd
  cd /CDROM
  tar cvBpf - . | (cd /var/tmp/cd; tar xBpf -)
  cd /var/tmp
  mkisofs -R -o cd.raw cd
  cdr cd.raw

However, some CDs have more than just data, eg. EFS-format CDs which are bootable for doing OS installations or upgrades. These CDs have a volume header which is not visible on the normal partition mounted on /CDROM. To create a CD image which includes the volume header, one must access the CDROM device at a raw level using the 'dd' command, as follows:

  dd if=/dev/rdsk/dks1d4vol of=cd.raw bs=512

The 'if' field specifies the input file or device (notice there are no spaces either side of the '=' symbol), while 'of' specifies the output file or device. 'bs' specifies the block size, which for CDROMs should be 512. NB: this operation will work ok if 'bs' is not specified, but by default 'bs' is set to 1 which means the copy operation would take a very long time! Thus, remember to include the 'bs' option and set it to 512.

When the operation has finished, write the image to a CDR in the normal way, eg. 'cdr cd.raw'. Thus, for example, this procedure is appropriate for creating a backup CD set of the base 6.5 OS installation CDs.


Ejecting a Stuck CD

The most common reason a CD can't be ejected is because a process somewhere is using it, which usually means a shell window has its current directory somewhere within the CDROM file system. One will see an error message like this:

  eject: The drive is busy.  Make sure no programs are using the drive.

Make sure all shells have their current working directory set to be elsewhere (enter 'cd' in every window; check with 'pwd') and try ejecting the CD again.

If it still doesn't eject, even with the low level eject aliases as described earlier, then it's likely an application or process which was using the CD has gone wrong and is unable to release its hold on the device. Hence, try using the -k option with umount to kill the process which is locking the CDROM:

  umount -k /CDROM

and then try ejecting the CD again.

If that doesn't work, then the last resort is to shutdown mediad and then just press the hardware eject button on the front of the CDROM, ie.:

  /etc/init.d/mediad stop

...press eject, take out the CD, then restart mediad...

  /etc/init.d/mediad start


Hiding the 'rr-moved' Directory

Sometimes the mkisofs command will create an image which, when written to a CDR, results in an extra directory visible in the top of the CD file structure called 'rr-moved'. It's not important, but for cosmetic reasons it may be desirable to hide this directory, eg. for production work, etc. (yes, there are companies which use cdrecord to make the commercial CDs they then sell).

To hide the directory, use the -hide-rr-moved option with mkisofs. This will still include the rr-moved directory if mkisofs decides to create it, but the directory will be hidden, ie. it will have a dot prefix (.rr-moved) so that a normal 'ls' command action on the CDROM will not show the presence of the directory, which looks much cleaner. A typical usage would be:

  mkisofs -hide-rr-moved -R -o cdstuff.raw cdstuff

I have an alias defined to make this easier:

  alias mk    'mkisofs -hide-rr-moved -R -o'

which shortens the example above to:

  mk cdstuff.raw cdstuff


Erasing/Blanking a CDRW Disc

To erase, or blank a CD, use cdrecord with the 'blank' option:

  cdrecord -v dev=1,4,0 speed=8 blank=all

or if you're confident that a basic erase will suffice then use the fast blanking option thus:

  cdrecord -v dev=1,4,0 speed=8 blank=fast

I have two script files in /usr/local/bin to make this easier: cdba (for blank=all) and cdbf (for blank=fast), which contain respectively:

  #!/bin/sh
  echo "Erasing the CD fully [ALL] at 8X speed..."
  cdrecord -v dev=1,4,0 speed=8 blank=all
  soundplayer -nodisplay -nofork /usr/local/misc/spiral.aifc
  sleep 2
  eject /dev/scsi/sc1d4l0

and:

  #!/bin/sh
  echo "Erasing just the basic structures of the CD [FAST] at 8X speed..."
  cdrecord -v dev=1,4,0 speed=8 blank=fast
  soundplayer -nodisplay -nofork /usr/local/misc/spiral.aifc
  sleep 2
  eject /dev/scsi/sc1d4l0


Miscellaneous

If you're writing to a CDRW disc, remember that the write speed may be different to the normal write speed and so adjust the values passed to cdrecord accordingly. I use modified versions of the cdr script to achieve this, eg. cdr4 which writes at 4X speed, cdr8, cdr12, etc.


And that's it! I'm sure there are useful items I've left out; I'll add them when I remember them or hear of other tips. Feel free to email me your own ideas and info.

NOTE: I shall write a section on how to use gcombust to read/record audio CDs at a later date.


Ian's SGI Depot: FOR SALE! SGI Systems, Parts, Spares and Upgrades

(check my current auctions!)
[WhatsNew] [P.I.] [Indigo] [Indy] [O2] [Indigo2] [Crimson] [Challenge] [Onyx] [Octane] [Origin] [Onyx2]
[Future Technology Research Index] [SGI Tech/Advice Index] [Nintendo64 Tech Info Index]