Quick HOWTO : Ch07 : The Linux Boot Process

From Linux Home Networking
Revision as of 23:30, 21 July 2012 by Admin (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Introduction

Learning how Linux boots up is critical. When you have this information you can use it to alter the type of login screen you get as well as which programs start up. Read on for the details.

The Linux Boot Sequence

You might remember when you installed Linux that the installation process prompted you for a list of partitions and the sizes of each in which your filesystems would be placed.

When allocating disk space for the partitions, the first sector, or data unit, for each partition is always reserved for programmable code used in booting. The very first sector of the hard disk is reserved for the same purpose and is called the master boot record (MBR).

When booting from a hard disk, the PC system BIOS starts by loading and executing bootloader code. In many cases the complete bootloader code is larger than the space available in the MBR, so booting has to be done in stages.

Fedora Linux uses the Grub staged bootloader system where the first stage bootloader code (boot.img) is run from the MBR, but depending on the version of Grub, the following sequence of events is different.

Grub Version 1

In Stage 1.5 of the Grub version 1 process, additional code is loaded from the 30 kilobytes of hard disk immediately after the MBR. This 1.5 bootloader image file includes enough partition and filesystem drivers to allow the Stage 2 to be loaded from a known location in the boot filesystem, usually /boot/grub. Stage 2 then loads other required drivers and kernel modules before reading the Grub configuration file and displaying the boot menu.

Grub Version 2

Like version 1, version 2 reads an image file (core.img) in the 30 kilobytes after the MBR. To keep its size small, it contains only enough modules to access the boot partition and loads everything it needs, including the boot menu, from there.

Grub After the Boot Menu

The familiar GRUB startup menu is now displayed, which will allow you to select an operating system to boot or to view and edit kernel startup parameters.

Assuming you select a version of Linux to boot, the following steps will happen:

  • The kernel you selected is loaded into memory
  • An image file containing a basic root file system with all the kernel modules and other files the kernel requires to continue the boot process is loaded into memory too. This file is sometimes called initrd ("init ram disk") or initramfs ("init ram filesystem").
  • Grub then starts the kernel and tells it the memory address of the image file. The kernel then mounts this image file as a "starter" memory based root filesystem.
  • The kernel then starts to detect the systems' hardware by loading drivers it needs from this filesystem.
  • The root filesystem on disk takes over from the one in memory
  • The boot process then starts the software daemons according to the system administrator's settings.
  • A root file system will be created in memory using A ramdisk file will be loaded into memory

Let's discuss Grub in more detail.

Grub Configuration Files

As you would expect, the different versions of Grub have different configuration file names and syntaxes. These will be covered next.

Grub Version 1 Configuration

Grub v1 uses the /boot/grub/grub.conf configuration file to get a list of all the available operating systems and their booting parameters. This information is then used to create the familiar GRUB startup menu.

Note: In some operating systems, such as Debian / Ubuntu, the /boot/grub/grub.conf file may also be referred to by the name /boot/grub/menu.lst.

Figure 7-1 shows a typical grub.conf file for a system that can boot both Fedora Linux and Windows 2000.

Figure 7-1 Sample grub.conf file

default=0
timeout=10
splashimage=(hd0,0)/grub/splash.xpm.gz
title Fedora Core (2.6.8-1.521)
        root (hd0,0)
        kernel /vmlinuz-2.6.8-1.521 ro root=LABEL=/
        initrd /initrd-2.6.8-1.521.img
title Windows 2000
      rootnoverify (hd0,1)
      chainloader +1


In this example, the default value is set to 0, which means the system boots the first kernel entry (2.6.8-1.521) when you either:

  • Hit the "enter" key when presented with the startup splash screen and boot menu
  • Let the startup boot menu process timeout at which time it auto boots in an unattended mode

In this configuration example, when default is set to 1, Windows boots.

You can also see that the Fedora kernel file is vmlinuz-2.6.8-1.521 and the memory based root filesystem image file is initrd-2.6.8-1.521.img. Both these files will be found in your /boot directory or partition.

The (hd0,0) and (hd0,1) disk definitions may seem strange, but /boot/grub/device.map file maps the Grub device nomenclature to that expected by Linux.

#
# File: /boot/grub/device.map
#
(fd0)     /dev/fd0
(hd0)     /dev/hda

So (hd0,0) and (hd0,1) refer to the first and second partitions of device /dev/hda respectively.

Grub Version 2 Configuration

When Fedora installs new kernel versions, updated versions of the vmlinuz and initramfs files are deposited in the /etc/grub directory. After doing this, the script grub2-mkconfig is run to create an updated grub menu configuration file /boot/grub2/grub.cfg. This is then used to create the Grub boot menu. A very trimmed version of this file is shown below.

#
# File: /boot/grub2/grub.cfg
#
...
...
...
menuentry 'Fedora (3.4.2-1.fc16.x86_64)' --class fedora --class gnu-linux --class gnu --class os {
        echo 'Loading Fedora (3.4.2-1.fc16.x86_64)'
        linux   /vmlinuz-3.4.2-1.fc16.x86_64 ...
        echo 'Loading initial ramdisk ...'
        initrd /initramfs-3.4.2-1.fc16.x86_64.img
}
...
...

Note: The /boot/grub2/grub.cfg file has sections or stanzas called "menuentry" that define the entries to be shown in the boot menu and the parameters each requires. You don't edit /boot/grub2/grub.cfg as it is auto-generated. Customizations are done in the /etc/default/grub file. A sample is below.

#
# File: /etc/default/grub
#
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="Fedora"
GRUB_DEFAULT=saved
GRUB_CMDLINE_LINUX="rd.md=0 rd.dm=0 rd.lvm.lv=vg_web003/LogVol01 rd.lvm.lv=vg_web003/LogVol00 \
   KEYTABLE=us quiet SYSFONT=latarcyrheb-sun16 rhgb rd.luks=0 LANG=en_US.UTF-8"

Here are what the keywords mean. If you need more information, the official Grub manual at http://www.gnu.org has more details.

  • GRUB_TIMEOUT: The timeout in seconds that the boot menu is displayed.
  • GRUB_DISTRIBUTOR: The distribution of Linux being used
  • GRUB_SAVEDEFAULT: When set to ‘true’, then the menu entry selected will be saved as the new default entry for all future reboots.
  • GRUB_DEFAULT: The name of the menuentry to use in the /boot/grub2/grub.cfg as the version of Linux to boot. If set to a number N, then the Nth entry is used. If set to "saved" then the value of GRUB_SAVEDEFAULT will be used. If GRUB_SAVEDEFAULT isn't defined, then the very first menuentry is used.
  • GRUB_CMDLINE_LINUX: A list of command-line arguments that will be added to the kernel menuentry stanzas in /boot/grub2/grub.cfg.

Now we'll discuss booting runlevels and targets.

Boot Runlevels and Targets

The final post booting state of Linux systems is configured by the systems administrator. With Fedora / RedHat systems there are seven of these states as defined in Table 7-1 "Runlevel and Target Descriptions".

Table 7-1 Runlevel and Target Descriptions

Runlevel Target Description
0 runlevel0.target , poweroff.target Halt
1 runlevel1.target, rescue.target Single-user mode
2 runlevel2.target Not used (user-definable)
3 runlevel3.target , multi-user.target Full multi-user mode (no GUI interface)
4 runlevel4.target Not used (user-definable)
5 runlevel5.target, graphical.target Full multiuser mode (with GUI interface)
6 runlevel6.target, reboot.target Reboot

Depending on your version of Linux there will be one of two main types of runlevel management systems. These are systemd which uses the "target" terminology and init which uses the "runlevel" terminology.

For example, when the system is set for runlevel zero, it halts, and when it's set to runlevel six, it reboots. The default level is usually 3, for booting without a GUI interface, or 5 for booting with one. Single user mode is used for maintenance or emergency repair purposes as it loads a very limited set of drivers and often has network services disabled.

Some differences between the init and systemd systems include:

  • init: The daemon startup scripts in the /etc/rc.X directory are executed, where "X" is the run level. Daemons are started sequentially. Daemons are tracked by process IDs (PIDs) without constraints on resource usage.
  • systemd: You can create your own target directories for your daemons in /etc/systemd/system to create your very own custom post boot states. Daemons can be started in parallel. Daemons are tracked by control groups or cgroups which limit system resources by class of daemon.

Both systems will be discussed next.

Systemd

Symbolic links to the systemd startup configuration files are located in the /etc/systemd/system directory. Each target will have its own subdirectory as shown in Table 7-2.

Table 7-2 Systemd Target File Locations

Target Directory
Default /etc/systemd/system/default.target.wants
Multiuser /etc/systemd/system/multi-user.target.wants
Network /etc/systemd/system/network.target.wants
Sockets /etc/systemd/system/sockets.target.wants
Sysinit /etc/systemd/system/sysinit.target.wants


Fortunately you don't have to be a scripting/symbolic linking guru to make sure everything works right because Fedora RPM daemon packages install their files in the correct locations so that they work correctly at each target level.

When the system boots under systemd, it follows these basic steps.

1. First, systemd reads all the .target files in the /lib/systemd/system/ directory. Each target file contains a list of services that need to be run during the target activation; a list of pre-requisite targets that have to be completed and the target which must be completed immediately beforehand. In some cases the file will include targets that must be completed immediately afterwards. In this sample target file we see that the target expects the steps in sysinit.target and sockets.target to be completed as pre-requisites and that the target will also run immediately after they are completed

#
# File: /lib/systemd/system/basic.target
#
[Unit]
Description=Basic System
Requires=sysinit.target sockets.target
After=sysinit.target sockets.target
RefuseManualStart=yes

2. Using this information, systemd creates a master list of services and the order in which they should be started. The system will boot and systemd will stop starting daemons in the list after it executes the services in the default.target file found in the /etc/systemd/system directory. 3. When all this is completed without errors, the system has booted successfully.

Table 7-3 provides a summary of some important systemd commands that will be helpful to you with systemd. These are then covered in more detail.

Table 7-3 Important Systemd Boot Related Commands

Desired Result Command
Determine the current default target group # ll /etc/systemd/system/default.target
Determine the current active target group (Alternative method # runlevel
Set the default target group (multi-user) # systemctl enable multi-user.target
Change the current target group (multi-user) # systemctl isolate multi-user.target
# systemctl isolate runlevel3.target
List all active targets in the active target group # systemctl list-units --type=target


Determine the current default target group

As stated before the target control files are located in the /etc/systemd directory tree. The file that sets the default target is /etc/systemd/system/default.target. In this case doing a directory listing of this file shows that when the system boots next, it will be in target 3.

[root@bigboy tmp]# ll /etc/systemd/system/default.target
lrwxrwxrwx. 1 root root 36 Jan  1  2012 /etc/systemd/system/default.target -> /lib/systemd/system/runlevel3.target
[root@bigboy tmp]#

The currently running target can be determined using the runlevel command. Here we see that it is set to 3 also.

[root@bigboy tmp]# runlevel
N 3
[root@bigboy tmp]#

If you need to see all the various targets that are active then use the systemctl list-units --type=target command as shown here.

[root@bigboy tmp]# systemctl list-units --type=target 
UNIT                LOAD   ACTIVE SUB    JOB DESCRIPTION
basic.target        loaded active active     Basic System
cryptsetup.target   loaded active active     Encrypted Volumes
getty.target        loaded active active     Login Prompts
local-fs-pre.target loaded active active     Local File Systems (Pre)
local-fs.target     loaded active active     Local File Systems
multi-user.target   loaded active active     Multi-User
network.target      loaded active active     Network
remote-fs.target    loaded active active     Remote File Systems
sockets.target      loaded active active     Sockets
sound.target        loaded active active     Sound Card
swap.target         loaded active active     Swap
sysinit.target      loaded active active     System Initialization
syslog.target       loaded active active     Syslog

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.
JOB    = Pending job for the unit.

13 units listed. Pass --all to see inactive units, too.
[root@bigboy tmp]#

Set the default target group

To set the default target use either the systemctl enable x.target command or the ln -sf command to link the /lib/systemd/system/*.target file to /etc/systemd/system/default.target. In these cases we set the default target to 3 and 5.

[root@bigboy tmp]# systemctl enable multi-user.target

[root@bigboy tmp]# systemctl enable graphical.target

[root@bigboy tmp]# ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target

[root@bigboy tmp]# ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target

Next we'll discuss systems that use init.

SysV Init

When a Linux system running SysV Init begins to boot with its kernel, it first runs the /sbin/init program, which does some system checks, such as verifying the integrity of the file systems, and starts vital programs needed for the operating system to function properly. It then inspects the /etc/inittab file to determine Linux's overall mode of operation or runlevel. A listing of valid runlevels can be seen in Table 7-4. Table 7-4 "Init Runlevel File Locations"

7-4 Init Runlevel File Locations

Runlevel Directory
0 /etc/rc.d/rc0.d
1 /etc/rc.d/rc1.d
2 /etc/rc.d/rc2.d
3 /etc/rc.d/rc3.d
4 /etc/rc.d/rc4.d
5 /etc/rc.d/rc5.d
6 /etc/rc.d/rc6.d

Based on the selected runlevel, the init process then executes startup scripts located in subdirectories of the /etc/rc.d directory. Scripts used for runlevels 0 to 6 are located in subdirectories /etc/rc.d/rc0.d through /etc/rc.d/rc6.d, respectively.

Here is a directory listing of the scripts in the /etc/rc.d/rc3.d directory:


[root@bigboy tmp]# ls /etc/rc.d/rc3.d
...    ...    K75netfs      K96pcmcia    ...    ...
...    ...    K86nfslock    S05kudzu     ...    ...
...    ...    K87portmap    S09wlan      ...    ...
...    ...    K91isdn       S10network   ...    ...
...    ...    K92iptables   S12syslog    ...    ...
...    ...    K95firstboot  S17keytable  ...    ...
[root@bigboy tmp]#

As you can see, each filename in these directories either starts with an "S" which signifies the script should be run at startup, or a K, which means the script should be run when the system is shutting down. If a script isn't there, it won't be run.

Most Linux packages place their startup script in the /etc/init.d directory and place symbolic links (pointers) to this script in the appropriate subdirectory of /etc/rc.d. This makes file management a lot easier. The deletion of a link doesn't delete the file, which can then be used for another day.

The number that follows the K or S specifies the position in which the scripts should be run in ascending order. In our example, kudzu with a value 05 will be started before wlan with a value of 09. Fortunately you don't have to be a scripting/symbolic linking guru to make sure everything works right because Fedora comes with a nifty utility called chkconfig while Debian / Ubuntu uses the update-rc.d command to do it all for you. This is explained later.

Determining and Setting the Default Boot runlevel

The default boot runlevel is set in the file /etc/inittab with the initdefault variable. When set to 3, the system boots up with the text interface on the VGA console; when set to 5, you get the GUI. Here is a snippet of the file (delete the initdefault line you don't need):

# Default runlevel. The runlevels used by RHS are:
# 0 - halt (Do NOT set initdefault to this)
# 1 - Single user mode
# 2 - Multiuser, without NFS (The same as 3, if you do not have networking)
# 3 - Full multiuser mode
# 4 - unused
# 5 - X11
# 6 - reboot (Do NOT set initdefault to this)
# 
id:3:initdefault:                         # Console Text Mode
id:5:initdefault:                         # Console GUI Mode

Note the following:

  • Most home users boot up with a Windows like GUI (runlevel 5)
  • Most techies will tend to boot up with a plain text-based command-line-type interface (runlevel 3)
  • Changing initdefault from 3 to 5, or vice-versa, has an effect upon your next reboot. See the following section on how to get a GUI login all the time until the next reboot.
  • Of course, don't set the initdefault value to 6 or your system will constantly reboot. Setting it to 0 will never allow it to start!

System Shutdown and Rebooting

It is usually not a good idea to immediately power off your system when you are finished using it. This can cause files that are being updated to become corrupted, or worse, you could corrupt the filesystem directory structure. Linux has a number of ways to gracefully shut down and reboot your system which will be outlined in this section.


Halt/Shut Down The System

The init command will allow you to change the current runlevel, and for a shutdown, that value is 0. Here is an example:

[root@bigboy tmp]# init 0

Fedora also has a shutdown command which can also be used to the same effect. It often prompts you as to whether you are sure you want to execute the command, which can be avoided with the -y switch. The -h switch forces the system to halt, and the first argument tells it how long to wait before starting the procedure, in this case 0 minutes. You can also specify shutting down at a specific time of the day; please refer to the man pages for details. Another advantage of the shutdown command is that it warns people that the shutdown is going to occur.

[root@bigboy tmp]# shutdown -hy 0

Broadcast message from root (pts/0) (Sat Nov  6 13:15:27 2004):

The system is going down for system halt NOW!
[root@bigboy tmp]#

Reboot The System

You can also use the init command to reboot the system immediately by entering runlevel 6.

[root@bigboy tmp]# init 6

The "reboot" command has the same effect, but it also sends a warning message to all users.

[root@bigboy tmp]# reboot

Broadcast message from root (pts/0) (Sat Nov  6 12:39:31 2004):

The system is going down for reboot NOW!
[root@bigboy tmp]#

More graceful reboots can be done with the shutdown command using the -r switch and specifying a delay, which in this case is 10 minutes.

[root@bigboy root]# shutdown -ry 10

Broadcast message from root (pts/0) (Sat Nov  6 13:26:39 2004):

The system is going DOWN for reboot in 10 minutes!

Broadcast message from root (pts/0) (Sat Nov  6 13:27:39 2004):

The system is going DOWN for reboot in 9 minutes!
...
...
...
Broadcast message from root (pts/0) (Sat Nov  6 13:36:39 2004):

The system is going down for reboot NOW!

Entering Single-user Mode

Some activities require you to force the system to log off all users, third-party applications and networking so that only the systems administrator has access to the system from the VGA console. A typical scenario is the addition of a new hard disk, as mentioned in Chapter 27, "Expanding Disk Capacity", or the troubleshooting of a failed boot process.

Another reason is the recovery of your root password.

Switching to Single-user Mode

When the system is running normally, this can be done by using the init command to enter runlevel 1. It is best to do this from the console, because if you do it from a remote terminal session you'll be logged out.

[root@bigboy root]# init 1
...
...
bash-2.05b#

Unfortunately, this gives no prior warning to users, and the shutdown command doesn't have a single-user mode option. This can be overcome by running the shutdown command with a delay in minutes as the only argument.

[root@bigboy tmp]# shutdown 1

Broadcast message from root (pts/0) (Sat Nov  6 13:44:59 2004):

The system is going DOWN to maintenance mode in 1 minute!

Broadcast message from root (pts/0) (Sat Nov  6 13:45:59 2004):

The system is going down to maintenance mode NOW!

...
...
bash-2.05b#

Entering Single-user Mode At The Grub Splash Screen

You can enter single user mode directly after turning on the power to your system. The steps to do this are listed below.

1. Power on your system. Wait for the "Grub loading" message to appear and, depending on your Linux distribution, get ready to hit either any key or the ESC key to enter the grub boot menu.

Grub loading, please wait ...
Press ESC to enter the menu

or

Grub loading, please wait ...
Press any key to enter the menu

2. You will then get grub's main menu which will display a list of available kernels. Use the arrow keys to scroll to your desired version of the kernel and then press e for "edit".

Fedora Core (2.6.18-1.2239.fc5smp)
Fedora Core (2.6.18-1.2200.fc5smp)

3. The kernel's boot menu will appear. Use the arrow keys to scroll to the "kernel" line and then press e for "edit".

root (hd0,0)
kernel /vmlinuz-2.6.18-1.2239.fc5smp ro root=LABEL=/
initrd /initrd-2.6.18-1.2239.fc5smp.img

4. A grub edit prompt will appear. Use the arrow keys to move to the end of the line and add the word "single" to the end, separated by a space. Change

grub edit> kernel /vmlinuz-2.6.18-1.2239.fc5smp ro root=LABEL=/

to

grub edit> kernel /vmlinuz-2.6.18-1.2239.fc5smp ro root=LABEL=/ single

5. Press enter to save your changes, and then b for "boot". 6. The system will continue to boot, but will go straight to the root # prompt without first asking for a username and password.

Reverting To Your Default runlevel From Single User Mode

The exit command forces the system to exit runlevel 1 and revert to the default runlevel for the system. You can also use the init command (for example init 3 and init 5) to alter this default behavior:

bash-2.05b# exit
INIT: Entering runlevel: 3
...
...
...
Fedora Core release 2 (Tettnang)
Kernel 2.6.8-1.521 on an i686
bigboy login:

Root Password Recovery

Sometimes you might forget the root password, or the previous systems administrator may move on to a new job without giving it to you. To do this, follow these steps:

  1. Go to the VGA console and press Ctrl-Alt-Del. The system will then shut down in an orderly fashion.
  2. Reboot the system and enter single-user mode.
  3. Once at the command prompt, change your password. Single user mode assumes the person at the console is the systems administrator root, so you don't have to specify a root username.
  4. Return to your default runlevel by using the exit command.


The Linux Console

A good knowledge of some basic Linux console commands is always helpful immediately after booting. Here are some examples.

Getting a GUI Console

Manual Method: You can start the X terminal GUI application each time you need it by running the startx command at the VGA console. Remember that when you log out you will get the regular text-based console again.

[root@bigboy tmp]# startx

Automatic Method: You can have Linux automatically start the X terminal GUI console for every login attempt until your next reboot by using the init command. You will need to edit your initdefault variable in your /etc/inittab file, as mentioned in the preceding section to keep this functionality even after you reboot.

[root@bigboy tmp]# init 5

When the CPU capacity or available memory on your server is low or you want to maximize all system resources, you might want to operate in text mode runlevel 3 most of the time, using the GUI only as necessary with the startx command.

Servers that double as personal workstations, or servers that might have to be operated for an extended period of time by relatively nontechnical staff, may need to be run at runlevel 5 all the time through the init 5 command. Remember you can make runlevel 5 permanent even after a reboot by editing the /etc/inittab file.

Get a Basic Text Terminal Without Exiting the GUI

There are a number of ways for you to get a command prompt when running a Linux GUI. This can be important if you need quick access to commands or you are not familiar with the GUI menu option layout.

Using a GUI Terminal Window

You can open a GUI-based window with a command prompt inside by doing the following:

  • Click on the Fedora logo button in the bottom left hand corner of the screen.
  • Click on Systems Tools and then Terminal

Using Virtual Consoles

By default, Linux runs six virtual console or TTY sessions running on the VGA console. These are defined by the mingetty statements in the /etc/inittab file. The X terminal GUI console creates its own virtual console using the first available TTY that is not controlled by mingetty. This makes the GUI run as number 7:

  • You can step through each virtual console session by using the Ctl-Alt-F1 through F6 key sequence. You'll get a new login prompt for each attempt.
  • You can get the GUI login with the sequence Ctl-Alt-F7 only in run level 5, or if the GUI is running after launching startx.

Conclusion

The topics discussed in this chapter might seem simple, but like syslog, which was covered in Chapter 5, "Troubleshooting Linux with syslog", they are an essential part of Linux administration that gets frequently overlooked especially when new software is installed.

Whenever possible, always try to reboot your system to make sure all the newly installed applications start up correctly. Sometimes they start but give errors listed only in the /var/log directory. Taking the time to configure and test your startup scripts could prevent you from being awakened in the middle of the night while you are on vacation! It is really important.