Chapter 7 Booting and Shutting Down – Linux Administration: A Beginner's Guide, Eighth Edition, 8th Edition

CHAPTER

7

Booting and Shutting Down

As the complexity in modern-day operating systems has grown, so has the complexity in starting up and shutting down processes. Not only does the hardware need to be initialized and the core operating system need to be brought up and shut down, but an impressive list of services and processes must also be started and stopped at the right moment.

In this chapter, we discuss the bootstrapping of the Linux operating system with GRUB. We then step through the processes of starting up and shutting down the Linux environment. We discuss the scripts that automate parts of these processes, as well as modifications that may sometimes be desirable in the scripts. We finish up with coverage of a few odds and ends that pertain to booting up and shutting down.

CAUTION  Apply a liberal dose of common sense in following the practical exercises in this chapter on a real/production system. As you experiment with modifying startup and shutdown scripts, bear in mind that it is possible to bring your system to a nonfunctional state that cannot be recovered by mere rebooting. Don’t mess with a production system; if you must, make sure you back up all the files you want to change—and most importantly, have your bootable rescue media handy.

Boot Loaders

For any operating system to boot on standard PC hardware, you need what is called a boot loader. The boot loader is the first software program that runs when a computer starts. It is responsible for handing over control of the system to the operating system.

Typically, the boot loader will reside in the Master Boot Record (MBR) of the disk, and it knows how to get the operating system up and running. The de facto boot loader on Linux distros is called GRUB, and it can be configured to also recognize and boot other operating systems. GRUB currently comes in two versions—the older GRUB Legacy and the newer and more common GRUB version 2 (GRUB 2).

GRUB Legacy

Most modern Linux distributions use GRUB as the default boot loader during installation, including Fedora, Red Hat Enterprise Linux (RHEL), openSUSE, Debian, CentOS, Ubuntu, and a host of others. GRUB aims to be compliant with the Multiboot Specification and offers many features.

The GRUB Legacy boot process happens in stages. Each stage is taken care of by special GRUB image files, with each preceding stage helping the next stage along. Two of the stages (stage 1 and 2) are essential, and the other stages (for example, stage 1.5) are optional and dependent on the particular system setup.

On RPM-based distros, you can check your GRUB version by running the following:

On Debian-based systems, you can check your version of GRUB by running this:

If the output shows GRUB version 1.9*, 2.*, or higher, then you are running GRUB 2 or newer. If the output shows version 0.99 or earlier, you are running a legacy version of GRUB.

Conventions Used in GRUB

GRUB has its own special way of referring to devices (optical disc drives, floppy drives, hard disk drives, and so on). The device name has to be enclosed in parentheses: ( ). GRUB starts numbering its devices and partitions from 0, not from 1. Therefore, GRUB would refer to the first enumerated hard drive on the controller as (hd0), where “hd” means “hard disk” drive and the number 0 means it is the first enumerated hard disk.

NOTE  A simple-to-use script that can help complete various GRUB-related tasks or repairs is the grub-install script (see man grub-install).

Keep in mind that, typically, GRUB needs to be installed only once. Any further modifications are stored in a text configuration file, and such changes don’t need to be rewritten to the MBR or partition boot sector every time.

CAUTION  Back up the MBR! Before you proceed with the exercises that follow, it is a good idea to make a backup of your current “known good” MBR. It is easy to do this using the dd command. Since the MBR of a PC’s hard disk (sda, vda, sdb ...) resides in the first 512 bytes of the disk, you can easily copy the first 512 bytes to a file by typing the following:

GRUB 2

GRUB 2 is the successor to the GRUB Legacy boot loader. Some widely used and deployed older versions of popular Linux distros still use and standardize on GRUB Legacy, but many mainstream distros have adopted GRUB 2. It is reasonable to assume that at some point in the near future GRUB Legacy will no longer be supported and everybody will have to move to GRUB 2 or to something else, if something better comes along.

The main features of GRUB 2, as well as some differences when compared with GRUB Legacy, are listed in Table 7-1.

Table 7-1   GRUB 2 Features

Configuring GRUB 2

The primary configuration file in GRUB 2 is grub.cfg. On most modern EFI-based systems, grub.cfg is stored on the special EFI boot partition (/boot/efi). On our sample EFI-based Fedora server, the exact location of the file is /boot/efi/EFI/fedora/grub.cfg. On other distros such as Ubuntu, the file might be located at /boot/efi/EFI/ubuntu/grub.cfg, for example. On traditional BIOS-based systems, the file is usually located at /boot/grub/grub.cfg (Ubuntu) or /boot/grub2/grub.cfg (Fedora).

Regardless of its location, this file is automagically generated and updated by invoking the grub2-mkconfig command. The grub2-mkconfig command parses the various scripts (see Table 7-1) under the /etc/grub.d/ directory to create grub.cfg. Entries in grub.cfg are a good indication for what will end up being displayed in the operating system boot menu.

The following shows an excerpt from a sample grub.cfg file on a Fedora-based system (note that line numbers 1–16 have been added to the output to aid readability):

The entries in the preceding sample configuration file for GRUB are discussed here:

•   Line 1   All lines that begin with a pound sign (#) are comments and are ignored.

•   Line 2: menuentry This directive defines the beginning stanza for a GRUB menu entry/title. In this example, the specific title looks like 'Fedora...'. This title is what will be displayed in the GRUB menu at system boot. The directive accepts different options, such as class, users, unrestricted, hotkey, and so on. The --class options can be used to group menu entries into classes.

The menuentry line ends with an opening brace ({), which signifies the start of all the directives that pertain to this particular GRUB 2 menuentry.

•   Line 3: load_video This refers to a function defined earlier in the configuration file that is not shown in our excerpt. This particular function loads several dynamic GRUB video-related modules such as vga, efi_uga, ieee1275_fb, and so on.

•   Line 4: set   Sets the environment variable gfxpayload value to keep.

•   Lines 5–7: insmod   These lines insert the dynamic GRUB modules gzio, part_gpt, and xfs, respectively.

•   Line 8: set root='hd0,gpt2'   Sets the GRUB root device name (usually /boot). In this example, the root device is defined as the second partition (gpt2) on the first hard disk (hd0).

•   Lines 9–13: if, then, else, fi This block makes use of the built-in scripting capabilities of GRUB 2 using conditionals. The block essentially tests the return value of the statements or conditions specified between the starting if reserved command and the ending fi command. Here, the GRUB 2 search command is being executed based on the return value of the tests.

•   Line 14: linux   This command loads the specified Linux kernel image file (/vmlinuz-5.*.x86_64) in 32-bit mode. Other variations of this are linux16, linuxefi, and so on. Specific directives may also be specified in the BootLoaderSpec files stored under /boot/loader/entries/. The other arguments after the kernel filename are passed verbatim to the kernel as boot parameters/arguments. One example of a boot parameter is rd.lvm.lv, which activates the specified logical volumes (LVs). Another example is the quiet parameter, which disables most of the verbose log messages as the system boots.

•   Line 15: initrd   Loads the specified initial ramdisk file for the Linux kernel image to be booted in 32-bit mode. Other variations of this are initrd16, initrdefi, and so on. Specific directives may also be specified in the BootLoaderSpec files stored under /boot/loader/entries/. The initial ramdisk image provides a way to preload certain basic modules that may be necessary for accessing and mounting the root file system.

•   Line 16: }   This closing brace signifies the end of this particular GRUB 2 menu entry.

NOTE  The path names are relative to the /boot directory, so, for example, instead of specifying the path to the kernel to be /boot/vmlinuz-5.*.x86_64, GRUB’s configuration file references this path as /vmlinuz-5.*.x86_64.

Adding a New GRUB 2 Menu Entry

In this section, you learn how to manually add a new entry to the GRUB 2 boot menu. We will be adding a semi-useless entry just for testing purposes. In other words, the new entry will not do anything useful—we’re adding it for illustration purposes only. In Chapter 9, we will use the same concepts to add a more useful GRUB 2 menu entry that will boot the Linux kernel we build from scratch.

In the following steps, you will create a new entry that does nothing more than change the foreground and background colors of GRUB’s boot menu:

1.   While logged in as the root user, change your current working directory to the /etc/grub/d/ directory:

2.   Create a new GRUB 2–formatted script named 99_custom.sh that will be used to add your new entry to the GRUB menu. Using any text editor you are comfortable with (the vim editor is used in this example), type the following text in the file:

3.   Once the script has been successfully created, make the script executable:

4.   Run grub2-mkconfig, which will parse the commands in the new script you just created and create an appropriate updated /boot/efi/EFI/fedora/grub.cfg configuration:

On a BIOS based or non-EFI system, you would instead need to send the output grub2-mkconfig to the /boot/grub2/grub.cfg (Fedora) or /boot/grub/grub.cfg (Ubuntu) file.

5.   Use the grep command to verify that the new menuentry was added to grub.cfg:

6.   Once you’ve confirmed the entry is in the grub.cfg file, reboot the system.

When the system reboots, you can test your changes by following the next steps while at the initial GRUB screen:

1.   After the GRUB menu appears, select the Change Background Color option and press ENTER.

2.   The color of the menu should change to the color you specified in the 99_custom.sh file using the color_normal directive. Note that your selection will not actually boot the system. You will have to select a valid menuentry to boot the OS into Linux.

TIP  If you don’t want a specific menu entry to be automatically created in a system using GRUB 2 as the boot loader, you have to delete or disable the corresponding script in the /etc/grub.d/ directory that creates the entry. For example, if you don’t want to see entries for other, non-native operating systems such as Microsoft Windows in your boot menu, you need to delete /etc/grub.d/30_os-prober or alternatively make it non-executable and then run the grub2-mkconfig command to regenerate grub.cfg, like so:

USB GRUB 2 Boot Disk

Let’s create a bootable external USB GRUB 2 disk. This will allow you to boot the system using the external USB device in the off chance that you can’t boot the system normally. Here are some sample situations where a bootable GRUB 2 USB disk can come in handy:

•   Your system does not currently have a boot loader installed.

•   The boot loader for the system is damaged or corrupted, possibly by another operating system.

•   You want to create a multiboot USB medium for storing and booting different operating systems that come in ISO (CD/DVD-ROM) image format.

The general idea behind using a USB GRUB boot disk is that it is assumed that you currently have a system with an unbootable, corrupt, or unwanted boot loader—and since the system cannot be booted by itself from the hard disk, you need another medium with which to bootstrap the system. For this, you can use a GRUB 2 USB disk, a GRUB CD, or even a GRUB floppy disk (good luck with finding a system with a floppy disk drive!).

Assuming we are ready to lose the entire contents of the target USB device and that the current block device for the USB drive is /dev/sdb, we can carry out the following procedures:

1.   Plug in a reasonably sized USB drive into the appropriate port on the system and then use either the fdisk, lsusb, dmesg, or blkid command to verify the block device file that Linux has associated with your USB drive. We use the blkid command here:

2.   Format the drive with the ext4 file system (this will wipe the drive clean):

3.   Mount the USB device to an existing and available mount point (for example, /media/sda1):

4.   Use the grub2-install utility to install the boot loader on the USB device:

5.   If you don’t want to use GRUB 2 interactively from the GRUB 2 prompt during system boot, you will have to store a suitable GRUB 2 configuration file on the USB device.

You can alternatively duplicate the exact boot configuration on the current system by copying over the current grub.cfg file to the USB device or creating a custom configuration file from scratch.

Here we will duplicate the GRUB 2 boot configuration on the current system and write the grub.cfg file to the USB device mount point:

6.   View the files and directories created on the USB device by the previous steps and then umount the USB device when done:

That’s it! You can reboot the system at your leisure and try selecting the USB device as the boot medium (adjust your UEFI or BIOS settings if necessary) to make sure that you have indeed created a bootable external USB device.

Bootstrapping

This section assumes you are already familiar with the boot processes of other operating systems and thus already know the boot cycle of your hardware. We cover the process of bootstrapping the operating system. We’ll begin with the Linux boot loader (usually GRUB for PCs).

Kernel Loading

Once GRUB has started and you have selected Linux as the operating system to boot, the first thing to get loaded is the kernel. Keep in mind that no operating system exists in memory at this point, and PCs have no easy way to access all of their memory. Thus, the kernel must load completely into the first megabyte of available RAM. To accomplish this, the kernel is compressed. The head of the file contains the code necessary to bring the CPU into protected mode (thereby removing the memory restriction) and decompress the remainder of the kernel.

Kernel Execution

With the kernel in memory, it can begin executing. Something to remember is that the kernel is nothing but a program (albeit a very sophisticated and smart one) that needs to be executed. The kernel knows only whatever functionality is built into it, which means any parts of the kernel compiled as modules are useless at this point. At the very minimum, the kernel must have enough code to set up its virtual memory subsystem and access the root file system (usually the ext3, ext4, Btrfs, or XFS file system). Once the kernel has started, a hardware probe determines what device drivers should be initialized. From here, the kernel can mount the root file system. This is akin to what a Microsoft Windows system will do to recognize and access its C drive. The kernel mounts the root file system and starts a program called init, which is discussed in the next section.

The init Process

On the traditional System V (SysV) style of Linux distros, the init process is the first non-kernel process that is started; therefore, it always gets the process ID number of 1. init reads its configuration file, /etc/inittab, and determines the runlevel where it should start. Essentially, a runlevel dictates the system’s behavior. Each level (designated by an integer between 0 and 6) serves a specific purpose. A runlevel of initdefault is selected if it exists; otherwise, you are prompted to supply a runlevel value.

Most modern Linux distros have substituted the functionality previously provided by SysV init with a new startup manager called systemd. The notion of runlevels is different in systemd, and instead are referred to as targets. Chapter 9 discusses systemd in greater detail. Table 7-2 shows the different runlevels in the traditional SysV world as well as their equivalent in the systemd world.

Table 7-2   SysV init Runlevels and systemd Targets

Systemd Scripts

On systemd-based distros, the configuration files that control what is started, how it is started, and when it is started are referred to as unit files. These files are stored in certain locations on the file system. For example, /usr/lib/systemd/system/ holds any relevant unit files that come with installed packages, and /etc/systemd/system/ often holds unit files installed (implicitly or explicitly) by the system administrator.

These unit files are collectively responsible for starting, managing, or stopping various services and processes at a fixed point during or after the boot process. In many cases, the order in which these units are executed makes a difference. For example, you can’t start services that rely on a configured network interface without first enabling and configuring the network interface!

Let’s peer into the /usr/lib/systemd/system directory of our sample Fedora server:

As you can see from the preceding output, there are lots of unit files! The files are named tmp.mount, basic.target, network.target, crond.server, blah.socket, and so on. You will learn more about the relevance of the filename extensions (*.target, *.service, *.mount, and so on) in Chapter 9. Thankfully, not all of the unit files are active all of the time, and they also all don’t need to be manually managed by the system administrator. The only unit files that are active are the ones that have been explicitly enabled by the system administrator or that have been implicitly enabled by the system via a software package or system configuration utility.

For any given enabled (active) unit file, a corresponding symbolic link for the unit is created under the unit configuration directory.

Okay, we are beginning to talk in circles, so let’s break off into a real example that will hopefully make things clearer. We’ll create our very own service (aka systemd service unit) in the next section.

Writing Your Own rc Script

In the course of administering a Linux system and keeping it running, at some point you will need to modify the behavior of a process or service as it pertains to the system bootup or shutdown. systemd makes this easy to do on modern Linux distros.

Let’s step through the process using an example to see how to create a simple service and integrate it with the automatic system bootup process. You can use this example as a skeleton script, by the way, changing it to add anything you need. Let’s assume you are running a systemd-enabled Linux server and you want to start a special program that pops up a message every hour and reminds you that you need to take a break from the keyboard—a good idea if you don’t want to get carpal tunnel syndrome!

The script to start this program will include the following: a description of the script’s purpose (so that you don’t forget it a year later) and a simple loop to send an e-mail every hour.

NOTE  Lines starting with a pound sign (#) are comments and are not part of the script’s actions, except for the first line.

Given these parameters, let’s begin creating the script.

Creating the carpald.sh Script

First, we’ll create the script that will perform the actual function we want. The script is unsophisticated, but it will serve our purpose here. A description of what the script does is embedded in its comment fields.

1.   Launch any text editor of your choice and type the following text:

2.   Save the text of the script into a file called carpald.sh.

3.   You next need to make the script executable. Type the following:

4.   Copy or move the script over to a common and central directory location; we’ll use the /usr/local/bin/ directory:

5.   Notice that the carpald.sh script references a mailx command (second-to-last line). Therefore, you need to have the mailx utility available or installed on the system so it can be used within the script.

On our sample Fedora/CentOS/RHEL system, you can use dnf to install mailx—if you don’t already have it installed. Type the following:

If you don’t have mailx on a Debian-based system like Ubuntu, you can use the apt program to install it by running this:

NOTE  Our demo carpald.sh script will need a mechanism to actually deliver e-mails to the recipient e-mail address (root@localhost). This involves either setting up a local mail server or configuring the system to use an external mail server or some other mechanism to send e-mails. Because this is just a proof of concept, we are not ready to go whole hog just yet. So, for now, kindly ignore any “message not sent” errors that you might see in the system logs! Chapter 20 covers installing and setting up a fully functioning mail server. If you don’t trust us or simply can’t wait to test the script, you can quickly install the postfix package using dnf, yum, or apt.

Creating the carpald Service Unit

Here you will create the actual startup script that’s executed during system startup and shutdown. The file you create here is called carpald. The file is systemd-enabled, which means that it will make use of systemd domain-specific language/syntax. This is a useful and time-saving functionality.

1.   Launch any text editor of your choice and type the following text:

A few comments about the preceding sample carpald.service unit file. The fields in square brackets, like [Unit], [Service], and [Install], mark the start of a new section within the file:

•   The [Unit] section contains generic parameters affect various systemd objects, such as Description, After, and so on. Here, we specify a simple string that describes our custom carpald service, and we also specify that this unit can be started after the syslog.target.

•   The [Service] section contains parameters that are more specific to the particular unit. For one thing, it specifies that this is a service type of unit. The ExecStart parameter is set to the path of the carpald.sh shell script that we created earlier.

The Type parameter specifies how the service should notify the init system, after starting up. Some sample values for Type are simple, forking, and exec dbus.

•   Finally, the [Install] section contains directives that specify the circumstances (aka triggers) under which this unit is started. The value of WantedBy is set to multi-user.target here, meaning that our carpald.service unit will be automatically started whenever the multi-user.target (or runlevel) is requested.

2.   Save the text of the script into a file called carpald.service.

3.   Copy or move the script over to the /etc/systemd/system/ directory where systemd will find it:

4.   Now tell systemd about the existence of this new unit file by reloading the systemd daemon:

This might all appear rather elaborate, but the good news is that you only need to set this up once and then pretty much forget about it. As long as the script/daemon/service/process is doing what it is designed to do, and when it is supposed to, there should be no need to babysit it. Specifically, in our example the script will automatically run during startup and shutdown—thanks to systemd. The overhead upfront is well worth the long-term benefits of avoiding carpal tunnel syndrome!

We have set up the “nuts and bolts” around the carpald infrastructure, but it’s not a terribly useful until we actually get it to run. We’ll use the service command to manually start the daemon now:

1.   Use the service command to view the status of the carpald.sh program:

2.   We don’t want to wait for the next system reboot to test the carpald script, so let’s manually start the carpald program using the service command:

TIP  As long as the e-mail subsystem of the server is running (see Chapter 20), you should see a mail message from the carpald.sh script after about an hour. You can use the mail program from the command line by typing the following:

Type q at the ampersand (&) prompt to quit the mail program.

3.   Now stop the carpald service unit by typing the following:

You can similarly use the native systemctl command to stop the carpald daemon by running the following:

Enabling and Disabling Services

At times, you might find that you simply don’t need a particular service to be started at boot time. This is especially important if you are configuring the system as a server and need only specific services and nothing more. Depending on the specific Linux distro, you have various tools (chkconfig, systemctl, rc-, and so on) at your disposal for enabling or disabling services. In the following section, we’ll use the newer Swiss army knife–like systemctl utility, which is found on most modern Linux distros running systemd.

Enabling a Service

Let’s configure carpald service to automatically always start up as part of the system boot process,

1.   Once the specified systemd target (multi-user.target) is reached. Type the following:

This automatically creates a symbolic link for the carpald.service unit under the folder of the target specified in the [Install] section in the WantedBy parameter. The target folder in this example is /etc/systemd/system/multi-user.target.wants/.

2.   Use systemctl to view whether the carpald service is configured to automatically start in the current environment by typing this:

Disabling a Service

To disable a service or systemd unit completely, you must, at a minimum, know the name of the service. You can then use the systemctl tool to turn it off, thereby preventing it from starting in all targets (runlevels).

1.   To disable our “wrist-saving” carpald.sh program from automatic startup, you could type this:

2.   Check carpald.service unit again to see its new startup state:

3.   To remove the carpald.sh program permanently from under systemd’s knowledge and control, stop it, delete its unit file, and then reload systemd. Enter the following:

4.   We are done with our sample carpald.sh script, and we can delete it from the system for good by typing this:

And that’s how services start up and shut down automatically in Linux. Now go take a break.

Odds and Ends of Booting and Shutting Down

Most Linux administrators do not like to shut down their Linux servers. It spoils their “uptime,” which is a thing of pride for Linux system admins. Thus, when a Linux box has to be rebooted, it is usually for unavoidable reasons. Perhaps something bad has happened or the kernel has been upgraded.

Thankfully, Linux does an excellent job of self-recovery, even during reboots. It is rare to have to deal with a system that will not boot correctly, but that is not to say that it will never happen—and that’s what this section is all about.

fsck!

Making sure that data on a system’s hard disk is in a consistent state is an important function. This function is partly controlled by various subsystems/programs and another file called the /etc/fstab file. The File System Check (fsck) tool is automatically run as necessary on every boot, as specified by certain flags in the /etc/fstab file. The specific flag is the passno flag in the sixth field of the each entry in /etc/fstab (see man fstab). The purpose of the fsck program is similar to that of Windows ScanDisk/chkdsk: to check and repair any damage on the file system before continuing the boot process. Because of its critical nature, fsck is traditionally scheduled to run very early in the boot sequence. On systemd-enabled systems, the checks are managed by the systemd-fsck@.service and the systemd-fsck-root.service unit files.

If the file system is found to be in an unclean state or if a certain number of times has passed in between checks, the system will automatically initiate a file system check at the next startup. Of course, you can always manually initiate as an fsck check as necessary (and it isn’t uncommon for the system administrator to be cursing throughout the process).

If fsck does need to run, don’t panic. It is unlikely you’ll have any problems. However, if something does arise, fsck will prompt you with information about the problem and ask whether you want to perform a repair. In general, you’ll find that answering “yes” is the right thing to do.

Virtually all modern Linux distributions use what is called a “journaling file system,” and this makes it easier and quicker to recover from any file system inconsistencies that might arise from unclean shutdowns and other minor software errors. Examples of file systems with this journaling capability are ext4, Btrfs, ext3, ReiserFS, JFS, and XFS.

If your storage partitions or volumes are formatted with any of the journaling-capable file systems (such as XFS, ext4, ext3, Btrfs, or ReiserFS), you will notice that recovering from unclean system resets will be much quicker and easier. The only trade-off with running a journaled file system is the slight overhead involved in keeping the journal, and even this depends on the method by which the file system implements its journaling.

Booting into Single-User (“Recovery”) Mode

Under Windows, the concept of “Recovery Mode” was borrowed from a long-time UNIX feature of booting into single-user mode. What this means for you in the Linux world is that if something gets broken in the startup scripts that affect the booting process of a host, it is possible for you to boot into this mode, fix the problem, and then allow the system to boot into complete multiuser mode (normal behavior).

If you are using the GRUB 2 boot loader, these are the steps:

1.   Select the GRUB entry that you want to boot from the GRUB menu. The entry for the default or most recently installed kernel version will be highlighted by default in the boot menu. Press the E key.

2.   You will next be presented with a submenu with various directives (directives from the file/boot/grub/grub.cfg, /boot/grub2/grub.cfg, /boot/efi/EFI/fedora/grub.cfg, /boot/efi/EFI/ubuntu/grub.cfg, and so on).

3.   Use the ARROW keys on your keyboard to navigate to the line that specifies the Linux kernel to be loaded as well as the parameters to pass to the kernel. On our sample Fedora system, this is the line that begins with linux or linux16. Go to the end of that line, leave a space, and then add the keyword single (or the letter s) to the end of the line.

TIP  Red Hat–based systems like Fedora accept the rd.break kernel command-line parameter, which can be used for password recovery purposes.

4.   Press CTRL-X to boot the system with the temporary changes you just made. The system should boot the kernel into single-user mode.

5.   Depending on the system configuration, you will either be prompted for the root password or simply be given a shell prompt. If prompted for a password, type the root password and press ENTER, and you will get the shell prompt.

6.   You should now effectively be in the systemd rescue.target mode (aka runlevel 1). In this mode, you’ll find that almost all the services that are normally started are not running. This may include network configuration. So if you need to change the IP address, gateway, netmask, or any network-related configuration file, you can. This is also a good time to run fsck manually on any partitions that could not be automatically checked and recovered. (The fsck program will tell you which partitions are misbehaving, if any.)

TIP  In the single-user mode of many Linux distributions, only the root partition will be automatically mounted for you. If you need to access any other partitions, you will need to consult /etc/fstab and mount them yourself using the mount command.

7.   Once you have made any changes you need to make, simply press CTRL-D. This will exit single-user mode and continue with the booting process, or you can just issue the reboot command to reboot the system.

Summary

This chapter looked at the various core concepts involved with starting up and shutting down a typical Linux system. We started our exploration with the almighty boot loader. We looked at GRUB in particular as a sample boot loader/manager, because it is the boot loader of choice among the popular Linux distributions. Next, we explored how things (or services) typically get started and stopped in GNU/Linux, and how Linux decides what to start and stop, and at which runlevel (or target in systemd parlance) it is supposed to do this. We even wrote a little shell program, as a demonstration, that helps us to avoid carpal tunnel syndrome. We then went ahead and configured the system to start up the program automatically during system startup!