GRUB

GRUB2 is the newest version of the GRUB bootloader and is used much more frequently these days. We will not cover GRUB1 or LILO in this course because they are much older than GRUB2.

Because it is easier to write and say GRUB than GRUB2, I will use the term GRUB in this chapter, but I will be referring to GRUB2 unless specified otherwise. GRUB2 stands for “GRand Unified Bootloader, version 2,” and it is now the standard bootloader for most current Linux distributions. GRUB is the program which makes the computer just smart enough to find the operating system kernel and load it into memory, but it takes three stages of GRUB to do this. Wikipedia has an excellent article on GNU GRUB.⁷

GRUB has been designed to be compatible with the multiboot specification which allows GRUB to boot many versions of Linux and other free operating systems. It can also chain load the boot record of proprietary operating systems. GRUB can allow the user to choose to boot from among several different kernels for your Linux distribution if there are more than one present due to system updates. This affords the ability to boot to a previous kernel version if an updated one fails somehow or is incompatible with an important piece of software. GRUB can be configured using the /boot/grub/grub.conf file.

GRUB1 is now considered to be legacy and has been replaced in most modern distributions with GRUB2, which is a complete rewrite of GRUB1. Red Hat-based distros upgraded to GRUB2 around Fedora 15 and CentOS/RHEL 7. GRUB2 provides the same boot functionality as GRUB1, but GRUB2 also provides a mainframe-like command-based pre-OS environment and allows more flexibility during the pre-boot phase.

The primary function of GRUB is to get the Linux kernel loaded into memory and running. The use of GRUB2 commands within the pre-OS environment is outside the scope of this chapter. Although GRUB does not officially use the stage terminology for its three stages, it is convenient to refer to them in that way, so I will.

GRUB stage 1

As mentioned in the BIOS/UEFI POST section, at the end of POST, BIOS/UEFI searches the attached disks for a boot record, which is located in the master boot record (MBR); it loads the first one it finds into memory and then starts execution of the boot record. The bootstrap code, that is GRUB stage 1, is very small because it must fit into the first 512-byte sector on the hard drive along with the partition table.⁸ The total amount of space allocated for the actual bootstrap code in a classic, generic MBR is 446 bytes. The 446-byte file for stage 1 is named boot.img and does not contain the partition table. The partition table is created when the device is partitioned and is overlaid onto the boot record starting at byte 447.

In UEFI systems, the partition table has been moved out of the MBR and into the space immediately following the MBR. This provides more space for defining partitions, so it allows a larger number of partitions to be created.

Because the boot record must be so small, it is also not very smart and does not understand filesystem structures such as EXT4. Therefore the sole purpose of stage 1 is to load GRUB stage 1.5. In order to accomplish this, stage 1.5 of GRUB must be located in the space between the boot record and the UEFI partition data and the first partition on the drive. After loading GRUB stage 1.5 into RAM, stage 1 turns control over to stage 1.5.

Experiment 16-1

Log in to a terminal session as root if there is not one already available. As root in a terminal session, run the following command to verify the identity of the boot drive on your VM. It should be the same drive as the boot partition:

[root@studentvm1 ~]# lsblk -i

NAME                                 MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT

sda                          8:0    0   60G  0 disk

|-sda1                       8:1    0    1G  0 part /boot

`-sda2                       8:2    0   59G  0 part

  |-fedora_studentvm1-root 253:0    0    2G  0 lvm  /

  |-fedora_studentvm1-swap 253:1    0    6G  0 lvm  [SWAP]

  |-fedora_studentvm1-usr  253:2    0   15G  0 lvm  /usr

  |-fedora_studentvm1-home 253:3    0    4G  0 lvm  /home

  |-fedora_studentvm1-var  253:4    0   10G  0 lvm  /var

  `-fedora_studentvm1-tmp  253:5    0    5G  0 lvm  /tmp

[root@studentvm1 ~]#

Use the dd command to view the boot record of the boot drive. For this experiment I assume it is assigned to the /dev/sda device. The bs= argument in the command specifies the block size, and the count= argument specifies the number of blocks to dump to STDIO. The if= argument (InFile) specifies the source of the data stream, in this case, the USB device:

This prints the text of the boot record, which is the first block on the disk – any disk. In this case, there is information about the filesystem and, although it is unreadable because it is stored in binary format, the partition table. Stage 1 of GRUB or some other boot loader is located in this sector but that, too, is mostly unreadable by us mere humans. We can see a couple messages in ASCII text that are stored in the boot record. It might be easier to read these messages if we do this a bit differently. The od command (octal display) displays the data stream piped to it in octal format in a nice matrix that makes the content a bit easier to read. The -a option tells the command to convert into readable ASCII format characters where possible. The last – at the end of the command tells od to take input from the STDIN stream rather than a file:

[root@studentvm1 ~]# dd if=/dev/sda bs=512 count=1 | od -a -

1+0 records in

1+0 records out

0000000   k   c dle dle  so   P   < nul   0   8 nul nul  so   X  so   @

0000020   {   > nul   |   ? nul ack   9 nul stx   s   $   j   ! ack nul

0000040 nul   >   > bel   8 eot   u  vt etx   F dle soh   ~   ~ bel   u

0000060   s   k syn   4 stx   0 soh   ; nul   |   2 nul  nl   t soh  vt

0000100   L stx   M dc3   j nul   | nul nul   k   ~ nul nul nul nul nul

0000120 nul nul nul nul nul nul nul nul nul nul nul nul soh nul nul nul

0000140 nul nul nul nul del   z dle dle   v   B nul   t enq   v   B   p

0000160   t stx   2 nul   j   y   | nul nul   1   @  so   X  so   P   <

0000200 nul  sp   {  sp   d   |   < del   t stx  bs   B   R   > enq   |

0000220   1   @  ht   D eot   @  bs   D del  ht   D stx   G eot dle nul

0000240   f  vt  rs      |   f  ht     bs   f  vt  rs   `   |   f  ht

0000260     ff   G   D ack nul   p   4   B   M dc3   r enq   ; nul   p

0000300   k stx   k   K   `  rs   9 nul soh  so   [   1   v   ? nul nul

0000320  so   F   |   s   %  us   a   `   8 nul   ;   M sub   f enq   @

0000340   u  gs   8 bel   ;   ? nul nul   f   1   v   f   ;   T   C   P

0000360   A   f   9 nul stx nul nul   f   :  bs nul nul nul   M sub   a

0000400 del   &   Z   |   >  us   }   k etx   >   .   }   h   4 nul   >

0000420   3   }   h   . nul   M can   k   ~   G   R   U   B  sp nul   G

0000440   e   o   m nul   H   a   r   d  sp   D   i   s   k nul   R   e

0000460   a   d nul  sp   E   r   r   o   r  cr  nl nul   ; soh nul   4

0000500  so   M dle   ,   < nul   u   t   C nul nul nul nul nul nul nul

0000520 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul

*

0000660 nul nul nul nul nul nul nul nul      ;   ^   . nul nul nul eot

0000700 soh eot etx   ~   B del nul  bs nul nul nul nul  sp nul nul   ~

0000720   B del  so   ~   B del nul  bs  sp nul nul   x   _ bel nul nul

0000740 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul

0000760 nul nul nul nul nul nul nul nul nul nul nul nul nul nul   U   *

0001000

Note the star (*) (splat/asterisk) between addresses 0000520 and 0000660. This indicates that all of the data in that range is the same as the last line before it, 0000520, which is all null characters. This saves space in the output stream. The addresses are in octal, which is base 8.

A generic boot record that does not contain a partition table is located in the /boot/grub2/i386-pc directory. Let’s look at the content of that file. It would not be necessary to specify the block size and the count if we used dd because we are looking at a file that already has a limited length. We can also use od directly and specify the file name rather than using the dd command, although we could do that, too.

Note In Fedora 30 and above, the boot.img files are located in the /usr/lib/grub/i386-pc/ directory. Be sure to use that location when performing the next part of this experiment.

[root@studentvm1 ~]# od -a /boot/grub2/i386-pc/boot.img

0000000   k   c dle nul nul nul nul nul nul nul nul nul nul nul nul nul

0000020 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul

*

0000120 nul nul nul nul nul nul nul nul nul nul nul nul soh nul nul nul

0000140 nul nul nul nul del   z   k enq   v   B nul   t enq   v   B   p

0000160   t stx   2 nul   j   y   | nul nul   1   @  so   X  so   P   <

0000200 nul  sp   {  sp   d   |   < del   t stx  bs   B   R   > enq   |

0000220   1   @  ht   D eot   @  bs   D del  ht   D stx   G eot dle nul

0000240   f  vt  rs      |   f  ht     bs   f  vt  rs   `   |   f  ht

0000260     ff   G   D ack nul   p   4   B   M dc3   r enq   ; nul   p

0000300   k stx   k   K   `  rs   9 nul soh  so   [   1   v   ? nul nul

0000320  so   F   |   s   %  us   a   `   8 nul   ;   M sub   f enq   @

0000340   u  gs   8 bel   ;   ? nul nul   f   1   v   f   ;   T   C   P

0000360   A   f   9 nul stx nul nul   f   :  bs nul nul nul   M sub   a

0000400 del   &   Z   |   >  us   }   k etx   >   .   }   h   4 nul   >

0000420   3   }   h   . nul   M can   k   ~   G   R   U   B  sp nul   G

0000440   e   o   m nul   H   a   r   d  sp   D   i   s   k nul   R   e

0000460   a   d nul  sp   E   r   r   o   r  cr  nl nul   ; soh nul   4

0000500  so   M dle   ,   < nul   u   t   C nul nul nul nul nul nul nul

0000520 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul

*

0000760 nul nul nul nul nul nul nul nul nul nul nul nul nul nul   U   *

0001000

There is second area of duplicated data in this output, between addresses 0000020 and 0000120. Because that area is different from the actual boot record and it is all null in this file, we can infer that this is where the partition table is located in the actual boot record. There is also an interesting utility that enables us to just look at the ASCII text strings contained in a file:

[root@studentvm1 ~]# strings /boot/grub2/i386-pc/boot.img

TCPAf

GRUB

Geom

Hard Disk

Read

 Error

This tool is easier to use to locate actual text strings than sorting through many lines of the occasional random ASCII characters to find meaningful strings. But note that like the first line of the preceding output, not all text strings have meaning to humans.

The point here is that the GRUB boot record is installed in the first sector of the hard drive or other bootable media, using the boot.img file as the source. The partition table is then superimposed on the boot record in its specified location.

GRUB stage 2

All of the files for GRUB stage 2 are located in the /boot/grub2 directory and its subdirectories. GRUB2 does not have an image file like stages 1 and 2. Instead, it consists of those files and runtime kernel modules that are loaded as needed from the /boot/grub2 directory and its subdirectories. Some Linux distributions may store these files in the /boot/grub directory.

The function of GRUB stage 2 is to locate and load a Linux kernel into RAM and turn control of the computer over to the kernel. The kernel and its associated files are located in the /boot directory. The kernel files are identifiable as they are all named starting with vmlinuz. You can list the contents of the /boot directory to see the currently installed kernels on your system.

Experiment 16-3

Your list of Linux kernels should be similar to the ones on my VM, but the kernel versions and probably the releases will be different. You should be using the most recent release of Fedora on your VM, so it should be release 29 or even higher by the time you installed your VMs. That should make no difference to these experiments:

[root@studentvm1 ~]# ll /boot

total 187716

-rw-r--r--. 1 root root     196376   Apr 23    2018   config-4.16.3-301.fc28.x86_64

-rw-r--r--. 1 root root     196172  Aug 15   08:55   config-4.17.14-202.fc28.x86_64

-rw-r--r--  1 root root     197953   Sep 19   23:02   config-4.18.9-200.fc28.x86_64

drwx------. 4 root root       4096   Apr 30    2018   efi

-rw-r--r--. 1 root root     184380   Jun 28   10:55   elf-memtest86+-5.01

drwxr-xr-x. 2 root root       4096   Apr 25    2018   extlinux

drwx------. 6 root root       4096   Sep 23   21:52   grub2

-rw-------. 1 root root   72032025   Aug 13   16:23   initramfs-0-rescue-7f12524278bd40e9b10a085bc82dc504.img

-rw-------. 1 root root   24768511   Aug 13   16:24   initramfs-4.16.3-301.fc28.x86_64.img

-rw-------. 1 root root   24251484   Aug 18   10:46   initramfs-4.17.14-202.fc28.x86_64.img

-rw-------  1 root root   24313919   Sep 23   21:52   initramfs-4.18.9-200.fc28.x86_64.img

drwxr-xr-x. 3 root root       4096   Apr 25    2018   loader

drwx------. 2 root root      16384   Aug 13   16:16   lost+found

-rw-r--r--. 1 root root     182704   Jun 28   10:55   memtest86+-5.01

-rw-------. 1 root root    3888620   Apr 23    2018   System.map-4.16.3-301.fc28.x86_64

-rw-------. 1 root root    4105662   Aug 15   08:55   System.map-4.17.14-202.fc28.x86_64

-rw-------  1 root root    4102469   Sep 19   23:02   System.map-4.18.9-200.fc28.x86_64

-rwxr-xr-x. 1 root root    8286392   Aug 13   16:23   vmlinuz-0-rescue-7f12524278bd40e9b10a085bc82dc504

-rwxr-xr-x. 1 root root    8286392   Apr 23    2018   vmlinuz-4.16.3-301.fc28.x86_64

-rwxr-xr-x. 1 root root    8552728   Aug 15   08:56   vmlinuz-4.17.14-202.fc28.x86_64

-rwxr-xr-x  1 root root    8605976   Sep 19   23:03   vmlinuz-4.18.9-200.fc28.x86_64

[root@studentvm1 ~]#

You can see that there are four kernels and their supporting files in this list. The System.map files are symbol tables that map the physical addresses of the symbols such as variables and functions. The initramfs files are used early in the Linux boot process before the filesystem drivers have been loaded and the filesystems mounted.

GRUB supports booting from one of a selection of installed Linux kernels. The Red Hat Package Manager, DNF, supports keeping multiple versions of the kernel so that if a problem occurs with the newest one, an older version of the kernel can be booted. As shown in Figure 16-1, GRUB provides a pre-boot menu of the installed kernels, including a rescue option and, if configured, a recovery option for each kernel.

The default kernel is always the most recent one that has been installed during updates, and it will boot automatically after a short timeout of five seconds. If the up and down arrows are pressed, the countdown stops, and the highlight bar moves to another kernel. Press Enter to boot the selected kernel.

If almost any key other than the up and down arrow keys or the “e” or “c” keys are pressed, the countdown stops and waits for more input. Now you can take your time to use the arrow keys to select a kernel to boot and then press the Enter key to boot from it. Stage 2 of GRUB loads the selected kernel into memory and turns control of the computer over to the kernel.

The rescue boot option is intended as a last resort when attempting to resolve boot severe problems – ones which prevent the Linux system from completing the boot process. When some types of errors occur during boot, GRUB will automatically fall back to boot from the rescue image.

The GRUB menu entries for installed kernels has been useful to me. Before I became aware of VirtualBox I used to use some commercial virtualization software that sometimes experienced problems when the Linux was updated. Although the company tried to keep up with kernel variations, they eventually stopped updating their software to run with every kernel version. Whenever they did not support a kernel version to which I had updated, I used the GRUB menu to select an older kernel which I knew would work. I did discover that maintaining only three older kernels was not always enough, so I configured the DNF package manager to save up to ten kernels. DNF package manager configuration is covered in Volume 1, Chapter 12.

Configuring GRUB

GRUB is configured with /boot/grub2/grub.cfg, but we do not change that file because it can get overwritten when the kernel is updated to a new version. Instead, we make modifications to the /etc/default/grub file.

Experiment 16-4

Let’s start by looking at the unmodified version of the /etc/default/grub file:

[root@studentvm1 ~]# cd /etc/default ; cat grub

GRUB_TIMEOUT=5

GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"

GRUB_DEFAULT=saved

GRUB_DISABLE_SUBMENU=true

GRUB_TERMINAL_OUTPUT="console"

GRUB_CMDLINE_LINUX="resume=/dev/mapper/fedora_studentvm1-swap rd.lvm.lv=fedora_studentvm1/root rd.lvm.lv=fedora_studentvm1/swap rd.lvm.lv=fedora_studentvm1/usr rhgb quiet"

GRUB_DISABLE_RECOVERY="true"

[root@studentvm1 default]#

Chapter 6 of the GRUB documentation referenced in footnote 6 contains a complete listing of all the possible entries in the /etc/default/grub file, but there are three that we should look at here.

I always change GRUB_TIMEOUT, the number of seconds for the GRUB menu countdown, from five to ten which gives a bit more time to respond to the GRUB menu before the countdown hits zero.

I also change GRUB_DISABLE_RECOVERY from “true” to “false” which is a bit of reverse programmer logic. I have found that the rescue boot option does not always work. To circumvent this problem, I change this statement to allow the grub2-mkconfig command to generate a recovery option for each installed kernel; I have found that when the rescue option fails, these options do work. This also provides recovery kernels for use in case a particular tool or software package that needs to run on a specific kernel version is able to do so.

Note Changing GRUB_DISABLE_RECOVERY in the grub default configuration no longer works starting in Fedora 30. The other changes, GRUB_TIMEOUT and removing “rhgb quiet” from the GRUB_CMDLINE_LINUX variable, still work.

The GRUB_CMDLINE_LINUX line can be changed, too. This line lists the command-line parameters that are passed to the kernel at boot time. I usually delete the last two parameters on this line. The rhgb parameter stands for Red Hat Graphical Boot, and it causes the little graphical animation of the Fedora icon to display during the kernel initialization instead of showing boot time messages. The quiet parameter prevents the display of the startup messages that document the progress of the startup and any errors that might occur. Delete both of these entries because SysAdmins need to be able to see these messages. If something goes wrong during boot, the messages displayed on the screen can point us to the cause of the problem.

Change these three lines as described so that your grub file looks like this:

[root@studentvm1 default]# cat grub

GRUB_TIMEOUT=10

GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"

GRUB_DEFAULT=saved

GRUB_DISABLE_SUBMENU=true

GRUB_TERMINAL_OUTPUT="console"

GRUB_CMDLINE_LINUX="resume=/dev/mapper/fedora_studentvm1-swap rd.lvm.lv=fedora_studentvm1/root rd.lvm.lv=fedora_studentvm1/swap rd.lvm.lv=fedora_studentvm1/usr"

GRUB_DISABLE_RECOVERY="false"

[root@studentvm1 default]#

Check the current content of the /boot/grub2/grub.cfg file. Run the following command to update the /boot/grub2/grub.cfg configuration file:

[root@studentvm1 grub2]# grub2-mkconfig > /boot/grub2/grub.cfg

Generating grub configuration file ...

Found linux image: /boot/vmlinuz-4.18.9-200.fc28.x86_64

Found initrd image: /boot/initramfs-4.18.9-200.fc28.x86_64.img

Found linux image: /boot/vmlinuz-4.17.14-202.fc28.x86_64

Found initrd image: /boot/initramfs-4.17.14-202.fc28.x86_64.img

Found linux image: /boot/vmlinuz-4.16.3-301.fc28.x86_64

Found initrd image: /boot/initramfs-4.16.3-301.fc28.x86_64.img

Found linux image: /boot/vmlinuz-0-rescue-7f12524278bd40e9b10a085bc82dc504

Found initrd image: /boot/initramfs-0-rescue-7f12524278bd40e9b10a085bc82dc504.img

done

[root@studentvm1 grub2]#

Recheck the content of /boot/grub2/grub.cfg which should reflect the changes we made. You can grep for the specific lines we changed to verify that the changes occurred. We could also use an alternative form of this command to specify the output file. grub2-mkconfig -o /boot/grub2/grub.cfg Either form works, and the results are the same.

Reboot the StudentVM1 virtual machine. Press the Esc key when the GRUB menu is displayed. The first difference you should notice in the GRUB menu is that the countdown timer started at ten seconds. The GRUB menu should now appear similar to that shown in Figure 16-2 with a recovery option for each kernel version. The details of your menu will be different from these.

Use the down arrow key to highlight the recovery option for the default kernel – the second option – and press the Enter key to complete the boot and startup process. This will take you into recovery mode using that kernel. You will also notice many messages displayed on the screen as the system boots and goes through startup. Some of these messages can be seen in Figure 16-3 along with messages pertaining to the rescue shell.

Based on these messages, we can conclude that “recovery” mode is a rescue mode in which we get to choose the kernel version. The system displays a login message:

Give root password for maintenance

(or press Control-D to continue):

Type the root password to log in. There are also instructions on the screen in case you want to reboot or continue into the default runlevel target.

Notice also at the bottom of the screen in Figure 16-3 that the little trail of messages we will embed in the bash startup configuration files in Chapter 17 shows here that the /etc/bashrc and /etc/profile.d/myBashConfig.sh files – along with all of the other bash configuration files in /etc/profile.d – were run at login. I have skipped ahead a bit with this, but I will show you how to test it yourself in Chapter 17. This is good information to have because you will know what to expect in the way of shell configuration while working in recovery mode.

While in recovery mode, explore the system while it is in the equivalent of what used to be called single user mode. The lsblk utility will show that all of the filesystems are mounted in their correct locations and the ip addr command will show that networking has not been started. The computer is up and running, but it is in a very minimal mode of operation. Only the most essential services are available to enable pxroblem solving. The runlevel command will show that the host is in the equivalent of the old SystemV runlevel 1.

Before completing this experiment, reboot your VM to one of the older regular kernels, and log in to the desktop. Test a few programs, and then open a terminal session to test some command-line utilities. Everything should work without a problem because the kernel version is not bound to specific versions of the rest of the Linux operating system. Running an alternate kernel is easy and commonplace.

To end this experiment, reboot the system and allow the default kernel to boot. No intervention will be required. Youx will see all of the kernel boot and startup messages during this normal boot.

There are three different terms that are typically applied to recovery mode: recovery, rescue, and maintenance. These are all functionally the same. Maintenance mode is typically used when the Linux host fails to boot to its default target due to some error that occurs during the boot and startup. Being able to see the boot and startup messages if an error occurs can also provide clues as to where the problem might exist.

I have found that the rescue kernel, the option at the bottom of the GRUB menu in Figures 16-1, 16-2, and 16-3, almost never works and I have tried it on a variety of physical hardware and virtual machines, and it always fails. So I need to use the recovery kernels, and that is why I configure GRUB to create those recovery menu options.

In Figure 16-2, after configuring GRUB and running the grub2-mkconfig -o /boot/grub2/grub.cfg command, there are two rescue mode menu options. In my testing I have discovered that the top rescue mode menu option fails but that the bottom rescue mode menu option, the one we just created, does work. But it really does not seem to matter because, as I have said, both rescue and recovery modes provide exactly the same function. This problem is a bug, probably in GRUB, so I reported it to Red Hat using Bugzilla.⁹

Part of our responsibility as SysAdmins, and part of giving back to the open source community, is to report bugs when we encounter them. Anyone can create an account and log in to report bugs. Updates will be sent to you by e-mail whenever a change is made to the bug report.

The Linux kernel

All Linux kernels are in a self-extracting, compressed format to save space. The kernels are located in the /boot directory, along with an initial RAM disk image and symbol maps. After the selected kernel is loaded into memory by GRUB and begins executing, it must first extract itself from the compressed version of the file before it can perform any useful work. The kernel has extracted itself, loads systemd, and turns control over to it.

This is the end of the boot process. At this point, the Linux kernel and systemd are running but unable to perform any productive tasks for the end user because nothing else is running, no shell to provide a command line, no background processes to manage the network or other communication links, and nothing that enables the computer to perform any productive function.

systemd

systemd^10,11 is the mother of all processes, and it is responsible for bringing the Linux host up to a state in which productive work can be done. Some of its functions, which are far more extensive than the old SystemV¹² init program, are to manage many aspects of a running Linux host, including mounting filesystems and starting and managing system services required to have a productive Linux host. Any of systemd’s tasks that are not related to the startup sequence are outside the scope of this chapter, but we will explore them in Volume 2, Chapter 13.

First systemd mounts the filesystems as defined by /etc/fstab, including any swap files or partitions. At this point, it can access the configuration files located in /etc, including its own. It uses its configuration link, /etc/systemd/system/default.target, to determine which state or target, into which it should boot the host. The default.target file is a symbolic link to the true target file. For a desktop workstation, this is typically going to be the graphical.target, which is equivalent to runlevel 5 in SystemV. For a server, the default is more likely to be the multi-user.target which is like runlevel 3 in SystemV. The emergency.target is similar to single user mode. Targets and services are systemd units.

Figure 16-4 is a comparison of the systemd targets with the old SystemV startup runlevels. The systemd target aliases are provided by systemd for backward compatibility. The target aliases allow scripts — and many SysAdmins like myself — to use SystemV commands like init 3 to change runlevels. Of course the SystemV commands are forwarded to systemd for interpretation and execution.

Each target has a set of dependencies described in its configuration file. systemd starts the required dependencies. These dependencies are the services required to run the Linux host at a specific level of functionality. When all of the dependencies listed in the target configuration files are loaded and running, the system is running at that target level.

systemd also looks at the legacy SystemV init directories to see if any startup files exist there. If so, systemd used those as configuration files to start the services described by the files. The deprecated network service is a good example of one of those that still use SystemV startup files in Fedora.

Figure 16-5 is copied directly from the bootup man page. It shows a map of the general sequence of events during systemd startup and the basic ordering requirements to ensure a successful startup.

The sysinit.target and basic.target targets can be considered as checkpoints in the startup process. Although systemd has as one of its design goals to start system services in parallel, there are still certain services and functional targets that must be started before other services and targets can be started. These checkpoints cannot be passed until all of the services and targets required by that checkpoint are fulfilled.

The sysinit.target is reached when all of the units on which it depends are completed. All of those units, mounting filesystems, setting up swap files, starting udev, setting the random generator seed, initiating low-level services, and setting up cryptographic services if one or more filesystems are encrypted, must be completed, but within the sysinit.target, those tasks can be performed in parallel.

The sysinit.target starts up all of the low-level services and units required for the system to be marginally functional, and that are required to enable moving on to the basic.target.

After the sysinit.target is fulfilled, systemd next starts the basic.target, starting all of the units required to fulfill it. The basic target provides some additional functionality by starting units that are required for all of the next targets. These include setting up things like paths to various executable directories, communication sockets, and timers.

Finally, the user-level targets, multi-user.target, or graphical.target can be initialized. The multi-user.target must be reached before the graphical target dependencies can be met. The underlined targets in Figure 16-5 are the usual startup targets. When one of these targets is reached, then startup has completed. If the multi-user.target is the default, then you should see a text mode login on the console. If graphical.target is the default, then you should see a graphical login; the specific GUI login screen you see will depend upon the default display manager.

The bootup man page also describes and provides maps of the boot into the initial RAM disk and the systemd shutdown process.

GRUB and the systemd init system are key components in the boot and startup phases of most modern Linux distributions. These two components work together smoothly to first load the kernel and then to start up all of the system services required to produce a functional GNU/Linux system.

Although I do find both GRUB and systemd more complex than their predecessors, they are also just as easy to learn and manage. The man pages have a great deal of information about systemd, and freedesktop.org has a web site that describes the complete startup process¹⁴ and a complete set of systemd man pages¹⁵ online.

Graphical login screen

There are still two components that figure in to the very end of the boot and startup process for the graphical.target, the display manager (dm) and the window manager (wm). These two programs, regardless of which ones you use on your Linux GUI desktop system, always work closely together to make your GUI login experience smooth and seamless before you even get to your desktop.

Display manager

The display manager¹⁶ is a program with the sole function of providing the GUI login screen for your Linux desktop. After you log in to a GUI desktop, the display manager turns control over to the window manager. When you log out of the desktop, the display manager is given control again to display the login screen and wait for another login.

There are several display managers; some are provided with their respective desktops. For example, the kdm display manager is provided with the KDE desktop. Many display managers are not directly associated with a specific desktop. Any of the display managers can be used for your login screen regardless of which desktop you are using. And not all desktops have their own display managers. Such is the flexibility of Linux and well-written, modular code.

The typical desktops and display managers are shown in Figure 16-6. The display manager for the first desktop that is installed, that is, GNOME, KDE, etc., becomes the default one. For Fedora, this is usually gdm which is the display manager for GNOME. If GNOME is not installed, then the display manager for the installed desktop is the default. If the desktop selected during installation does not have a default display manager, then gdm is installed and used. If you use KDE as your desktop, the new SDDM¹⁷ will be the default display manager.

Regardless of which display manager is configured as the default at installation time, later installation of additional desktops does not automatically change the display manager used. If you want to change the display manager, you must do it yourself from the command line. Any display manager can be used, regardless of which window manager and desktop are used.

Window manager

The function of a window manager¹⁸ is to manage the creation, movement, and destruction of windows on a GUI desktop including the GUI login screen. The window manager works with the Xwindow¹⁹ system or the newer Wayland²⁰ to perform these tasks. The Xwindow system provides all of the graphical primitives and functions to generate the graphics for a Linux or Unix graphical user interface.

The window manager also controls the appearance of the windows it generates. This includes the functional decorative aspects of the windows, such as the look of buttons, sliders, window frames, pop-up menus, and more.

As with almost every other component of Linux, there are many different window managers from which to choose. The list in Figure 16-7 represents only a sample of the available window managers. Some of these window managers are stand-alone, that is, they are not associated with a desktop and can be used to provide a simple graphical user interface without the more complex, feature-rich, and more resource-intensive overhead of a full desktop environment. Stand-alone window managers should not be used with any of the desktop environments.

Most window managers are not directly associated with any specific desktop. In fact some window managers can be used without any type of desktop software, such as KDE or GNOME, to provide a very minimalist GUI experience for users. Many desktop environments support the use of more than one window manager.

How do I deal with all these choices?

In most modern distributions, the choices are made for you at installation time and are based on your selection of desktops and the preferences of the packagers of your distribution. The desktop and window managers and the display manager can be easily changed.

Now that systemd has become the standard startup system in many distributions, you can set the preferred display manager in /etc/systemd/system which is where the basic system startup configuration is located. There is a symbolic link (symlink) named display-manager.service that points to one of the display manager service units in /usr/lib/systemd/system. Each installed display manager has a service unit located there. To change the active display manager, remove the existing display-manager.service link, and replace it with the one you want to use.

Experiment 16-6

Perform this experiment as root. We will install additional display managers and stand-alone window managers then switch between them.

Check and see which display managers are already installed. The RPMs in which the window managers are packaged have inconsistent naming, so it is difficult to locate them using a simple DNF search unless you already know their RPM package names which, after a bit of research, I do:

[root@studentvm1 ~]# dnf list compiz fluxbox fvwm icewm xorg-x11-twm xfwm4

Last metadata expiration check: 1:00:54 ago on Thu 29 Nov 2018 11:31:21 AM EST.

Installed Packages

xfwm4.x86_64                 4.12.5-1.fc28                      @updates

Available Packages

compiz.i686                  1:0.8.14-5.fc28                    fedora

compiz.x86_64                1:0.8.14-5.fc28                    fedora

fluxbox.x86_64               1.3.7-4.fc28                       fedora

fvwm.x86_64                  2.6.8-1.fc28                       updates

icewm.x86_64                 1.3.8-15.fc28                      fedora

xorg-x11-twm.x86_64          1:1.0.9-7.fc28                     fedora

[root@studentvm1 ~]#

Now let’s look for the display managers:

[root@studentvm1 ~]# dnf list gdm kdm lightdm lxdm sddm xfdm xorg-x11-xdm

Last metadata expiration check: 2:15:20 ago on Thu 29 Nov 2018 11:31:21 AM EST.

Installed Packages

lightdm.x86_64               1.28.0-1.fc28                      @updates

Available Packages

gdm.i686                     1:3.28.4-1.fc28                    updates

gdm.x86_64                   1:3.28.4-1.fc28                    updates

kdm.x86_64                   1:4.11.22-22.fc28                  fedora

lightdm.i686                 1.28.0-2.fc28                      updates

lightdm.x86_64               1.28.0-2.fc28                      updates

lxdm.x86_64                  0.5.3-10.D20161111gita548c73e.fc28 fedora

sddm.i686                    0.17.0-3.fc28                      updates

sddm.x86_64                  0.17.0-3.fc28                      updates

xorg-x11-xdm.x86_64          1:1.1.11-16.fc28                   fedora

[root@studentvm1 ~]#

Each dm is started as a systemd service, so another way to determine which ones are installed is to check the /usr/lib/systemd/system/ directory. The lightdm display manager shows up twice as installed and available because there is an update for it:

[root@studentvm1 ~]# cd /usr/lib/systemd/system/ ; ll *dm.service

-rw-r--r-- 1 root root 1059 Sep  1 11:38 lightdm.service

[root@studentvm1 system]#

Like my VM, yours should have only a single dm, the lightdm. Let’s install lxdm and xorg-x11-xdm as the additional display managers, with FVWM, fluxbox, and icewm for window managers:

[root@studentvm1 ~]# dnf install -y lxdm xorg-x11-xdm compiz fvwm fluxbox icewm

Now we must restart the display manager service so that the newly installed window managers in the display manager selection tool. The simplest way is to log out of the desktop and restart the dm from a virtual console session:

[root@studentvm1 ~]# systemctl restart display-manager.service

Or we could do this by switching to the multiuser target and then back to the graphical target. Do this, too, just to see what switching between these targets looks like:

[root@studentvm1 ~]# systemctl isolate multi-user.target

[root@studentvm1 ~]# systemctl isolate graphical.target

But this second method is a lot more typing. Switch back to the lightdm login on vc1, and look in the upper right corner of the lightdm login screen. The leftmost icon, which on my VM looks like a sheet of paper with a wrench,²¹ allows us to choose the desktop or window manager we want to use before we log in. Click this icon and choose FVWM from the menu in Figure 16-8, then log in.

Explore this window manager. Open an Xterm instance, and locate the menu option that gives access to application programs. Figure 16-9 shows the Fvwm desktop (this is not a desktop environment like KDE or GNOME) with an open Xterm instance and a menu tree that is opened with a left click on the display. A different menu is opened with a right-click.

Fvwm is a very basic but usable window manager. Like most window managers, it provides menus to access various functions and a graphical display that supports simple windowing functionality. Fvwm also provides multiple windows in which to run programs for some task management capabilities.

Notice that the XDGMenu in Figure 16-9 also contains Xfce applications. The Start Here menu item leads to the Fvwm menus that include all of the standard Linux applications that are installed on the host.

After spending a bit of time exploring the Fvwm interface, log out. Can’t find the way to do that? Neither could I as it is very nonintuitive. Left-click the desktop and open the FvwmConsole. Then type in the command Quit – yes, with the uppercase Q – and press Enter.

We could also open an Xterm session and use the following command which kills all instances of the Fvwm window manager belonging to the student user:

[student@studentvm1 ~]# killall fvwm

Try each of the other window managers, exploring the basic functions of launching applications and a terminal session. When you have finished that, exit whichever window manager you are in, and log in again using the Xfce desktop environment.

Now let’s change the display manager to one of the new ones we have installed. Each dm has the same function, to provide a GUI for login and some configuration such as the desktop environment or window manager to start as the user interface. Change into the /etc/systemd/system/ directory, and list the link for the display manager service:

[root@studentvm1 ~]# cd /etc/systemd/system/ ; ll display-manager.service

total 60

lrwxrwxrwx. 1 root root   39 Apr 25  2018  display-manager.service -> /usr/lib/systemd/system/lightdm.service

Locate all of the display manager services in /usr/lib/systemd/system/:

[root@studentvm1 system]# ll /usr/lib/systemd/system/*dm.service

-rw-r--r-- 1 root root 1059 Sep 26 11:04 /usr/lib/systemd/system/lightdm.service

-rw-r--r-- 1 root root  384 Feb 14  2018 /usr/lib/systemd/system/lxdm.service

-rw-r--r-- 1 root root  287 Feb 10  2018 /usr/lib/systemd/system/xdm.service

And make the change:

[root@studentvm1 system]# rm -f display-manager.service

[root@studentvm1 system]# [root@studentvm1 system]# ln -s /usr/lib/systemd/system/xdm.service display.manager.service

[root@studentvm1 system]# ll display-manager.service

lrwxrwxrwx 1 root root 35 Nov 30 09:03 display.manager.service -> /usr/lib/systemd/system/xdm.service

[root@studentvm1 system]#

As far as I can tell at this point, rebooting the host is the only way to reliably activate the new dm. Go ahead and reboot your VM now to do that.

There is a tool, system-switch-displaymanager, which is supposed to make the necessary changes, and it does seem to work sometimes. But this tool does not restart the dm, and many times that step fails when performed. Unfortunately, my own experiments have determined that restarting the display manager service does not activate the new dm. The following steps are supposed to work; try it to see if it works for you as you switch back to the lightdm display manager:

[root@studentvm1 ~]# dnf -y install system-switch-displaymanager

[root@studentvm1 ~]# system-switch-displaymanager lightdm

[root@studentvm1 ~]# systemctl restart display-manager.service

If the second two steps in this sequence does not work, then reboot. Jason Baker, my technical reviewer, says, “This seemed to work for me, but then it failed to actually log in to lightdm, so I had to reboot.”

Different distributions and desktops have various means of changing the window manager, but, in general, changing the desktop environment also changes the window manager to the default one for that desktop. For current releases of Fedora Linux, the desktop environment can be changed on the display manager login screen. If stand-alone display managers are also installed, they also appear in the list with the desktop environments.

There are many different choices for display and window managers available. When you install most modern distributions with any kind of desktop, the choices of which ones to install and activate are usually made by the installation program. For most users, there should never be any need to change these choices. For others who have different needs, or for those who are simply more adventurous, there are many options and combinations from which to choose. With a little research, you can make some interesting changes.

CLI login screen

The CLI login screen is initiated by a program called a getty, which stands for GET TTY. The historical function of a getty was to wait for a connection from a remote dumb terminal to come in on a serial communications line. The getty program would spawn the login screen and wait for a login to occur. When the remote user would log in, the getty would terminate, and the default shell for the user account would launch and allow the user to interact with the host on the command line. When the user would log out, the init program would spawn a new getty to listen for the next connection.

Starting with step 3, this is a circular process that repeats as long as the host is up and running. New login screens are displayed on a virtual console immediately after the user logs out of the old session.

GUI login screen

The steps are almost the same, and the display manager functions as a graphical version of the agetty.