This chapter provides overview information and step-by-step instructions for managing peripheral devices, such as disks, CD-ROMs, and tape devices, in the Solaris release.
This is a list of the overview information in this chapter.
This is a list of the step-by-step instructions in this chapter.
Device management in the Solaris release usually involves adding and removing peripheral devices from systems, possibly adding a third-party device driver to support a device, and displaying system configuration information.
This section provides information about new device management features in the Solaris release.
For a complete listing of new Solaris features and a description of Solaris releases, see Solaris Express Developer Edition What’s New.
Solaris Express Developer Edition 1/08: You can use the device detection tool to identify whether your x86 hardware is supported in this Solaris release. For more information, go to the following site:
http://www.sun.com/bigadmin/hcl/hcts/device_detect.jsp
Solaris Express Developer Edition 1/08: This release introduces a new device retirement mechanism to isolate a device as faulty by the fault management framework (FMA). This feature allows faulty devices to be safely and automatically inactivated to avoid data loss, data corruption, or panics and system down time. The retirement process is done safely, taking into account the stability of the system after the device has been retired.
Critical devices are never retired. If you need to manually replace a retired device, use the fmadm repair command after the device replacement so that system knows that the device is replaced, in addition to the manual replacement steps.
The fmadm repair process is as follows:
Identify the faulted device with the fmadm faulty -a command.
# fmadm faulty STATE RESOURCE / UUID -------- --------------------------------------------------------------------- faulty <fmri> |
Clear the fault by using the fmadm repair command.
# fmadm repair <fmri> |
Run the fmadm faulty command again to be sure the fault is cleared.
# fmadm faulty -a STATE RESOURCE / UUID |
For more information, see fmadm(1M).
A general message regarding device retirement is displayed on the console and written to the /var/adm/messages file so that you aware of a retired device. For example:
Aug 9 18:14 starbug genunix: [ID 751201 kern.notice] NOTICE: One or more I/O devices have been retired |
You can use the prtconf command to identify specific retired devices. For example:
# prtconf . . . pci, instance #2 scsi, instance #0 disk (driver not attached) tape (driver not attached) sd, instance #3 sd, instance #0 (retired) scsi, instance #1 (retired) disk (retired) tape (retired) pci, instance #3 network, instance #2 (driver not attached) network, instance #3 (driver not attached) os-io (driver not attached) iscsi, instance #0 pseudo, instance #0 . . . |
Solaris Express 10/06: The /dev name space supports multiple file system instances as needed. A global instance of the /dev file system is created automatically when the system is booted. Subsequent /dev instances are created and mounted when needed, such as when devices are added to a non-global zone. When a non-global zone is shutdown, the available /dev instance is unmounted and unavailable.
In addition, device configuration is improved in the following ways:
Reconfiguration boot is eliminated – In previous Solaris releases, a reconfiguration boot was needed if you connected a device to a system that is powered off.
In this Solaris release, performing a reconfiguration boot is unnecessary when attaching devices to a system that is powered off. Newly attached devices are automatically recognized and the appropriate device links are created when the system is rebooted.
For more information, see dev(7FS).
Zone device support is simplified – As described above, device support for Solaris zones is enhanced by providing specific instances of the /dev directory for non-global zones. In addition, zones are no longer dependent upon the devfsadm daemon for reconfiguration of devices within a zone.
Pseudo device creation is improved – In this Solaris release, the content of the /dev/pts directory is created on demand in the global /dev name space as well as a/dev instance when needed in a non-global zone. In addition, the ptys links are only visible in the global zone or the non-global zone from which they are allocated.
For more information, see grantpt(3C).
For more information about device configuration, see Managing Devices in the Solaris OS.
Solaris Express 4/06: This Solaris release provides support for the PCI Express (PCIe) interconnect, which is designed to connect peripheral devices to desktop, enterprise, mobile, communication, and embedded applications, on both SPARC and x86 systems.
In the previous Solaris Express 1/06 release, PCIe devices were only available on x86 systems.
The PCIe interconnect is an industry-standard, high-performance, serial I/O bus. For details on PCIe technology, go to the following site:
The PCIe software provides the following features in this Solaris release:
Support for extended PCIe configuration space
Support for PCIe baseline error handling and MSI interrupts
Modified IEEE-1275 properties for PCIe devices
PCIe hotplug support (both native and ACPI-based) by enhancing the cfgadm_pci component of the cfgadm command
ATTN Button usage based PCIe peripheral autoconfiguration
The administrative model for hotplugging PCIe peripherals is the same as for PCI peripherals, which uses the cfgadm command.
Check your hardware platform guide to ensure that PCIe and PCIe hotplug support is provided on your system. In addition, carefully review the instructions for physically inserting or removing adapters on your system and the semantics of device auto-configuration, if applicable.
For information about using the cfgadm command with PCIe peripherals, see PCI or PCIe Hot-Plugging With the cfgadm Command (Task Map).
Solaris Express 6/06: In this Solaris release, both non-removable USB storage devices and 1394 mass storage devices are identified as hotpluggable devices at the driver level. This new behavior means that these devices can be connected or disconnected without rebooting the system and configured or unconfigured automatically without intervention. These changes are made at the kernel level and do not impact the use of these devices. For example, the responsibility of mounting and unmounting these devices is controlled by the removable media management services.
In addition, non-removable USB devices and 1394 mass storage devices can be accessed and labeled by using the format utility. However, you can override the new hotpluggable behavior of these devices by setting the remvalue to true in the /kernel/drv/scsa2usb.conf file. Setting this parameter to true means that the device is treated as a removable media device at the driver level, if that behavior is preferred.
For more information on using these devices, see scsa1394(7D) and Using USB Mass Storage Devices (Task Map).
Solaris Express 1/06: This feature was undocumented previously.
The following utilities have been enhanced to detect when a specified device is in use:
dumpadm
format
mkfs and newfs
swap
These enhancements mean that the above utilities might detect some of the following usage scenarios:
Device is part of a ZFS storage pool
Device is a dump or swap device
Mounted file system or an entry for the device exists in the /etc/vfstab file
Device is part of live upgrade configuration
Device is part of a Solaris Volume Manager configuration or Veritas Volume Manager configuration
For example, if you attempt to use the format utility to access an active device, you will see a message similar to the following:
# format . . . Specify disk (enter its number): 1 selecting c0t1d0 [disk formatted] Warning: Current Disk has mounted partitions. /dev/dsk/c0t1d0s0 is currently mounted on /. Please see umount(1M). /dev/dsk/c0t1d0s1 is currently used by swap. Please see swap(1M). |
However, these utilities do not detect all scenarios in the same way. For example, you can use the newfs command to create a new file system on a device in a live upgrade configuration. You cannot use the newfs command to create a new file system on a device that is part of a live upgrade configuration if it also has a mounted file system.
The following table describes where to find step-by-step instructions for hot-plugging devices and adding serial devices, such as printers and modems, and peripheral devices, such as a disk, CD-ROM, or tape device.
Table 5–1 Where to Find Instructions for Adding a Device
Device Management Task |
For More Information |
---|---|
Add a disk that is not hot-pluggable. |
Chapter 12, SPARC: Adding a Disk (Tasks) or Chapter 13, x86: Adding a Disk (Tasks) |
Hot-plug a SCSI or PCI device. |
SCSI Hot-Plugging With the cfgadm Command or PCI or PCIe Hot-Plugging With the cfgadm Command |
Hot-plug a USB device. | |
Add a CD-ROM or tape device. | |
Add a modem. | |
Add a printer. | |
Secure a device. |
Chapter 5, Controlling Access to Devices (Tasks), in System Administration Guide: Security Services |
The following sections provide overview information about features that manage devices in the Solaris OS. For information about accessing devices, see Accessing Devices.
The United States Environmental Protection Agency created the Energy Star® guidelines for computer products to encourage the use of energy-efficient computer systems and to reduce air pollution associated with energy generation. To meet these guidelines, Sun hardware is designed to use power efficiently. In addition, power management software is provided to configure the power management settings.
For more information about power managing your system, see your specific hardware documentation or power.conf(4).
Power management of Sun systems has been provided in many previous Solaris releases. For example, the internal drives on the following systems are power managed by default:
SunBlade 1000 or 2000
SunBlade 100 or 150
SunBlade 2500 or 1500
The default settings in the /etc/power.conf file ensure Energy Star compliance and fully support power management of these systems.
The following adapters connect external Fibre Channel storage devices:
Sun StorEdge PCI Dual Fibre Channel Host Adapter
Sun StorEdge PCI Single Fibre Channel Network Adapter
If a combination of the above adapters and Sun systems are used to attach external Fibre Channel storage devices, the external storage devices will also be power managed by default.
Under the following conditions, power management should be disabled:
If the system has Fibre Channel attached disks that are connected to a storage area network (SAN)
If the system has Fibre Channel attached disks that are used in a multi-initiator configuration, such as with the SunCluster software
If the system is using IP over a Fibre Channel interface (see fcip(7D))
Power management should not be enabled when more than one Solaris system might share the same devices, as in the above conditions.
You can disable power management for the system by changing the autopm keyword in the /etc/power.conf file as follows:
autopm disable |
Then, reconfigure power management by running the pmconfig command or by rebooting the system.
For more information, see power.conf(4) and pmconfig(1M).
A computer typically uses a wide range of peripheral devices and mass-storage devices. Your system, for example, probably has a disk drive, a keyboard and a mouse, and some kind of magnetic backup medium. Other commonly used devices include the following:
CD-ROM drives
Printers and plotters
Light pens
Touch-sensitive screens
Digitizers
Tablet-and-stylus pairs
The Solaris software does not directly communicate with all these devices. Each type of device requires different data formats, protocols, and transmission rates.
A device driver is a low-level program that allows the operating system to communicate with a specific piece of hardware. The driver serves as the operating system's “interpreter” for that piece of hardware.
The kernel consists of a small generic core with a platform-specific component and a set of modules. The kernel is configured automatically in the Solaris release.
A kernel module is a hardware or software component that is used to perform a specific task on the system. An example of a loadable kernel module is a device driver that is loaded when the device is accessed.
The platform-independent kernel is /kernel/genunix. The platform-specific component is /platform/`uname -m`/kernel/unix.
The kernel modules are described in the following table.
Table 5–2 Description of Solaris Kernel Modules
Location |
Directory Contents |
---|---|
/platform/`uname -m`/kernel |
Platform-specific kernel components |
/kernel |
Kernel components common to all platforms that are needed for booting the system |
/usr/kernel |
Kernel components common to all platforms within a particular instruction set |
The system determines what devices are attached to it at boot time. Then, the kernel configures itself dynamically, loading needed modules into memory. At this time, device drivers are loaded when devices, such as disk devices and tape devices, are accessed. This process is called autoconfiguration because all kernel modules are loaded automatically when they are needed.
You can customize the way in which kernel modules are loaded by modifying the /etc/system file. For instructions on modifying this file, see system(4).
The benefits of autoconfiguration are as follows:
Main memory is used more efficiently because modules are loaded when needed.
There is no need to reconfigure the kernel when new devices are added to the system.
Drivers can be loaded and tested without having to rebuild the kernel and reboot the system.
Autoconfiguration is used when you add a new device (and driver) to the system. In previous Solaris releases, it was necessary to perform a reconfiguration boot if you added a device to a system that is shutdown. Starting in the Solaris Express 10/06 release, device configuration enhancements make a reconfiguration boot unnecessary when a device is added to a system that is shutdown.
You can add, remove, or replace devices in the Solaris OS while the system is still running, if the system components support hot-plugging. For information about hot-plugging devices, see Chapter 6, Dynamically Configuring Devices (Tasks).
Device drivers needed to support a wide range of standard devices are included in the Solaris release. These drivers can be found in the /kernel/drv and /platform/`uname -m`/kernel/drv directories.
However, if you have purchased an unsupported device, the manufacturer should provide the software that is needed for the device to be properly installed, maintained, and administered.
At a minimum, this software includes a device driver and its associated configuration (.conf) file. The .conf files reside in the drv directories. This software might also include custom maintenance and administrative utilities because the device might be incompatible with Solaris utilities.
For more information about what you need for unsupported devices, contact your device manufacturer.
Three commands are used to display system and device configuration information.
Command |
Description |
Man Page |
---|---|---|
prtconf |
Displays system configuration information, including the total amount of memory and the device configuration as described by the system's device hierarchy. The output displayed by this command depends upon the type of system. | |
sysdef |
Displays device configuration information, including system hardware, pseudo devices, loadable modules, and selected kernel parameters. | |
dmesg |
Displays system diagnostic messages as well as a list of devices attached to the system since the last reboot. |
For information on the device names that are used to identify devices on the system, see Device Naming Conventions.
The following driver-related message might be displayed by the prtconf and sysdef commands:
device, instance #number (driver not attached) |
This message does not always mean that a driver is unavailable for this device. This message means that no driver is currently attached to the device instance because no device exists at this node or the device is not in use. Drivers are loaded automatically when the device is accessed. They are unloaded when the device is not in use.
Use the output of the prtconf and sysdef commands to identify which disk, tape, and CD-ROM devices are connected to the system. The output of these commands displays the driver not attached messages next to the device instances. Because these devices are always being monitored by some system process, the driver not attached message is usually a good indication that no device exists at that device instance.
Use the sysdef command to display system configuration information that include pseudo devices, loadable modules, and selected kernel parameters.
Display system and device configuration information.
Display all the devices connected to a system.
For example, the following prtconf -v output on a SunBlade 1000 identifies the disk devices connected to the system. The detailed disk information is described in the Device Minor Nodes section within the ssd/fp driver section.
$ /usr/sbin/prtconf -v | more . . . Device Minor Nodes: dev=(118,8) dev_path=/pci@8,600000/SUNW,qlc@4/fp@0,0/ssd@w210000 2037bde864,0:a spectype=blk type=minor dev_link=/dev/dsk/c0t1d0s0 dev_path=/pci@8,600000/SUNW,qlc@4/fp@0,0/ssd@w210000 2037bde864,0:a,raw spectype=chr type=minor dev_link=/dev/rdsk/c0t1d0s0 dev=(118,9) dev_path=/pci@8,600000/SUNW,qlc@4/fp@0,0/ssd@w210000 2037bde864,0:b spectype=blk type=minor dev_link=/dev/dsk/c0t1d0s1 dev_path=/pci@8,600000/SUNW,qlc@4/fp@0,0/ssd@w210000 2037bde864,0:b,raw . . . |
Display information about one specific device connected to the system.
For example, the following prtconf output on a SunBlade 1000 displays the ssd instance number for /dev/dsk/c0t1d0s0.
# prtconf -v /dev/dsk/c0t1d0s0 ssd, instance #1 |
Display only the devices that are attached to the system.
# prtconf | grep -v not |
Display device usage information.
For example, the following fuser command displays which processes are accessing the /dev/console device.
# fuser -d /dev/console /dev/console: 346o 323o # |
The following prtconf output is displayed on a SPARC based system.
# prtconf System Configuration: Sun Microsystems sun4u Memory size: 512 Megabytes System Peripherals (Software Nodes): SUNW,Sun-Blade-1000 scsi_vhci, instance #0 packages (driver not attached) SUNW,builtin-drivers (driver not attached) deblocker (driver not attached) disk-label (driver not attached) terminal-emulator (driver not attached) obp-tftp (driver not attached) dropins (driver not attached) kbd-translator (driver not attached) ufs-file-system (driver not attached) chosen (driver not attached) openprom (driver not attached) client-services (driver not attached) options, instance #0 aliases (driver not attached) memory (driver not attached) virtual-memory (driver not attached) SUNW,UltraSPARC-III, instance #0 memory-controller, instance #0 SUNW,UltraSPARC-III, instance #1 memory-controller, instance #1 pci, instance #0 ebus, instance #0 flashprom (driver not attached) bbc (driver not attached) ppm, instance #0 i2c, instance #0 dimm-fru, instance #0 dimm-fru, instance #1 dimm-fru, instance #2 dimm-fru, instance #3 nvram, instance #4 idprom (driver not attached) i2c, instance #1 cpu-fru, instance #5 temperature, instance #0 cpu-fru, instance #6 temperature, instance #1 fan-control, instance #0 motherboard-fru, instance #7 i2c-bridge (driver not attached) beep, instance #0 rtc, instance #0 gpio (driver not attached) pmc (driver not attached) floppy (driver not attached) parallel (driver not attached) serial, instance #0 network, instance #0 firewire, instance #0 usb, instance #0 scsi (driver not attached) disk (driver not attached) tape (driver not attached) scsi (driver not attached) disk (driver not attached) tape (driver not attached) pci, instance #1 SUNW,qlc, instance #0 fp (driver not attached) disk (driver not attached) fp, instance #1 ssd, instance #1 ssd, instance #0 (driver not attached) ssd, instance #2 (driver not attached) ssd, instance #3 (driver not attached) ssd, instance #4 (driver not attached) ssd, instance #5 (driver not attached) ssd, instance #6 (driver not attached) upa, instance #0 SUNW,ffb, instance #0 (driver not attached) ppm, instance #0 pseudo, instance #0 |
The following sysdef output is displayed from an x86 based system.
# sysdef * Hostid * 29f10b4d * * i86pc Configuration * * * Devices * +boot (driver not attached) memory (driver not attached) aliases (driver not attached) chosen (driver not attached) i86pc-memory (driver not attached) i86pc-mmu (driver not attached) openprom (driver not attached) options, instance #0 packages (driver not attached) delayed-writes (driver not attached) itu-props (driver not attached) isa, instance #0 motherboard (driver not attached) pnpADP,1542, instance #0 asy, instance #0 asy, instance #1 lp, instance #0 (driver not attached) fdc, instance #0 fd, instance #0 fd, instance #1 (driver not attached) kd (driver not attached) kdmouse (driver not attached) . . . |
Adding a new peripheral device that is not-pluggable usually involves the following:
Shutting down the system
Connecting the device to the system
Rebooting the system
Use How to Add a Peripheral Device to add the following devices that are not hot-pluggable to a system:
CD-ROM
Secondary disk drive
Tape drive
SBUS card
In some cases, you might have to add a third-party device driver to support the new device.
For information on hot-plugging devices, see Chapter 6, Dynamically Configuring Devices (Tasks).
Become superuser.
(Optional) If you need to add a device driver to support the device, complete the procedure How to Add a Device Driver.
Shut down the system.
# shutdown -i0 -g30 -y |
Brings the system to the 0 init state, which is the appropriate state for turning the system power off for adding and removing devices.
Shuts the system down in 30 seconds. The default is 60 seconds.
Continues the system shutdown without user intervention. Otherwise, you are prompted to continue the shutdown process.
Select one of the following to turn off power to the system after it is shut down:
For SPARC platforms, it is safe to turn off power if the ok prompt is displayed.
For x86 platforms, it is safe to turn off power if the type any key to continue prompt is displayed.
Turn off power to all peripheral devices.
For the location of power switches on any peripheral devices, refer to the hardware installation guides that accompany your peripheral devices.
Install the peripheral device, making sure that the device you are adding has a different target number than the other devices on the system.
Often, a small switch is located at the back of the disk for selecting the target number.
Refer to the hardware installation guide that accompanies the peripheral device for information on installing and connecting the device.
Turn on the power to the system.
The system boots to multiuser mode, and the login prompt is displayed.
Verify that the peripheral device has been added by attempting to access the device.
For information on accessing the device, see Accessing Devices.
This procedure assumes that the device has already been added to the system. If not, see What You Need for Unsupported Devices.
Become superuser.
Place the tape, diskette, or CD-ROM into the drive.
Install the driver.
# pkgadd [-d] device package-name |
Identifies the device path name that contains the package.
Identifies the package name that contains the device driver.
Verify that the package has been added correctly.
# pkgchk package-name # |
The system prompt returns with no response if the package is installed correctly.
The following example shows how to install and verify a package called XYZdrv.
# pkgadd XYZdrv (licensing messages displayed) . . . Installing XYZ Company driver as <XYZdrv> . . . Installation of <XYZdrv> was successful. # pkgchk XYZdrv # |
You need to know how to specify device names when using commands to manage disks, file systems, and other devices. In most cases, you can use logical device names to represent devices that are connected to the system. Both logical and physical device names are represented on the system by logical and physical device files.
When a system is booted for the first time, a device hierarchy is created to represent all the devices connected to the system. The kernel uses the device hierarchy information to associate drivers with their appropriate devices. The kernel also provides a set of pointers to the drivers that perform specific operations.
The devfs file system manages the /devices directory, which is the name space of all devices on the system. This directory represents the physical devices that consists of actual bus and device addresses.
The dev file system manages the /dev directory, which is the name space of logical device names.
By default, the devfsadm command attempts to load every driver in the system and attach to all possible device instances. Then, devfsadm creates the device files in the /devices directory and the logical links in the /dev directory. The devfsadm command also maintains the path_to_inst instance database.
Updates to the /dev and /devices directories in response to dynamic reconfiguration events or file system accesses are handled by devfsadmd, the daemon version of the devfsadm command. This daemon is started by the service management facility when a system is booted.
Because the devfsadmd daemon automatically detects device configuration changes generated by any reconfiguration event, there is no need to run this command interactively.
For more information, see the following references:
dev(7FS)
Devices are referenced in three ways in the Solaris OS.
Physical device name – Represents the full device path name in the device information hierarchy. The physical device name is created by when the device is first added to the system. Physical device files are found in the /devices directory.
Instance name – Represents the kernel's abbreviation name for every possible device on the system. For example, sd0 and sd1 represent the instance names of two disk devices. Instance names are mapped in the /etc/path_to_inst file.
Logical device name – The logical device name is created by when the device is first added to the system. Logical device names are used with most file system commands to refer to devices. For a list of file commands that use logical device names, see Table 5–3. Logical device files in the /dev directory are symbolically linked to physical device files in the /devices directory.
The preceding device name information is displayed with the following commands:
dmesg
format
sysdef
prtconf
Logical device names are used to access disk devices when you perform the following tasks:
Add a new disk to the system.
Move a disk from one system to another system.
Access or mount a file system residing on a local disk.
Back up a local file system.
Many administration commands take arguments that refer to a disk slice or file system.
Refer to a disk device by specifying the subdirectory to which it is symbolically linked, either /dev/dsk or /dev/rdsk, followed by a string identifying the particular controller, disk, and slice.
Disk and file administration commands require the use of either a raw (or character) device interface, or a block device interface. The distinction is made by how data is read from the device.
Raw device interfaces transfer only small amounts of data at a time. Block device interfaces include a buffer from which large blocks of data are read at once.
Different commands require different interfaces:
When a command requires the raw device interface, specify the /dev/rdsk subdirectory. (The “r” in rdsk stands for “raw.”)
When a command requires the block device interface, specify the /dev/dsk subdirectory.
When you are not sure whether a command requires use of /dev/dsk or /dev/rdsk, check the man page for that command.
The following table shows which interface is required for some commonly used disk and file system commands.
Table 5–3 Device Interface Type Required by Some Frequently Used Commands
Command Reference |
Interface Type |
Example of Use |
---|---|---|
Block |
df /dev/dsk/c0t3d0s6 |
|
Raw |
fsck -p /dev/rdsk/c0t0d0s0 |
|
Block |
mount /dev/dsk/c1t0d0s7 /export/home |
|
Raw |
newfs /dev/rdsk/c0t0d1s1 |
|
Raw |
prtvtoc /dev/rdsk/c0t0d0s2 |
You might access disk partitions or slices differently depending upon whether the disk device is connected to a direct or bus-oriented controller. Generally, direct controllers do not include a target identifier in the logical device name.
The conventions for both types of controllers are explained in the following subsections.
Controller numbers are assigned automatically during system initialization. The numbers are strictly logical and imply no direct mapping to physical controllers.
To specify a slice on a disk with an IDE controller on an x86 based system, follow the naming convention shown in the following figure.
To indicate the entire Solaris fdisk partition, specify slice 2 (s2).
If you have only one controller on your system, w is usually 0.
To specify a slice on a disk with a bus-oriented controller, SCSI for instance, follow the naming convention shown in the following figure.
On a SPARC based system with directly connected disks such as the IDE disks on an UltraSPARC® system, the naming convention is the same as that for systems with bus-oriented controllers.
If you have only one controller on your system, w is usually 0.
For SCSI controllers, x is the target address set by the switch on the back of the unit, and y is the logical unit number (LUN) of the drive attached to the target. If the disk has an embedded controller, y is usually 0. For more information about SCSI addressing on SPARC based systems, see the SunSolveSM Info Doc 48041 and scsi_address(9S).
To indicate the whole disk, specify slice 2 (s2).
Logical tape device files are found in the /dev/rmt/* directory as symbolic links from the /devices directory.
The first tape device connected to the system is 0 (/dev/rmt/0). Tape density values (l, m, h, c, and u) are described in Chapter 30, Managing Tape Drives (Tasks).
Since removable media is managed by removable media management services, the logical device name is usually not used unless you want to mount the media manually.
The logical device name that represents the removable media devices on a system are described in Chapter 3, Accessing Removable Media (Tasks).