PART IPART IPART IPART IPART VII Chapter 25: Devices and Modules 571 Once you have the device’s /sys path, you can use that path to display information about it. Use the udevinfo command again with the -a option to display all information about the device and the -p option to specify its path in the /sys file system. The listing can be extensive, so you should pipe the output to less or redirect it to a file: udevinfo -a -p /sys/class/usb/lp0 | less Some of the key output to look for is the bus used and information such as the serial number, product name, or manufacturer, as shown next. Look for information that uniquely identifies the device, such as the serial number. Some devices will support different buses, and the information may be different for each. Be sure to use the information for that bus when setting up your keys in the udev rule. BUS="usb" ATTRS{serial}="300HCR" ATTRS{manufacturer}="Canon" ATTRS{idproduct}="1074" ATTRS{product}="S330" You can use much of this information in an ATTRS (attributes) key in an udev rule to identify the device. The ATTRS key is used to obtain /sys information about a device. You use the ATTRS key with the field you want referenced placed in braces. You can then match that field to a value to reference the particular device you want. Use the = sign and a valid field value to match against. Once you know the /sys serial number of a device, you can use it in ATTRS keys in udev rules to reference the device uniquely. The following key checks the serial number of the devices field for the Canon printer’s serial number: ATTRS{serial}=="300HCR" A user rule can now be created for the Canon printer. In another rules file, you can add your own symbolic link using /sys information to uniquely identify the printer and name the device with its official kernel name. The first two keys, BUS and ATTRS, specify the particular printer. In this case the serial number of the printer is used to uniquely identify it. The NAME key will name the printer using the official kernel name, always referenced with the %k code. Since this is a USB printer, its device file will be placed in the usb subdirectory, usb/%k. Then the SYMLINK key defines the unique symbolic name to use, in this case canon-pr in the /dev/usb directory: BUS=="usb", ATTRS{serial}=="300HCR", NAME="usb/%k", SYMLINK="usb/canon-pr" The rules are applied dynamically in real time. To run a new rule, simply attach your USB printer (or detach and reattach). You will see the device files automatically generated. Permission Fields: MODE, GROUP, OWNER Permissions that will be given to different device files are determined by the permission fields in the udev rules. The permission rules are located in the 40-permissions.rules file. The MODE field is a octal-bit permission setting, the same that is used for file permissions. Usually this is set to 660, owner and group read/write permission. Pattern matching is supported with the *, ?, and [] operators. 572 Part VII: System Administration USB printer devices use the lp group with mode 660: KERNEL=="usb/lp*", GROUP="lp", MODE="0660" Tape devices use the disk group: KERNEL=="npt*", GROUP="disk", MODE="0660" The default settings set the OWNER and GROUP to root with owner read/write permissions (600): KERNEL=="*", OWNER="root" GROUP="root", MODE="0600" Hardware Abstraction Layer The purpose of HAL is to abstract the process of applications accessing devices. Applications should not have to know anything about a device, even its symbolic name. The application should just have to request a device of a certain type, and then a service, such as HAL, should provide what is available. With HAL, device implementation is hidden from applications. HAL makes devices easily available to desktops and applications using a D-BUS (device bus) structure. Devices are managed as objects that applications can easily access. The D-BUS service is provided by the HAL daemon, haldaemon. Interaction with the device object is provided by the freedesktop.org HAL service, which is managed by the /org/freedesktop/ HAL/Manager. HAL is an information service for devices. The HAL daemon maintains a dynamic database of connected hardware devices. This information can be used by specialized callout programs to maintain certain device configuration files. This is the case with managing removable storage devices. HAL will invoke the specialized callout programs that will use HAL information to manage devices dynamically. Removable devices such as CD-ROM discs or USB card readers are managed by specialized callouts with HAL information, detecting when such devices are attached. The situation can be confusing: Callout programs perform the actual tasks, but HAL provides the device information. For example, though the callout hal-system-storage-mount mounts a device, the options and mountpoints used for CD-ROM entries are specified in HAL device information files that set policies for storage management. HAL has a key impact on the /etc/fstab file used to manage file systems. No longer are entries maintained in the /etc/fstab file for removable devices such as CD-ROMs. These devices are managed directly by HAL using its set of storage callouts such as hal-storage-mount to mount a device or hal-storage-eject to remove one. In effect, you now have to use the HAL device information files to manage your removable file systems. HAL is a software project of freedesktop.org, which specializes in open source desktop tools. Check the latest HAL specification documentation at www.freedesktop.org under the software/HAL page for detailed explanations of how HAL works (see the specifications link on the HAL page: Latest HAL Specification). The documentation is very detailed and complete. PART IPART IPART IPART IPART VII Chapter 25: Devices and Modules 573 The HAL Daemon and hal-device-manager (hal-gnome) The HAL daemon, hald, is run as the haldaemon process. Information provided by the HAL daemon for all your devices can be displayed using the HAL device manager, hal-device-manager, which is part of the hal-gnome package. You can access it, once installed, by choosing System | Administration | Hardware. When you run the manager, it displays an expandable tree of your devices arranged by category in the left panel. The right panel displays information about the selected device. A Device tab lists the basic device information such as the vendor and the bus type. The Advanced tab lists the HAL device properties defined for this device, as described in later sections, as well as /sys file system paths for this device. For device controllers, a USB or PCI tab will appear. For example, a DVD writer could have an entry for the storage.cdrom.cdr property that says it can write CD-R discs. You may find an IDE CD/DVD-ROM device under IDE (some third-party IDE controllers may be labeled as SCSI devices). A typical entry would look like the following; the bool is the type of entry, namely Boolean: storage.cdrom.cdr bool true Numerical values may use an int type or a strlist type. The following write_speed property has a value 7056: storage.cdrom.write_speed strlist 7056 The /sys file system path will also be a string. It will be preceded by a Linux property category. Strings will use a strlist type for multiple values and string for single values. The following entry locates the /sys file system path at /sys/block/hdc: linux.sysfs_path strlist /sys/block/hdc HAL Configuration: /etc/hal/fdi and /usr/share/hal/fdi Information about devices and policies to manage devices are held in device information files in the /etc/hal/fdi and /usr/share/hal/fdi directories. In these directories, you set properties such as options that are to be used for CD-ROMs in /etc/fstab. The implementation of HAL on Linux configures storage management by focusing on storage methods for mountable volumes, instead of particular devices. Volume properties define actions to take and valid options that can be used. Special callouts perform the actions directly, such as hal-storage-mount to mount media or hal-storage-eject to remove it. Device Information Files: fdi HAL properties for these devices are handled by device information files (fdi) in the /usr/share/ hal/fdi and /etc/hal/fdi directories. The /usr/share/hal/fdi directory is used for configurations provided by the distribution, whereas /etc/hal/fdi is used for setting user administrative configurations. In both are listed subdirectories for the different kinds of information that HAL manages, such as policy, whose subdirectories have files with policies for how to manage devices. The files, known as device information files, have rules for obtaining information about devices, as well rules for detecting and assigning options for removable devices. The device information files use the extension .fdi, as in storage-methods.fdi. For example, the policy 574 Part VII: System Administration directory has two subdirectories: 10osvendor and 20thirdpary. The 10osvendor holds the fdi files that have policy rules for managing removable devices on Linux (10osvendor replaces 90defaultpolicy in earlier HAL versions). This directory holds the 20-storage-methods.fdi policy file used for storage devices. Here you will find the properties that specify options for removable storage devices such as CD-ROMs. The directories begin with numbers, and lower numbers are read first. Unlike with udev, the last property read will override any previous property settings, so priority is given to higher-numbered directories and the fdi files they hold. This is why the default policies are in 10osvendor, whereas the user policies, which override the defaults, are in a higher-numbered directory such as 30user, as are third-party policies in 20thirdpolicy. Three device information file directories are set up in the device information file directories, each for different kinds of information: information, policy, and preprobe: • information Contains information about devices. • policy Contains setting policies such as storage policies. The default policies for a storage device are in a 20-storage-methods.fdi file in the policy/10osvendor directory. • preprobe Handles difficult devices such as unusual drives or drive configurations— for instance, those in preprobe/10osvendor/10-ide-drives.fdi. This contains information needed even before the device is probed. Within these subdirectories are still other subdirectories indicating where the device information files come from, such as vendor, thirdparty, or user, and their priority. Certain critical files are listed here: • information/10freedesktop Information provided by freedesktop.org • policy/10osvendor Default policies (set by system administrator and OS distribution) • preprobe/10usevendor Preprobe policies for difficult devices Properties Information for a device is specified with a property entry. Such entries consist of a key/value pair, where the key specifies the device and its attribute, and the value is for that attribute. Many kinds of values can be used, such as Boolean true/false, string values such as those used to specify directory mountpoints, or integer values. Properties are classified according to metadata, physical connection, function, and policies. Metadata provides general information about a device, such as the bus it uses, its driver, or its HAL ID. Metadata properties begin with the key info, as in info.bus. Physical properties describe physical connections, namely the buses used. The IDE, PCI, and SCSI bus information is listed in ide, pci, and scsi keys. The usb_device properties are used for the USB bus; an example is usb_device.number. The functional properties apply to specific kinds of devices. Here you will find properties for storage devices, such as the storage.cdrom keys that specify whether an optical device has writable capabilities. For example, the storage.cdrom.cdr key set to true will specify that an optical drive can write to CD-R discs. The policies are not properties as such. Policies indicate how devices are to be handled and are, in effect, the directives that callout programs use to carry out tasks. Policies for storage media are handled using Volume properties, specifying methods (callouts) to use PART IPART IPART IPART IPART VII Chapter 25: Devices and Modules 575 and valid options such as mount options. HAL uses scripts in the /usr/share/hal/scripts directory to manage media. The following abbreviated entries come from the 20-storage- methods.fdi policy file. The first specifies the action to take and the second the callout script to execute, hal-storage-mount: <append key="Volume.method_names" type="strlist">Mount</append> <append key="Volume.method_execpaths" type="strlist">hal-storage-mount</append> Mount options are designated using volume.mount.valid_options as shown here for ro (read only). Options that will be used will be determined when the mount callout is executed. <append key="volume.mount.valid_options"type="strlist">ro</append> Several of the commonly used volume policy properties are listed in Table 25-6. Device Information File Directives Properties are defined in directives listed in device information files. As noted, device information files have .fdi extensions. A directive is encased in greater-than (>) and less-than (<) symbols. There are three directives: • merge Merges a new property into a device’s information database • append Appends or modifies a property for that device already in the database • match Tests device information values A directive includes a type attribute designating the type of value to be stored, such as string, bool, int, and double. The copy_property type copies a property. The following discussion of the storage-methods.fdi file shows several examples of merge and match directives. Property Description volume.method.execpath Callout script to be run for a device volume.policy.desired_mount_point (string) The preferred mountpoint for the storage device volume.mount.valid_options.* (bool) Mount options to use for specific device, where * can be any mount option, such as noauto or exec volume.method_names Action to be taken volume.policy.mount_filesystem (string) File system to use when mounting a volume volume.mount.valid.mount_options.* (bool) Default mount options for volumes, where * can be any mount option, such as noauto or exec T ABLE 25-6 HAL Storage Policies 576 Part VII: System Administration storage.fdi The 20-storage-methods.fdi file in the /usr/share/hal/fdi/policy/10osvendor directory lists the policies for your removable storage devices. This is where your options for storage volumes (for example, CD-ROM) entries are actually specified. The file is organized in sections beginning with particular types of devices to standard defaults. Keys are used to define options, such as volume.mount.valid_options, which will specify a mount option for a storage device such as a CD-ROM. Keys are also used to specify exceptions such as hotplugged devices. The 20-storage-methods.fdi file begins with default properties and then lists those properties for specific kinds of devices. Unless redefined in a later key, the default will remain in effect. The options you see listed for the default storage volumes will apply to CD-ROMs. For example, the noexec option is set as a valid default. The following sets noexec as a default mount option for a storage device. There are also entries for ro and quiet. The append operation adds the policy option. <append key="volume.mount.valid_options"type="strlist">noexec</append> The default mountpoint root directory for storage devices is now set by the mount callout script, hal-storage-mount. Currently this is /media. The default mountpoint is disk. HAL will try to use the Volume property information to generate a mountpoint. The following example manages blank disks. Instead of being mounted, such disks can only be ejected. To determine possible actions, HAL uses method_names, method_ signatures, and method_execpaths for the Volume properties. (The org.freedesktop.Hal prefix for the keys has been removed from this example to make it more readable, as in org.freedesktop.Hal.Volume.method_names.) <match key="volume.disc.is_blank" bool="true"> <append key="info.interfaces"type="strlist">Volume</append> <append key="Volume.method_names" type="strlist">Eject</append> <append key="Volume.method_signatures" type="strlist">as</append> <append key="Device.Volume.method_execpaths" type="strlist"> hal-storage-eject</append> </match> After dealing with special cases, the file system devices are matched, as shown here: <match key="volume.fsusage" string="filesystem"> Storage devices to ignore, such as recovery partitions, are specified: <merge key="volume.ignore" type="bool">false</merge> Then the actions to take and the callout script to use are specified, such as the action for unmount that uses hal-storage-mount: <append key="Device.Volume.method_names" type="strlist">Mount</append> <append key="Device.Volume.method_signatures" type="strlist">ssas</append> <append key="Device.Volume.method_execpaths" type="strlist"> hal-storage-mount</append> PART IPART IPART IPART IPART VII Chapter 25: Devices and Modules 577 Options are then specified with volume.mount.valid_options, starting with defaults and continuing with special cases, such as ext3 shown here for access control lists (acl) and extended attributes (xattr): <! allow these mount options for ext3 > <match key="volume.fstype" string="ext3"> <append key="volume.mount.valid_options"type="strlist">acl=</append> <append key="volume.mount.valid_options"type="strlist">user_xattr=</append> <append key="volume.mount.valid_options"type="strlist">data=</append> </match> HAL Callouts Callouts are programs invoked when the device object list is modified or when a device changes. As such, callouts can be used to maintain systemwide policy (that may be specific to the particular OS) such as changing permissions on device nodes, managing removable devices, or configuring the networking subsystem. Three different kinds of callouts are used for devices, capabilities, and properties. Device callouts are run when a device is added or removed. Capability callouts add or remove device capabilities, and property callouts add or remove a device’s property. Callouts are implemented using info.callout property rules, such as that which invokes the hal-storage-mount callout when CD/DVD-ROMs are inserted or removed, as shown here: <append key="org.freedesktop.Hal.Device.Volume.method_execpaths" type="strlist">hal-storage-mount</append> Callouts are placed in the /usr/lib/hal directory with the HAL callouts prefixed with hal Here you will find many of storage callouts used by HAL, such as hal-storage-eject and hal-storage-mount. HAL uses these callouts to manage removable devices such as DVD/ CD-ROMs directly instead of editing entries in the /etc/fstab file (fstab-sync is no longer used). The gnome-mount tool used for mounting CD/DVD disk on the GNOME desktop uses the HAL callouts. Other supporting scripts can be found in the /usr/lib/hal/scripts directory. Manual Devices You can, if you wish, create device file interfaces manually using the MAKEDEV or mknod command. MAKEDEV is a script that can create device files for known fixed devices such as attached hard disks. Check the MAKEDEV man page for details. Ubuntu relies on aliases in the /etc/modprobe.d directory to manage most fixed devices: /etc/modprobe.d/aliases. Linux implements several types of devices, the most common of which are block and character. A block device, such as a hard disk, transmits data a block at a time. A character device, such as a printer or modem, transmits data one character at a time, or rather as a continuous stream of data, not as separate blocks. Device driver files for character devices have a c as the first character in the permissions segment displayed by the ls command. Device driver files for block devices have a b. In the next example, lp0 (the printer) is a character device and sda1 (the hard disk) is a block device: # ls -l sda1 lp0 brw-rw 1 root disk 3, 1 Jan 30 02:04 sda1 crw-rw 1 root lp 6, 0 Jan 30 02:04 lp0 578 Part VII: System Administration The device type can be either b, c, p, or u. The b indicates a block device, and c is for a character device. The u is for an unbuffered character device, and the p is for a FIFO (first in, first out) device. Devices of the same type often have the same name; for example, serial interfaces all have the name ttyS. Devices of the same type are then uniquely identified by a number attached to the name. This number has two components: the major number and the minor number. Devices may have the same major number, but if so, the minor number is always different. This major and minor number structure is designed to deal with situations in which several devices may be dependent on one larger device, such as several modems connected to the same I/O card. All the modems will have the same major number that references the card, but each modem will have a unique minor number. Both the minor and major numbers are required for block and character devices (b, c, and u). They are not used for FIFO devices, however. Valid device names along with their major and minor numbers are listed in the devices.txt file located in the /Documentation directory for the kernel source code, /usr/src/linux-ver/ Documentation. When you create a device, you use the major and minor numbers as well as the device name prefix for the particular kind of device you are creating. Most of these devices are already created for you and are listed in the /etc/dev directory. Though the MAKEDEV command is preferable for creating device files, it can create only files for which it is configured. For devices not configured for use by MAKEDEV, you will have to use the mknod command. This is a lower level command that requires manual configuration of all its settings. With the mknod command you can create a device file in the traditional manner without any of the configuration support that MAKEDEV provides. The mknod command can create either a character or block-type device. The mknod command has the following syntax: mknod options device device-type major-num minor-num As a simple example, creating a device file with mknod for a printer port is discussed here. Linux systems usually provide device files for printer ports (lp0–2). As an example, you can see how an additional port could be created manually with the mknod command. Printer devices are character devices and must be owned by the root and daemon. The permissions for printer devices are read and write for the owner and the group, 660. The major device number is set to 6, while the minor device number is set to the port number of the printer, such as 0 for LPT1 and 1 for LPT2. Once the device is created, you use chown to change its ownership to the root user, since only the administrator should control it. Change the group to lp with the chgrp command. Most devices belong to their own groups, such as disks for hard disk partitions, lp for printers, floppy for floppy disks, and tty for terminals. In the next example, a printer device is made on a fourth parallel port, lp3. The -m option specifies the permissions—in this case, 660. The device is a character device, as indicated by the c argument following the device name. The major number is 6, and the minor number is 3. If you were making a device at lp4, the major number would still be 6, but the minor number would be 4. Once the device is made, the chown command then changes the ownership of the parallel printer device to root. For printers, be sure that a spool directory has been created for your device. If not, you need to make one. Spool directories contain files for data that varies according to the device PART IPART IPART IPART IPART VII Chapter 25: Devices and Modules 579 output or input, like that for printers or scanners. As with all manual devices, the device file has to be placed in the /etc/udev/devices directory; udev will later put it in /dev. # mknod -m 660 /etc/udev/devices/lp3 c 6 3 # chown root /etc/udev/devices/lp3 # chgrp lp /etc/udev/devices/lp3 Installing and Managing Terminals and Modems In Linux, several users may be logged in at the same time. Each user needs his or her own terminal through which to access the Linux system, of course. The monitor on your PC acts as a special terminal, called the console, but you can add other terminals through either the serial ports on your PC or a special multiport card installed on your PC. The other terminals can be standalone terminals or PCs using terminal emulation programs. For a detailed explanation of terminal installation, see the Term-HOWTO file in /usr/share/doc/HOWTO or at the Linux Documentation Project site (http://tldp.org). A brief explanation is provided here. Serial Ports The serial ports on your PC are referred to as COM1, COM2, COM3, and COM4. These serial ports correspond to the terminal devices /dev/ttyS0 through /dev/ttyS3. Note that several of these serial devices may already be used for other input devices such as your mouse and for communications devices such as your modem. If you have a serial printer, one of these serial devices is already used for that. If you installed a multiport card, you have many more ports from which to choose. For each terminal you add, udev will create the appropriate character device on your Linux system. The permissions for a terminal device are normally 660. Terminal devices are character devices with a major number of 4 and minor numbers usually beginning at 64. TIP TIP The /dev/pts entry in the /etc/fstab file mount a devpts file system at /dev/pts for Unix98 Pseudo-TTYs. These pseudoterminals are identified by devices named by number. mingetty, mgetty, and getty Terminal devices are managed by your system using the getty program and a set of configuration files. When your system starts, it reads the files of connected terminals in the Upstart /etc/events.d directory. Terminal files are prefixed with tty and have the terminal device number attached, such as tty2. The files executes an appropriate getty program for each terminal. These getty programs set up the communication between your Linux system and a specified terminal. You can install other getty applications to use instead, such as mgetty and mingetty. mingetty provides minimal support for virtual consoles. mgetty is designed for fax/modem connections, letting you configure dialing, login, and fax parameters. All getty programs can read an initial message placed in the /etc/issue file, which can contain special codes to provide the system name and current date and time. Input Devices Input devices, such as mice and keyboards, are displayed on several levels. Initial detection is performed during installation when you select the mouse and keyboard types. Keyboards and mice will automatically be detected by HAL. You can perform detailed configuration 580 Part VII: System Administration with your desktop configuration tools, such as the GNOME or KDE mouse configuration tools. On GNOME, choose System | Preferences | Mouse to configure your mouse. A Keyboard entry on that same menu is used for keyboards. Installing Other Cards To install a new card, your kernel must first be configured to support it. Support for most cards is provided in the form of modules that can be dynamically loaded into the kernel. Installing support for a card is usually a simple matter of loading a module that includes the drivers. For example, drivers for the Sound Blaster sound card are in the module sb.o. Loading this module makes your sound card accessible to Linux. Ubuntu automatically detects the cards installed on your system and loads the needed modules. If you change sound cards, the new card is automatically detected. You can also load modules you need manually, removing an older conflicting one. The section “Modules” later in this chapter describes this process. Sound Devices Most sound cards are now detected and managed by udev and HAL. A list of various sound devices is provided in Table 25-7. Some sound cards may require more specialized support. You can determine your current sound configuration by listing the contents of the /proc/ asound/oss/sndstat file. You can test your card by simply redirecting a sound file to it, as shown here: cat sample.au > /dev/audio Older sound devices are supported as part of the Open Sound System (OSS) and are freely distributed as OSS/Free. These are installed as part of Linux distributions. The OSS device drivers are intended to provide a uniform API for all Unix platforms, including Linux. They support Sound Blaster– and Windows Sound System–compatible sound cards (ISA and PCI). Device Description /dev/sndstat Sound driver status /dev/audio Audio output device /dev/dsp Sound sampling device /dev/mixer Control mixer on sound card /dev/music High-level sequencer /dev/sequencer Low-level sequencer /dev/midi Direct MIDI port T ABLE 25-7 Sound Devices [...]... the incremental levels all the same Given an initial level of 0, and then two backups both with level 1, the last level 1 would include all the changes from the backup with level 0, since level 0 is the next lower level—not the previous level 1 backup Recording Backups Backups are recorded in the /etc/dumpdates file This file will list all the previous backups, specifying the file system on which they... to run the restore command First you should use mkfs to format the partition where you are restoring the file system, and then mount it onto your system Then you use restore with the -r option and the -f option to specify the device holding the file system’s backup In the next example, the user formats PART VII PART I PART I PART I PART I Should you need to back up to a device located on another system... that hostname for the system and the name of its device The hostname is entered before the device name and delimited with a colon In the following example, the user backs up file system /dev/hda5 to the SCSI tape device with the name /dev/st0 on the rabbit.mytrek.com system: 601 602 Part VII: System Administration and mounts the /dev/hda5 partition and then restores on that partition the file system... and is the default -0 through -9 Specifies the dump level A dump level 0 is a full backup, copying the entire file system (see also the -h option) Dump level numbers above 0 perform incremental backups, copying all new or modified files new in the file system since the last backup at a lower level The default level is 9 -B records Lets you specify the number of blocks in a volume, overriding the end-ofmedia... to the Server tab, but you can also access the Hosts tab to add new users, Xfer to specify the backup method, and the Backup Settings to set backup options The Server tab will control features such as the hostname of the server and the username to provide access On the Xfer tab you can configure different backup methods: archive (gzip), rsync, rsycnd, smb (Samba), and tar The Schedule tab sets the. .. command with the -w option uses /etc/fstab to report the file systems ready for backup Operations with dump The dump command takes as its arguments the dump level, the device on which it is storing the backup, and the device name of the file system that is being backed up If the storage medium (such as a tape) is too small to accommodate the backup, dump will pause and let you insert another dump supports... your tape drive type In the Holding Disk segment, you will need to specify the partition and the directory for the holding disk you want to use See the Amanda man page and documentation for detailed information on various options disklist The disklist file is where you specify the file systems and partitions to be backed up An entry lists the host, the partition, and the dump-type The possible dump-types... available files and select them to restore Within the amrecover shell, the ls command will list available backups, the add command will select one, and the extract operation will restore it The lcd command lets you change the client directory; amrecover will use DailySet1 as the default, but for other configurations you will need to specify their configuration directory with the -C option Should you... in the /dev/tape device: mkfs /dev/hda5 mount /dev/hda5 /mystuff cd /mystuff restore -rf /dev/tape To restore from a backup device located on another system on your network, you have to specify the hostname for the system and the name of its device The hostname is entered before the device name and delimited with a colon In the following example, the user restores a file system from the backup on the. .. drivers In the next example, the user lists all modules in the sound/alsadriver/pci/hda directory: # modprobe -l -t sound/pci/hda /lib/modules/2.6.24-17-generic /ubuntu/ sound/alsa-driver/sound/pci/hda/ snd-hda-intel.ko Options for the modprobe command are placed in the /etc/modprobe.d directory The insmod Command The insmod command performs the actual loading of modules Both modprobe and the Kernel . the left panel. The right panel displays information about the selected device. A Device tab lists the basic device information such as the vendor and the bus type. The Advanced tab lists the. and rmmod commands. The insmod command takes as its argument the name of the module, as does rmmod. The name can be the simple base name, such as snd-ac97-codec for the snd-ac97-codec.ko module load, you can use the -f option. In the next example, insmod loads the snd-ac97-codec.ko sound module: # insmod -v snd-ac97-codec The rmmod Command The rmmod command performs the actual unloading