About cookies on this site Our websites require some cookies to function properly (required). In addition, other cookies may be used with your consent to analyze site usage, improve the user experience and for advertising. For more information, please review your options. By visiting our website, you agree to our processing of information as described in IBM’sprivacy statement. To provide a smooth navigation, your cookie preferences will be shared across the IBM web domains listed here.
Tutorial
Prepare for LPIC-1 exam 1 - topic 101.1: Configure hardware settings
Prepare your system for Linux
On this page
Overview
In this tutorial, learn to configure and check the hardware for your Linux system. Learn to:
- Enable and disable integrated peripherals
- Distinguish different types of mass storage devices
- Know what hardware resources devices use
- Use tools to list and manipulate devices, including USB devices
- Understand sysfs, procfs, udev, and dbus
Computer hardware
Today's computers have come a long way from the IBM PCs introduced in 1981. Apart from massive increases in speed, memory, and storage capabilities, perhaps the most notable changes have been in configuration and setup. In this tutorial, I cover some common hardware settings that you might make on current computers, and I explore the commands that Linux has for listing and managing hardware.
This tutorial helps you prepare for Objective 101.1 in Topic 101 of the Linux Server Professional (LPIC-1) exam 101. The objective has a weight of 2.
Prerequisites
To get the most from the tutorials in this series, you need a basic knowledge of Linux and a working Linux system on which you can practice the commands that are covered in this tutorial. Sometimes different versions of a program format output differently, so your results might not always look exactly like the listings and figures that are shown here. The examples in this tutorial come from 64-bit systems with traditional Basic Input-Output Services (BIOS) or with the newer Universal Extensible Firmware Interface (UEFI).
Hardware settings
You usually configure settings by using either BIOS or UEFI firmware. Unless a setting is specific to UEFI, I use the term BIOS settings to cover both BIOS and UEFI settings.
You can access BIOS settings when you turn on your computer. Usually you do this by pressing a key such as Del, F1, or F8 after turning on the computer but before the operating system load starts. As machines have become faster and solid-state drives (SSDs) have reduced boot time to a few seconds, you might find that your system has a special button or key sequence to use. Check your system documentation to find out how to access the BIOS settings. The examples that are shown here illustrate the kinds of settings you might find, but the actual layout of your BIOS interface will probably be different from mine.
Figure 1 shows an example of a BIOS main screen for a system that I built. On this screen, you can change the system date and time. You can also change parameters for the legacy floppy drive if you have one. You also see the summary of installed drives. My system has only SATA drives, although IDE drives are also supported through the on-board controllers.
Figure 1. BIOS main screen with date and time settings
If your system supports legacy peripheral interfaces, you might have a place to configure them. In my case, I can use the Advanced menu to configure the serial and parallel port interrupt requests (IRQs) and I/O port starting addresses. Figure 2 shows the advanced settings for my system. In addition to configuring the legacy serial and parallel ports, note that I can enable or disable the on-board LAN and 1394 (FireWire) controllers. Note that the LAN controller also has a boot ROM that I have disabled. You enable the boot ROM if you want the system to load over a LAN from a remote server. You might want this for a kiosk machine or for reimaging a large number of systems.
Figure 2. Configuring serial, parallel, and on-board devices with BIOS
Your BIOS can also have settings that you can use to boot without a keyboard or mouse. When there is a boot error or maybe a change in configuration (such as the addition of memory), many systems — particularly older ones — require you to press a key to enter BIOS setup. What happens if the system has no keyboard? Today, you might plug in a Universal Serial Bus (USB) keyboard, but older systems with PS2 keyboard connectors could sometimes be damaged when a keyboard was plugged in. So, on many BIOS systems, you can disable either the keyboard itself or the warning that you might get if the keyboard is not present. I have a keyboard on my system, so my Wait for 'F1' If Error setting is enabled, as shown in Figure 3.
Figure 3. Disabling keyboard or keyboard boot error with BIOS
Another important setting that you might need to make is the order of boot devices. As shown in Figure 4, my system is set to check the first floppy drive, then the first SATA drive, and finally a CD or DVD. I haven't had a working floppy drive for several years, so I could probably safely drop it from the sequence. If my hard drive isn't working, I have the CD or DVD as a backup. See the tutorial "Learn Linux, 101: Boot the system" for information on how to choose the CD or DVD if you want to boot from it only once.
Figure 4. Configuring boot device order with BIOS
For UEFI systems, many settings are similar to those for traditional BIOS, including date, time, and whether on-board devices are enabled or not. Figure 5 shows an example from a Lenovo Yoga 2 Pro.
Figure 5. Configuring date, time, and on-board devices with UEFI
One major difference with UEFI systems is, of course, support for UEFI booting. Your system might support UEFI-only booting or it might also support legacy BIOS-like booting. My system has a Boot Mode parameter with two choices, as shown in Figure 6. When I choose Legacy Support, I can boot a legacy system or a UEFI system. My system will only boot UEFI systems if I choose UEFI.
Figure 6. Choosing UEFI boot mode
If you select UEFI-only booting, then you will probably not see some items that are related to legacy support, such as the legacy USB support option that you saw in Figure 5. You will also probably have options for support of secure boot, which allows only signed binaries to be booted. Figure 7 shows some of the security options that you might see if you select UEFI-only booting. On my system, there are both status values and options that you can change. For example, the Platform Mode setting of User confirms that security keys have been installed. If no keys are installed, the value is likely to be Setup instead. I can use the Reset to Setup Mode to install new keys, or I can use the Restore Factory Keys to restore the preinstalled factory keys.
Figure 7. Secure boot options with UEFI
Mass storage devices
Computers use several types of mass storage, and this storage can be attached in various ways. Today, most mass storage devices use standard interfaces, and either the device is detected when connected or the BIOS configuration is mostly automatic. Later in this tutorial, you'll see how to determine which resources a device needs. For now, let's look at the different types of common mass storage devices.
Hard drives
The hard drive has been the workhorse of data storage on PCs since the early 1980s. Hard drives come in a sealed unit and contain several recording surfaces or platters. The ST-506 introduced in 1980 had a 5MB capacity and used a controller card to translate requests from the computer to the internal commands needed to access the data on the disk platters. In 1984, IBM introduced the IBM PC/AT computer with a 16-bit AT bus, later known as an Industry Standard Architecture (ISA) bus. The AT attachment interface (ATA) standardized the interface between the controller card and the computer, preserving compatibility with the ST-506 command set. In the early 1980s, Western Digital moved the controller function inside the drive housing under the name Integrated Drive Electronics (IDE). You will find several later standards and terms, including ATA-1, ATA-2, ATA-4, and EIDE, among others. When Serial ATA (SATA) was introduced in 2003, the original ATA interface became known as Parallel ATA (PATA).
Another popular disk-attachment interface is the Small Computer System Interface (SCSI). SCSI was developed around 1978 for attaching various devices, including hard drives and printers. SCSI disks are still popular in larger servers.
The original ATA interface was designed for hard drives. The ATA interface was extended to the ATA Packet Interface (ATAPI) for use with other devices, such as floppy drives, Zip drives, or CD drives. ATAPI added capability to detect media presence, or eject media, among other features not needed for a normal hard drive. The ATAPI interface can carry SCSI commands in packets and thus support various device types.
Today, internal hard drives usually use either SCSI or SATA attachment. Drives can also be attached externally using USB, IEE-1394 (FireWire), External Serial Advanced Technology Attachment (eSATA), or Apple's Thunderbolt.
Hard drives can be partitioned to divide their space for different uses, and they can be combined into arrays for redundancy. Hard drives can also be grouped together using tools such as Logical Volume Manager to make several smaller disks appear as one or more larger ones.
CD and DVD drives
CD, DVD, and Blu-Ray drives use optical storage to hold much more data than a floppy drive. Early CD drives were often attached through a sound card, and the interfaces were many and varied. Later CD and then DVD drives standardized on the ATAPI interface. Today, you will find CD drives internally connected using SATA, or externally connected using the same kinds of interfaces used for hard drives. Software packages are often distributed on CD or DVD, which were initially read-only media. Now, using devices and media, users can create (burn) their own CDs and DVDs for backup or data storage.
Flash or thumb drives
Perhaps the most common means of exchanging data today is the flash or thumb drive. These drives use nonvolatile RAM to store data. They are much more reliable, faster, and higher-capacity than floppy disks and can be reused many times, unlike CD or DVD media. Most are about the size of a human thumb — hence the name — and usually attach to a USB port. Most support USB 2.0, which has a maximum speed of 480Mbps. Newer devices support USB 3.0 with a speed of up to 5Gbps. At the time of writing, typical sizes range from 1GB to 256GB, with a few larger 512GB and 1TB models available. You can partition thumb drives like hard drivesa. If you download a new Linux distribution, you might burn it to a USB thumb drive so you can install it from that device.
Solid-state drives
Solid-state drives (SSDs) are a newer form of drive that is being used in many notebook computers. Compared to the traditional hard drive, SSDs are lighter and faster, use less power, and do not suffer from mechanical failure. Initially, SSDs were often housed like 2.5-inch notebook drives and used the same SATA interfaces. To handle even thinner laptops, a variant called mini-SATA or mSATA was developed. The connector is smaller than a standard SATA connector and drives are approximately 1 inch by 2 inch and very thin.
Next Generation Form Factor (NGFF) SSDs were developed to replace mSATA. They are essentially similar to SATA drives but use a new connector known as M.2. The M.2 connector supports USB and PCI Express (PCIe) devices if the motherboard supports these. Earlier motherboards may only support NGFF M.2 devices.
SATA interfaces can limit the theoretical capabilities of an SSD. A newer attachment called NVM Express (NVMe) has been developed for PCIe-based SSDs. The specification is designed to better use SSDs over PCIe. These also use the M.2 connector and may operate at SATA speeds or even faster PCIe speeds.
Virtual files for hardware and system information
Several virtual filesystems provide an in-memory look at your system as the kernel sees it. These filesystems are virtual in the sense that no real files exist on storage devices. Rather, the virtual filesystems provide insight into kernel data structures and into your system hardware.
Sysfs and /sys
Sysfs is a virtual filesystem that the Linux kernel uses to export information about kernel objects to processes running in user space. It was introduced in the 2.6 kernel and was originally derived from ramfs, which dated from the 2.4 kernel. As a virtual filesystem, sysfs is an in-memory filesystem that is mounted at /sys. If it is not mounted during initialization by an entry in /etc/fstab, you can always mount it using the command:
Sysfs is a simple filesystem with files that represent object attributes. The objects themselves are represented by directories. Symbolic links represent relationships between objects. The top-level directories in sysfs represent major subsystems. Listing 1 shows examples of the top-level /sys directory and the /sys/bus and /sys/devices directories.
Listing 1. Some entries from the sysfs filesystem
If you look at /sys/block, you find your block devices. In my case, I have three hard drives — sda, sdb, and sdc — and one CD/DVD drive: sr0. These are actually links to directories under the /sys/devices directory. If you follow these links, you find the partitions of sda. Looking at the size file, you see that the disk has 2,040,192 sectors, a value confirmed by fdisk -lfdisk-l, as illustrated in Listing 2.
Listing 2. Block devices in /sys
The tree command is a useful tool for exploring /sys. Note also that you have to escape special characters such as the colon (:) by enclosing them in quotation marks or using the backslash (\) character.
procfs and /proc
The procfs filesystem provides insight into many of the kernel data structures and even allows a few to be changed on the fly. procfs is usually mounted at /proc. Listing 3 shows a listing of /proc on my system.
Listing 3. Listing of /proc
You see a large number of numbered directories — one for each running process on your system. The number is the process ID (PID). Listing 4 shows the first few entries for a running bash command prompt (PID=$$ — the current PID). Note that almost all entries in the procfs filesystem have a length of 0, even though they might not be empty and you can see data if you use the cat command. Most entries are not terminated with a newline character, so I use the echo command in Listing 4 for clarity.
Listing 4. Showing /proc entries for the current process
The parameters that you can control by setting values in the procfs filesystem can also be controlled via the sysctl command. Refer to the sysctl and procfs man pages for more information.
The procfs filesystem also provides information about interrupt, Direct Memory Access (DMA), and I/O port resources used by your system.
Listing 5 shows the contents of /proc/interrupts on my system. Older single-processor computers using the ISA bus use certain well-known interrupts (or IRQs), I/O ports, and DMA resources. These were in limited supply, so adding a sound card that needed IRQ 5 might prevent use of a second parallel port that also needed IRQ 5. The PCI bus includes a capability for Message Signalling Interrupts (MSI), which has significantly eased the resource limitations found in older systems. ISA bus device interrupts are numbered from 0 through 15. This system does have a parallel printer port using IRQ7 but does not have serial ports, which normally use IRQ3 or IRQ 4. If you have error messages or a device that does not work and you suspect interrupt conflicts, looking at /proc/interrupts is a good place to start.
Listing 5. Listing of /proc/interrupts
DMA was a technique used in ISA bus systems whereby fast devices such as hard drives could transfer data to computer memory without involving the processor. DMA frees up the processor to do other work while the data is being read from or written to the device. The PCI bus architecture uses bus mastering to achieve a similar goal. Listing 6 shows the contents of /proc/dma on my system. If you have ISA bus resources, you usually see more than this, and you might need this information to help diagnose conflicts.
Listing 6. Listing of /proc/interrupts
Another resource list you can use to help resolve problems is the listing of I/O ports in /proc/ioports. Several I/O ports used in ISA bus systems are well known, such as the range 0378 to 037a usually used for the first parallel port. Note that the ports are specified in hexadecimal.
Listing 7. Listing of /proc/ioports
The lsdev command
The procinfo package contains the lsdev command, which simplifies the presentation of the information from /proc by gathering the DMA, IRQ, and I/O port information for each device into a simple tabular format. Listing 8 shows the lsdev output for my system.
Listing 8. Output from lsdev
The procinfo package also contains the procinfo command, which summarizes other information from /proc. Try it or see the man page for details.
udev and /dev
udev is responsible for the dynamic device management needed for hot plugging devices. Information about configured and active devices is contained in the /dev virtual filesystem. When a device is added to or removed from the system, or it changes state, the kernel sends an event to the systemd-udevd.service daemon, which manages udev events. The daemon searches configured rules to match the event with a rule to identify the device. The kernel usually assigns a name that is neither meaningful nor repeatable, so udev usually assigns a more meaningful and consistent name.
The udev rules are in /usr/lib/udev/rules.d, with additional local rules in /etc/udev/rules.d. You can create additional rules in the volatile /run/udev/rules.d directory. You can configure udev using the /etc/udev/udev.conf file. NOTE: Some systems place rules in /lib/udev/rules.d rather than /usr/lib/udev/rules.d. Check the udev man page on your system.
The /dev filesystem describes the devices on your system. In a long listing, you find one of four values in the first column:
b
Represents a block device such as a disk drive
c
Represents a character device such as a terminal or printer, or a special device such as null
d
Represents a directory
l
Represents a symbolic link to another directory of file, either in /dev, /proc, or /run
Listing 9 shows a partial listing of /dev on my system where you see examples of each type of entry.
Listing 9. Partial listing of /dev
Listing 10 shows the linkage between some kernel-assigned names and some more-familiar names for hard-drive partitions.
Listing 10. Symbolic links to familiar hard drive names
If you want to manage or monitor udev events, you can use the udevadm command. See the man pages for more information.
Tools and utilities
Some useful tools are available for determining information about your PCI and USB devices. Let's look at lspci and lsusb.
PCI and lspci
Use lspci without options to see a basic listing of your PCI devices. What you see depends on your own system hardware. Listing 11 shows the Fedora 22 desktop system that I have been using for most of this tutorial.
Listing 11. Using lspci to display desktop PCI devices
Listing 12 shows a Ubuntu 15.04 system running on a Lenovo Yoga 2 Pro notebook.
Listing 12. Using lspci to display notebook PCI devices
The lspci command looks up much of its data in the /usr/share/hwdata/pci.ids file, which contains a list of all known IDs (vendors, devices, classes, and subclasses). Vendor and device codes are assigned numbers. Use the -n option if you want to see numbers instead of names. If you have a new device that is not yet in your local database, use the -q option to query the central PCI ID server database using a DNS lookup. If a device is found there, the information is saved in ~/.pciids-cache, and the device is recognized on later runs even if you do not specify -q.
PCI topology is described by four levels: domain, bus, slot, and function. You can restrict output by using any of these components along with the -s option. The -t option shows the output in a tree view. Other options of lspci control the verbosity and format of the output. You can have more or less verbose output, and the output can be suitable for machine or human reading.
Listing 13 shows the topology tree for devices in slot 00 on my system, using the -t and -v options.
Listing 13. Output of lspci -tv
You can also restrict output by vendor ID, device, or class by using the -d option. And the -k option tells you which kernel driver is handling the device and which kernel modules are capable of handling it. Listing 14 shows this output for the NVIDIA graphics and sound devices on my system. The vendor ID for NVIDIA is 10de, which you can find out by using the -nn option of lspci.
Listing 14. Output of lspci with -d and -k options
See the man pages for the many other options for lspci. Some of them give you access to detailed information on PCI devices. There is also a setpci command, which enables a root user to query and configure PCI devices. Again, see the man pages for details.
USB and lsusb
Use the lsusb command to display information about your USB devices. As with lspci, the -t option displays information in a tree layout, as shown in Listing 15.
Listing 15. Tree output of lsusb
USB devices connect to a hub. The root hubs are at the top level and can support USB 1, 2, or 3. The OHCI (or UHCI) driver supports USB 1.1 (12Mbps), the EHCI driver supports USB 2.0 (480Mbps), and the XHCI driver supports USB 3.0 (5Gbps). USB Attached SCSI (UAS) is a faster protocol developed for USB 3.0 that also supports USB 2.0 speeds. UAS was introduced into Linux at kernel 3.15.
Attached devices fall into several classes:
- Human-interface devices include keyboards, mice, and other such devices.
- Communications devices include modems and serial, Ethernet, or WiFi interfaces.
- Mass storage devices include hard drives, CD and DVD drives, flash drives, memory card readers, and cameras.
- Audio devices include sound cards, MIDI devices, speakers, and microphones.
- IrDA devices use infrared communication and include medical devices and test equipment.
- Printer devices include printers and other devices such as numerically controlled machines.
- Video devices include webcams.
Many attached devices use a class driver, such as usb-storage for a storage device, usbhid for a human-interface device such as mouse or keyboard, or hub for a cascaded hub. The list in Listing 15 includes two human-interface devices (my mouse and keyboard) and a USB 2.0 hub with an attached storage device (a thumb drive). Some specialized devices might require a unique driver for the device.
As with PCI devices, you can limit the output by USB topology or by vendor or device ID. Listing 16 shows an example of each.
Listing 16. Limiting the output of lsusb
There is also a usbview command that you can use to view USB information graphically. The data is presented in tree view in the left pane. Selecting an entry shows the details in the right pane. The example in Usbfig 1 shows details for a USB drive.
Figure 8. Using usbview
Message passing and D-Bus
When new hardware is plugged in, or a printer runs out of paper, a user often needs to be notified. D-Bus (also known as dbus) is a message-passing bus developed under the auspices of freedesktop.org. A single system daemon allows communication between the kernel and user space for events such as new hardware found. D-Bus messages can drive notifications to a user, and the receiving application can then suggest actions such as opening a file browser when a CD or DVD is inserted in a drive or when a USB thumb drive is plugged in.
There is also a per-user-session daemon that is launched at login time. The user daemon provides interprocess communication between the user applications. The D-Bus protocol is a general one-to-one message-passing framework. Two applications could even communicate using the framework without messages passing through the dbus daemon.
See resources on the right side of the article for additional information on D-Bus.
Kernel modules
A long time ago, computer operating systems were configured and built to handle a specific set of attached hardware. If a device was not built into the operating system kernel, it could not be added or used. As the variety of devices increased and as the need grew to dynamically add devices by hot plugging, this model no longer worked. Today the kernel is minimal, and device support is configured by loadable kernel modules (LKMs). A basic set of device-support modules is usually included in an initial RAM disk that is loaded as part of the boot process. Once the system is up, the kernel probes the system further and loads needed device modules as new devices are discovered.
Several commands are used for interrogating and manipulating kernel modules. I'll cover lsmod, modinfo, and modprobe here. The modprobe command has now replaced the function of the earlier insmod and rmmod commands because it is more powerful.
Using lsmod
The lsmod command formats the information from /proc/modules to give you a current status of the modules in your Linux system. The lsmod command has no options. Listing 17 shows a partial listing of the module status on my system.
Listing 17. Partial listing of module status with lsmod
Using modinfo
Use the modinfo command to get information about a module. You can give a full filename or just the module name.Listing 18 shows information for the vfat module, which handles the various forms of FAT-formatted drives.
Listing 18. Information about the vfat module
The module information includes the full path to the file and information about any other names (aliases) the module might be known by. Dependencies, if any, are also listed. So, from Mod 2, you can see that the vfat module is also known as fs-vfat and depends on another module called fat. Try running modinfo with these module names.
You can use the -F or --field option to limit the output to a specific field. This option is useful for scripts.
If you don't specify a full filename, modinfo searches for a module in /lib/modules/version/kernel, where version is your kernel release as given by uname -runame-r. In the example in Listing 18, the file vfat.ko.xz (the vfat kernel module) is found in /lib/modules/4.1.6-200.fc22.x86_64/kernel/fs/fat. Listing 19 illustrates how you might start looking for module files on your system.
Listing 19. Locating module files on your system
You can also find several plain-text files in your /lib/modules/$(uname -r) directory — including modules.dep, which lists dependencies, and modules.alias, which lists aliases. The modules.builtin file lists modules that are built in to the kernel. These include drivers needed for core functionality on most systems. If you try to use modinfo to find out about the ehci-pci driver that you might have noticed in the lsusb output, you probably won't find it because it is a built-in driver. Listing 20 illustrates this scenario.
Listing 20. Finding built-in drivers
Using modprobe
As you've seen from the output of lspci, lsusb, lsmod, and modinfo, your system uses several kernel modules to drive devices. You have also seen that some of these modules have dependencies. So, loading the right modules in the right order is important. Fortunately, the modprobe command has taken over the earlier manual work of insmod and rmmod, which can each insert or remove one module from the system.
I'll use the irnet module for this example on my Ubuntu 16.04.1 LTS system. Use modinfo to see more about this module, as shown in Listing 21.
Listing 21. Module information for irrnet
As you see, this module has a dependency on irda, which has a further dependency on crc-ccitt. By using grep to search for irda or crc-ccitt in your modules.dep file, you can see the value of modularizing driver support. Each of these drivers is used by many other drivers.
If you want to manually load or unload a driver, use modprobe with the -a (or --all) option to load or insert the module and the -r option to remove or unload the module. The -n, --dry-run, or --show option shows you what will be done, without doing it. You usually use the -v option with these to see more information. Listing 22 shows what will happen if I try to load the irda module.
Listing 22. Dry run loading the irnet module
The output shows the insmod commands needed to load each required module with dependencies resolved.
The modprobe command takes into account modules that are already loaded. In Listing 22, I first load the crc-ccitt module, then do another dry run, and finally load the irnet module. Note that the actual loading or unloading requires root authority.
Listing 22. Loading the irnet module
You remove modules by using the -r option of modprobe. You cannot remove a module if it is being used. Listing 23 shows you some examples.
Listing 23. Unloading the irnet module
Module parameters
Some modules have parameters. For example, a device driver might need to know which IRQ or I/O port to use. Listing 24 shows module information for the nsc-ircc module, which has several such parameters.
Listing 24. Modules with parameters
You specify module parameters on the modprobe command line when loading the module. See the man page for more details and for details on the other available modprobe options.
This concludes your introduction to hardware settings on Linux.
