Most scanners can be purchased with a USB, parallel, or SCSI interface. At this time, only SCSI scanners are supported under Linux, with USB support improving. There are two programs you can use to capture data from a scanner: the commercially available xvscan (http://www.tummy.com) and the freeware SANE (Scanner Access Now Easy, http://www.mostang.com/sane). As an added bonus, SANE interfaces with the GIMP program to allow you to scan an image and immediately edit it.

Many SCSI scanners will come with their own low-grade SCSI card. Unless you're sure that Linux supports the card, don't bother trying to use it.

Your kernel will need to have the generic SCSI driver compiled in it or as a module. On Red Hat, the library is /lib/modules/<kernel>/scsi/sg.o. Next you will need to check and possibly set the SCSI ID of the scanner if it conflicts with existing devices on your controller. The device corresponding to the scanner will then be /dev/sg[a-f]. Here, a would be a SCSI ID of 0, b would be 2, and so on up to f, which would have an ID of 6.

crw-rw-rw-    1 root  sys         21,   3 Aug 28 00:12 /dev/sgd

# mknod /dev/scanjet c 21 3
# chgrp
scanner/dev/scanjet
# chmod 660 /dev/scanjet
# ls -l /dev/scanjet
crw-rw----   1 root
scanner 21,   3 Aug 28 00:15  /dev/scanjet

There are a number of reasons why you might want to attach a modem to your machine:

If you have an external modem, the only issue you have to worry about is having the serial port driver available. If you have an internal modem, which adds its own serial port to your machine, you may run into IRQ problems. Additionally, if the modem has a non-standard chipset, Linux may not recognize it. Any modem that is advertised as a "Winmodem" will not work with Linux. These modems, though inexpensive, rely on the CPU to do much of the processing work and should be avoided when purchasing a new machine.

In all likelihood, you will have to do nothing to get Linux to talk to your modem. The one thing needed (serial port support) is almost always present in the kernel, usually for the mouse.

If you have an external modem attached, it will attach to one of the on-board serial ports and should have no problems with IRQ conflicts. If you are installing it internally and have an IRQ conflict, there are a couple of ways of resolving it.

This will assign the third serial port. A number of other options can be set with setserial. Consult the man page for more information.

There is a rather large and bewildering selection of tape drives. If you need to back up large amounts of data in a reasonable amount of time, however, you can eliminate ones using the parallel port as they have lower throughputs. ATAPI (IDE) tape drives also exist.

Assuming you decide to use a SCSI tape drive, you will need to enable SCSI tape support in your kernel, or have the st.o module loaded. As in installing any SCSI device, check to make sure you have chosen a unique ID for your tape drive before installing it.

Device files for tape drives contain the letters "st." If your tape is SCSI ID 6, it will have two device files: st6 and nst6. The first is used if the device is rewinding and the second if it is not. Most tape drives are non-rewinding so you will need to refer to them as /dev/nstn, where n is the device number.

To test a new tape drive, you can use one of the backup programs included with Red Hat, or you can use the tar command to put files on the tape, then tar the files off again.

Until recently, few people thought of uninterruptible power supplies (UPSs) as peripherals for the reason that the computer and UPS didn't exchange information or take action based on the state of one or the other. Now though, this is not the case. A few years ago, UPSs with serial ports started appearing, along with snazzy GUI front-ends, to allow the battery and power level to be monitored and for actions to be set up based on conditions reported. However, only commercial OSes are supported. Some manufacturers have even published the language used to communicate with their UPS, allowing others to write their own programs for interacting with it.

There are two ways UPSs can be categorized: by how they perform their function of providing uninterrupted power, and by the level of interaction they have with the computer to which they are attached. The first has three types: stand-by, in-line, and line-interactive.

The first type simply sits and waits for the power to drop below a certain level and then, usually in a matter of milliseconds, switches to providing power via its batteries. The second actually filters all power through itself. It thus can condition the power that it puts out and kick in during brownouts. This method also provides about half the wear and tear on the batteries, obviously shortening their lifetime.

There are several programs, most of them with some sort of GUI, for talking to your UPS. Most of them are somewhat feature-poor when compared to their Microsoft Windows -based counterparts. To date, Best is the only vendor that supplies UPS control software that can be compiled for use under Linux. Most of the other tools are fairly generic and can talk to UPSs only in dumb mode.

With dedicated 3D cards costing less than $200 and providing great 3D graphics, you can now play many of the same games on Linux as you can on Windows 98, and then some. Physical installation is performed according to the instructions. Once Linux is up and running, you'll want to download, compile, and install the Mesa 3D library. Most 3D programs require Mesa, and Mesa comes with a few demo programs to test out the functionality. Some cards (such as the 3Dfx voodoo series) require that you download some drivers from 3Dfx to complete the installation. Check the Mesa home page for more information on what 3D cards are supported. Once installed, issue the following command to tell Mesa to use fullscreen mode:

setenv MESA_GLX_FX=f

Without this command, Mesa would start up its applications in a window, which would slow down the graphics (a lot!), but you could still do 3D in a window if you required it. Once you complete some of the demo programs, grab a copy of GlQuake and blow some friends away.

USB (Universal Serial Bus) is a method of trying to connect low-speed devices through a single connection on a motherboard. USB allows you to connect keyboards, mice, scanners, video cameras, digital speakers, and even Ethernet interfaces directly into a machine. USB provides for low-speed (1.5MB) and higher-speed (12MB) devices, allowing for up to 127 devices per machine. USB is plug-and-play, meaning that you can hot swap devices at will.

Unfortunately, few operating systems have full support for USB. At this writing, Linux has little support, but can handle a USB keyboard and mouse, since the iMac has only USB connections on it. In the coming months, USB support will be integrated into the main kernel, and many of the devices will become supported.

It is likely that at some point you will want to add additional disk space to your machine. Installing a new hard drive is a fairly painless procedure. In this section, we're assuming you are using a SCSI host adapter. Also, you presumably have SCSI, SCSI disk, and support for your SCSI controller already available, possibly set up by the vendor who sold you the machine.

This being the case, adding another hard drive is as simple as checking the new drive to ensure that it has a unique SCSI ID, installing it in the CPU case or an external case, and rebooting. Typically, the SCSI ID is set by jumpers. Where on the disk they are and how to set them should be explained in the manual that came with the disk.

Once you have the hard drive installed, you will need to create some Linux partitions on it. Start by running fdisk:

# fdisk/dev/sda

The number of cylinders for this disk is set to 1030. This is larger than 1024, and may cause problems with:

Command (m for help): p
Disk /dev/sdb: 64 heads, 32 sectors, 1030 cylinders
Units = cylinders of 2048 * 512 bytes

Device Boot   Begin   Start      End   Blocks   Id   System
/dev/sda1        1       1        100   102384   6    DOS 16-bit >=32

When you first get the drive, there can be any number of strange, possibly nonsensical, partitions on it. Just delete them with the d command in fdisk so you can start with a clean slate.

To add a new partition, use the n command:

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-100): 1
Last cylinder or +size or +sizeM or +sizeK ([1]-100): +50M

Command (m for help): p

Disk /dev/sdb: 64 heads, 32 sectors, 100 cylinders
Units = cylinders of 2048 * 512 bytes
Device Boot    Begin    Start     End    Blocks   Id   System
/dev/sdb1         1        1        51     52208   83   Linux native

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 2
First cylinder (1-100): 52
Last cylinder or +size or +sizeM or +sizeK ([52]-100): 100

Command (m for help):

By default, partitions are created as Linux native (extended 2) filesystems. If you need to change the filesystem type, for example to add a swap partition instead, use the t command:

Command (m for help): t
Partition number (1-4): 1
Hex code (type L to list codes): 82
Changed system type of partition 1 to 82 (Linux swap)

Contrary to conventional wisdom, performance-wise it is better to have a few large partitions as opposed to many small partitions, though your system's needs should probably play the largest role in determining how to partition your disk.

After you've set up your partition(s), run mke2fs on them to actually create the filesystems:

# mke2fs/dev/sdb2

Now you can mount it it:

# mount/dev/sdb2 /tmp2

You will likely want to add an entry to /etc/fstab to automatically mount your new partitions at boot:

# device  mountpoint  filesystemtype  options  dump fsckorder
/dev/sdb2     /tmp2    ext2     defaults  1     2

See the man page for fstab for details on all the options available.

If you have difficulties getting your system to recognize your new disk, booting the system with the drive in, or if you are experiencing other SCSI problems, here are a few things to check:

If you have a laptop, then you probably have PCMCIA available on your system. It's the way of getting SCSI, Ethernet, modems, and other types of devices onto it. PCMCIA allows for cards that are low-power, easy to configure, physically small, and standard across different architectures.

The first important thing you should do, if you have not bought a laptop, is check the Linux on Laptops page located at http://www.cs.utexas.edu/users/kharker/linux-laptops. Users that have gotten Linux to work on their laptops have included their notes on how to install Linux on various models. Also of note (specifically for PCMCIA support) is the PCMCIA HOWTO located at http://hyper.stanford.edu/HyperNews/get/pcm-cia/home.html. This page lists PCMCIA cards that are known to exist, along with PCMCIA controllers that also work.

In short, CardBus support is still experimental under Linux, but just about all PCMCIA cards are. A full list of cards that are supported can be found under /usr/doc/pcmcia-*/SUPPORTED.CARDS. CardBus is a faster form of PCMCIA and is used in some high-speed devices, such as Ethernet and SCSI cards.

PCMCIA support is included with Red Hat, is installed as the pcmcia-cs package, and is activated on bootup. If cards are found at boot-time, they're activated. If after bootup a new card is inserted, it'll automatically get started. Cards can be removed without deactivation, and the PCMCIA card manager (cardmgr) will attempt to unload the drivers. If you have network cards, cardmgr will attempt to shut down the network interface and then unload the drivers. If there is network activity going on, the network modules may not unload properly.

You can also manually work with the cards in your system through the cardctl command. Among other commands, cardctl insert indicates that a card has been inserted, and cardctl remove stops a card. Sending a HUP signal to the cardmgr program will force cardmgr to shut down and restart all card services.

You should note that since PCMCIA drivers are kernel modules, they may need to be recompiled when you install a new kernel.

Hard drives that support removable media became almost popular about a decade ago, but then faded. Iomega has resurrected them in the form of its JAZ and ZIP drives. Other companies have begun making comparable products, but none is currently supported under Linux.

ZIP drives have a capacity of 100MB and JAZ drives can hold 1GB. Because of their relatively large sizes, they are much better suited for use as backup media than floppy drives. Additionally, both have considerably better performance than floppy drives. In the case of JAZ drives, the performance is comparable to a SCSI-I hard drive. A ZIP drive has a seek time that is a few times longer and a transfer rate about one-fourth that of a JAZ drive.

/dev/sde1 /jazext2   noauto  0  0

You're probably familiar with how serial ports need speed (BPS), bit size, parity, and stop bit settings. Those settings are on the software side. On the hardware side, things are a bit more complicated. The typical serial port has nine pins associated with it, as described in Table 20-1.

Table 20-1 describes the pinout for a standard 9-pin PC serial connection. When a device like a terminal is connected to the serial port, you need a special pin connection called a null-modem cable. In short, pins 2 and 3 are crossed (leading Tx to Rx, and vice versa) and the RTS/CTS lines are crossed. When connecting to a modem, a "straight through" connection is sufficient.

CD-ROMs are fairly self-explanatory, as support for all ATAPI (IDE) and SCSI CD-ROMS is included with Linux. ATAPI CD-ROMS get their /dev entry based on where they are in the chains. The master device on the primary IDE chain is /dev/hda, and the slave on the primary chain is /dev/hdb. The master on the secondary is /dev/hdc, and the slave on the secondary is /dev/hdc. Note that these entries represent the entire disk, and should only be used for specifying CD-ROMs, as they're one large partition. You can find out where your ATAPI CD-ROM is by examining bootup messages or by looking through the output of the dmesg command.

SCSI CD-ROMs are handled a bit differently in that the first CD-ROM gets an entry of /dev/sr0 instead of being with the hard drives under /dev/sd. The second CD-ROM gets an entry of /dev/sr1, and so on. Again, the results of the dmesg_command can assist in telling you what devices are recognized. Another way of finding out is to check the /proc/scsi directory. This won't tell you what got assigned to which dev entry, but it will list what SCSI devices were found.

CD-R writers (also called CD-R burners and so on) are now getting affordable enough for people to actually purchase them. Linux has the ability to use many different kinds of CD-R and CD-RW (rewritable) devices. Two packages are first required to use them. First is the mkisofs package, which is included with the Red Hat CD-ROM. This program creates an ISO9660 image suitable for writing to a CD-R or CD-RW. The second program is cdrecord, which does the actual burning of the CD-R/CD-RW. The authors have only had access to a SCSI CD-R, so your experience may be different, but probably not by much.

We'll take the safe path first and show you the actual process of burning a CD-ROM. First, you must create an ISO9660 image. This requires enough space on a local drive to store a new image file. If you're going to build a CD-ROM that takes up 600MB of space, you'll need at least that much free space on a partition. The basic syntax for the mkisofs command is:

mkisofs -R -o file.raw /some/directory

The -R does a recursive copy, so everything under /some/directory gets included in the raw file. The -o file.raw indicates that the output of the mkisofs command will go into file.raw. This is where you'll need the space. There are two other options you may want to use. The -V text option includes text as a CD-ROM label that shows up under Windows or MacOS. The ISO9660 specification indicates that files have to be in the old DOS format of eight characters, a dot, and a three-character file extension. Fortunately, there is an extension to ISO9660 that allows for extended filenames called Joliet. Joliet allows for 64 characters in the name of each file. If you choose to use Joliet and an extended filename, add -J.

Now that the ISO image has been created, you can test it out by mounting it and taking a look at it. The command to do this is:

mount -t isofs -o loop file.raw /mnt/cdrom

Replace file.raw with the raw image you just created. You can also replace /mnt/cdrom with some other directory to mount on. The -o loop indicates that a file instead of an actual device is going to be used. This will work, and you can traverse the directories as if they were a CD-ROM. Once you're sure the image is correct, you can unmount the directory and prepare for writing.

With the raw image created, you can now burn the CD-R with cdrecord. First you'll need to know the SCSI ID of the CD-R. This can be found either by looking under /proc/scsi, or by using cdrecord -scanbus and looking at the results. You'll also need to know what speed your CD-R can handle. Most drives now are either double-speed (2x) or quad-speed (4x) for writing. Check your documentation for the capabilities of the CD-R.

Now down to the actual burning. The basic syntax for cdrecord is:

cdrecord -v speed=4 dev=5,0 file.raw

You'll need to change the speed based on the capability of your CD-R. The lowest speed is 1, so if you run into compatibility issues, try knocking the speed down. The -v gives a verbose listing of what's going on. The dev=5,0 lists the SCSI ID for the CD-R device. In this case, it's a SCSI ID of 5 and a LUN of 0. For single CD-R writers, the LUN will be 0. You can replace file.raw with the raw image file you created and tested earlier. During the write process, it's best not to use the machine until the writing is complete. The CD-R is dependent on a FIFO buffer to be full to keep writing to the CD at a constant rate. If that rate drops for any reason, the writing will fail and you'll be left with a coaster.

The time to write the CD-R depends both on the size of the image you're making and the speed of the CD-R. A quad-speed CD-ROM can write a 74-minute CD-R in about 18 minutes, and winds up being about 650MB in size.

Once the CD-R is complete, you can put it in your CD-ROM drive and test it out.

The above instructions describe the hard way, but also the safest. Once you're comfortable with the process, you can turn everything into one step. The following command will create a Joliet CD-ROM on a quad-speed writer at SCSI ID 5:

(nice --18 mkisofs -V text -J -R /some/directory) | cdrecord -v
  speed=4 dev=5,0 -

The nice command provides a high priority to mkisofs, allowing it to dedicate more CPU time to building the ISO image, which is passed via a pipe to the cdrecord program.

In this chapter, we've tried to discuss a reasonably large list of hardware, but there is no way for us to cover all of the hardware available for Linux. Similarly, there are dozens of ways each piece of hardware can be problematic. We discussed how to troubleshoot the most common stumbling blocks, but less common, more esoteric ones certainly exist.

The best places for information on how to deal with problematic hardware are the HOWTOs, the manuals for the hardware, and the manufacturers. Also, some hardware types have their own newsgroups or mailing lists. These are likely to be the best places to ask for help on particularly difficult problems.