CompTIA Linux+ / LPIC-1 Cert Guide (Exams LX0-103 & LX0-104/101-400 & 102-400) (2016)

In Example 1-1 you can see that the first device shown occupies two ranges of IO ports and has a numeric ID, which is a PCI address. The second command in the example searches for that address in the lspci command’s output, showing that it’s a bridge to the legacy ISA bus.

The next device is the advanced configuration and power interface (ACPI), which lets the hardware and software talk together for managing power usage. This communicates to the CPU with interrupt number 9.

Next is a DMA device called cascade, which is used by the hardware to let two DMA controllers talk to each other. It has DMA channel 4.

The last 3 entries are for the network peripherals. The first is the network driver, which has some IO ports reserved. The last two are for the cards, each has an IRQ.

Friends of procfs

procfs is the most popular way to expose kernel information to users, but there are more. The files under /proc are unstructured and contain both information about processes and devices. The goal of sysfs is to solve some of these shortcomings by migrating device data to /sys. Data still can exist on both, and the device tools such as lspci still use /proc.

udev is the Linux kernel’s device manager. It manages the device files under /dev using information about the device from sysfs. Every accessible device on the system will have a corresponding device file under /dev. If a device is plugged in to the computer while it is running, udev can configure it and make it available to the system. Devices that support being plugged in at runtime are also called hotplug devices, as opposed to coldplug devices that require the computer to be rebooted for them to be used.

Another loosely related service is called D-Bus. This is a distributed software bus that lets desktop applications send messages to each other and receive messages from the kernel. The D-Bus could be used for an email client to notify the window manager that an email has been received so that it can display an icon. It could also be used by udev to notify the window manager when a DVD has been inserted into the system.

Dealing with Integrated Peripherals

Motherboards, the component that houses the CPU and RAM, often comes with integrated peripherals, which are peripherals built into the motherboard. Video cards and network adapters are the most frequent integrated peripherals, but sound cards, RAID adapters, or special external peripheral ports could also be present.

Manufacturers include the hardware drivers with the motherboard, but these drivers may not support Linux. To make matters worse, integrated peripherals often require software support from the operating system to work properly. For example, some motherboards duplicate data across multiple disks for redundancy using a feature called a Redundant Array of Independent Disks (RAID) by supplying an integrated RAID adapter. This adapter may do some of the necessary parity calculations on the computer’s CPU instead of on the adapter to lower the price of the motherboard. This means that the Linux driver needs to support both the hardware and the software features.

If an integrated peripheral is not supported in Linux, your first step should be to see whether it works in a reduced capacity. A video card that shares memory with the system may not work in 3D accelerated mode but may work fine for regular use.

If the peripheral is not supported at all, your best course of action is to disable it entirely so that you can replace it with something that works. To do so

Step 1. Reboot your computer and enter BIOS setup mode. This involves pressing a special key while the computer boots. Your computer’s BIOS displays a message such as “PRESS F12 TO ENTER BIOS SETUP.”

Step 2. Navigate the setup menu to find the hardware section corresponding to the device you want to disable.

Step 3. Select the option to disable the peripheral.

Step 4. Exit the BIOS menu, making sure to select the option to save. This last part is important as the usual default is to discard all changes and reboot!

Laying Out the Hard Drive

Storage comes in many different flavors—hard drives, Universal Serial Bus (USB) flash drives, floppy and compact discs, DVDs, and network attached drives. Linux treats all these mass storage devices similarly and expects the administrator to fill in the details. This might mean entering a network or port address for a network file share, or identifying a particular hard drive. But to the user, these details are hidden from view.

Partitions and Devices

A single disk drive is divided up into one or more partitions that logically separate the disk. This logical separation allows you to assign space on the same drive for different uses. For example, a 3TB drive may be split up with the first 500GB for the operating system and applications, 1TB for database files, and 1.5TB for users’ home directories.

A partition is then formatted with a filesystem that allows it to store files. The operating system uses the filesystem to map files to the actual blocks on disk and manage directories and permissions.

Partitioning allows you to limit the scope of disk problems and to tune according to the intended use. For example, you may not want to track the last time a file was looked at on system binaries and database files but track the time on users’ files. Breaking out user files onto its own partition means you can use a different set of options for user files than you use for system binaries.

The problems encountered in an unexpected reboot are also reduced through partitioning. When a system is improperly shut down, files that were opened for writing may not have all their data persisted to disk. As the operating system files are rarely open for writing, that partition can usually survive an unclean shutdown. You can then get the computer up and running and tackle the problem of validating the consistency of user files in a separate action.

Linux uses device names to refer to the drives and partitions. The drives or devices are given a letter and a number is appended for the partition as follows:

/dev/sda is the first hard drive (a) in the system.

/dev/sda1 is the first partition (1) on the first hard drive (a) in the system.

/dev/sdb3 is the third partition (3) on the second drive (b) in the system.

Caution: The first partition is partition 1, but in most other situations 0 (zero) is the first device. /dev/md0 is the first RAID volume and /dev/scd0 is the first CD drive.

The Root Filesystem

Linux has many differences from Microsoft operating systems, but the one that seems to stand out the most is the single filesystem. In Windows, if you have three disk drives, they will probably be called C:, D:, and E:. Add a DVD drive and that is called F:. In Linux, just like other Unixes, there’s just one filesystem, and drives are grafted onto directories by mounting the filesystem at a particular point in the parent filesystem. The parent filesystem could be the root filesystem or it could be a descendant.

Figure 1-1 shows a typical configuration where directories are split among multiple drives and partitions.

Figure 1-1 A typical set of mounted directories showing two hard-drive mounts and one network mount

In Unix, the system starts off with a single root filesystem called /. In Figure 1-1 this is on device sda1. The /usr partition is mounted from sdb1, and on top of that, sda3 is mounted on /usr/local. Given this system, these statements are all true:

Directories with bolded names are mount points—their contents come from a different device than their parent.

Files in / go on sda1; it is the root partition.

Files in /sbin go on sda1; it is still part of the root filesystem.

Files in /usr go on sdb1; it is mounted off the root filesystem on /usr.

Files in /usr/bin go on sdb1; it is part of the same filesystem as /usr.

Files in /usr/local go on sda3; it is mounted on /usr/local/.

Files in /usr/local/bin go on sda3; the /usr/local/mount is more specific than the /usr mount.

Files in /home go over a network file system (NFS) share and are stored on a completely different computer.

Each partition has a filesystem on it, and the operating system stitches everything together to look like one big filesystem even though it may span multiple devices or even separate computers.

The user of a Linux system doesn’t have to worry about where one disk begins and another one ends—that’s the unfortunate job of the administrator. This layer of abstraction means that disks can be moved around, resized, put on the network, or cloned without any changes. Think of what would happen in Windows if your D: drive suddenly became E:! This just doesn’t happen in Linux.

The single filesystem also applies when accessing removable devices. When you plug in a USB flash drive you need to mount it somehow so that you can access the files stored on the drive. The software running your desktop environment may mount it for you or you may need to type commands, but in either case it’s treated as if it were a fixed hard drive.

When deciding how to lay out your disks, a useful acronym to remember for real-world needs is PIBS:

Performance—Performance increases if the system’s heavy usage directory trees are put on another disk. Good candidates for a move to another disk are the /home directory or the swap partition.

Integrity—Integrity improves by having critical files in their own partition. If disk resources become corrupted or damaged, such as from a sudden power outage, the computer can be down for hours to complete a filesystem check. Distancing risky partitions such as an FTP uploadfolder from the traditional root of the system is a good idea; otherwise, an FTP user that fills up the system partition would cause the system to crash.

Backup—Separate partitions give you more control over backups. For example, you may only want to back up files that change often in /home and conduct less frequent backups for files that do not change often within /usr. The tar command is used to back up sets of files and directory trees. It can be used to back up an entire file system, but there are more efficient tools for backup up partitions and complete disks like dump or dd.

Security—When placing partitions and directory trees on the system, be aware that it’s much easier to isolate or jail a risky portion of your server if it’s contained on a separate partition or disk. This is accomplished through options that are set at mount time, such as not allowing people to execute files with increased privilege or write to the filesystem. Mount options are discussed thoroughly in Chapter 9, “Partitions and Filesystems.”

Logical Volume Manager (LVM)

Over time the shuffling of physical disk partitions to keep up with demand gets tiring. What happens if you need a /home drive that’s bigger than a single disk? Do you just throw away your older disks when you add more space?

You could use the RAID system to create a virtual volume out of smaller disks, but that gets messy, especially if you want to use RAID’s fault tolerance.

Enterprise Unixes solve this problem with something called Logical Volume Management (LVM). Linux took ideas from enterprise Unixes and implemented the LVM feature. With LVM, system physical disks are combined into smaller sets of pools, and the partitions themselves are built from those pools.

Figure 1-2 shows the basic components of LVM and how they fit together.

Figure 1-2 Logical volume concepts

The base unit of storage in LVM is the physical volume (PV). A PV corresponds to a hard disk partition such as /dev/sda1 or some kind of block storage device coming from a dedicated storage system called a Storage Area Network (SAN). One or more physical volumes are combined to form a pool of storage called a volume group (VG). Under the hood the physical volume is chopped up into a series of physical extents (PE) to make allocations easier.

The administrator then carves up the volume group into a series of logical volumes (LV). Each logical volume holds a filesystem that is used by the operating system.

Many interesting things can happen now that the filesystem on the logical volume is thoroughly abstracted from the exact placement on disk. If you need more disk space on a logical volume you can take it from anywhere in the volume group. If the volume group is low on space simply add another physical volume to the volume group and the new physical extents are available to any logical volume.

Filesystems can be grown and shrunk by adjusting the size of their underlying logical volume as long as the filesystem supports it. The LVM system takes care of allocating the physical extents to the logical volume so you don’t have to worry about shuffling around partitions on disk anymore.

Snapshotting is now possible in an LVM enhanced system. A snapshot takes a point in time copy of a logical volume and makes it available as another disk while still allowing writes to happen to the original filesystem. This allows you to back up the snapshot image without needing to take the files or database offline; you can continue to work and change the files for later backup.

Commonly Used Mounts

A filesystem can be mounted on almost any directory as needed. You could mount a filesystem on top of /usr and then another one onto /usr/local if you wanted. Just because you can do it doesn’t mean you should, however. With experience, you’ll find a few common ways for administrators to lay out their filesystems.

The first option is to put everything on a single root partition. With LVM and large hard drives this isn’t a bad option.

The two most common places that a new partition is added is in /home and /var. Home is for the user’s home directories, which includes their work in progress and saved files. In a larger environment this may even be a network file share so that all computers share a common home directory system.

The other common mount point on which to split off another filesystem is /var, which is typically used for system log and data files. A database may store its files in /var/lib/mysql, system logs usually go under /var/log, and so forth.

When considering whether to split a directory off to another partition think about the activity on the disk: Do you expect the use of the partition to grow over time? What is the balance of reads and writes? Does the partition contain important system files, including the utilities to mount other partitions?

Both /home and /var are good candidates for separate filesystems because they grow the most and have the most write activity. The flexibility offered through separate partitions, even if they are backed by the same LVM volume group, is usually worth the added complexity.

Other lesser candidates for separate partitions are /tmp and /usr. The former is used for temporary file storage and can often grow, or need to be supported by a faster disk, and the latter can grow over time or may be shared across multiple systems.

A final partition you may run into is /boot. This is a small partition used to contain files necessary for loading the kernel.

Swap Files

Most partitions you encounter store files. There is another kind of partition, called a swap partition, that stores memory instead of files.

The operating system uses virtual memory, which means that the kernel presents a contiguous memory space to each application but can store the bytes wherever it needs to. If an application isn’t using all its memory, it doesn’t really matter whether the bytes are in RAM or stored on disk. Thus the kernel can swap memory pages to disk as needed, allowing the system to behave as if it has more memory than it actually does.

Access to disk data is much slower than access to RAM data, so it’s vital to avoid the need to constantly swap memory to and from disk or thrashing will happen. When your disks start to thrash, the system becomes painfully slow. Consider swap to be a safety net more than anything else.

Working with Boot Managers

The final piece of the installation puzzle is the boot manager. The boot manager’s job is to take the computer from power up to a functioning Linux kernel.

When a computer boots up, it doesn’t know how to talk to all its peripherals or load applications. But each computer has a Basic Input-Output System (BIOS) that gives it just enough intelligence to read and write to local disks and write some text to the screen.

Once the computer boots up it transfers control to the BIOS, which initializes the hardware and reads the first block—512 bytes—from the boot disk. This block contains the first part of the boot loader that loads the boot manager from disk and runs it. This special sector on the disk is called the master boot record (MBR).

The Linux boot block can be placed in the first block of the Linux partition itself in cases where an existing operating system already occupies the MBR. In this case the first boot manager needs to be told to pass control over to the Linux boot manager. It’s complicated, but this multi-bootingallows two different operating systems to coexist on the same computer.

The boot manager displays a menu offering different operating system choices. Usually a default is chosen if no input is received within a short period of time, which allows a computer to boot unattended. Boot managers can also pass parameters to the kernel such as to initialize hardware differently, disable problematic features, or alter the boot sequence.

Several boot managers are available though most distributions have standardized on the Grand Unified Boot Loader (GRUB).

GRUB Legacy

In the early days of Linux the boot manager was simple. You would either boot a kernel from an existing Microsoft DOS system through LOADLIN.EXE or directly with the Linux Loader (LILO). The latter was fairly inflexible. While you had a basic menu system, any changes needed to be made by rewriting the boot manager to disk. Even the location of the kernel blocks on disk needed to be known beforehand! LILO would have to generate a list of blocks containing a kernel and write them to a known place so that it could piece the kernel back together on boot.

Eventually the GNU Foundation started work on GRUB. This boot manager is more flexible than others because it offers an interactive menu that can be easily change and adapt to boot many operating systems. GRUB understands different filesystems, which allows it to read the kernel from disk as if it were a file instead of needing to know where the individual blocks are.

GRUB uses a temporary boot volume, /boot by default, on which to store kernels and the GRUB configuration. Some BIOSes can’t see the whole disk, so putting the boot manager in a safe area means that it can boot a kernel that has the functionality to read the entire disk.

GRUB2

GRUB2 is the version of GRUB currently in use. The software was rewritten to allow plugins and expand features available in the menu system. GRUB legacy and GRUB2 are otherwise fairly similar.

Installing GRUB2

The first step to getting GRUB2 installed is to have the tool write itself to the master boot record as follows:

[root@localhost ~]# grub2-install /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.

This copies the boot sector image to disk and the remaining files to /boot. If your bootable partition is not /boot you can override this default setting, such as /mnt/tmpboot in Example 1-2.

Example 1-2 Installing GRUB2 to an Alternate Location