| Installation GuideBoot Process, Init, and ShutdownAn important and powerful aspect of Red Hat Enterprise Linux is the open, user-configurable method it uses for starting the operating system. Users are free to configure many aspects of the boot process, including specifying the programs launched at boot-time. Similarly, system shutdown gracefully terminates processes in an organized and configurable way, although customization of this process is rarely required. Understanding how the boot and shutdown processes work not only allows customization, but also makes it easier to troubleshoot problems related to starting or shutting down the system. Below are the basic stages of the boot process: The system loads and runs a boot loader. The specifics of this process depend on the system architecture. For example: BIOS-based x86 systems run a first-stage boot loader from the MBR of the primary hard disk that, in turn, loads an additional boot loader, GRUB. UEFI-based x86 systems mount an EFI System Partition that contains a version of the GRUB boot loader. The EFI boot manager loads and runs GRUB as an EFI application. Power Systems servers mount a PPC PReP partition that contains the Yaboot boot loader. The System Management Services (SMS) boot manager loads and runs yaboot. IBM System z runs the z/IPL boot loader from a DASD or FCP-connected device that you specify when you IPL the partition that contains Red Hat Enterprise Linux.
The boot loader loads the kernel into memory, which in turn loads any necessary modules and mounts the root partition read-only. The kernel transfers control of the boot process to the /sbin/init program. The /sbin/init program loads all services and user-space tools, and mounts all partitions listed in /etc/fstab. The user is presented with a login screen for the freshly booted Linux system.
Because configuration of the boot process is more common than the customization of the shutdown process, the remainder of this chapter discusses in detail how the boot process works and how it can be customized to suite specific needs. F.2. A Detailed Look at the Boot ProcessThe beginning of the boot process varies depending on the hardware platform being used. However, once the kernel is found and loaded by the boot loader, the default boot process is identical across all architectures. This chapter focuses primarily on the x86 architecture. F.2.1. The firmware interfaceF.2.1.1. BIOS-based x86 systemsThe Basic Input/Output System (BIOS) is a firmware interface that controls not only the first step of the boot process, but also provides the lowest level interface to peripheral devices. On x86 systems equipped with BIOS, the program is written into read-only, permanent memory and is always available for use. When the system boots, the processor looks at the end of system memory for the BIOS program, and runs it. Once loaded, the BIOS tests the system, looks for and checks peripherals, and then locates a valid device with which to boot the system. Usually, it checks any optical drives or USB storage devices present for bootable media, then, failing that, looks to the system's hard drives. In most cases, the order of the drives searched while booting is controlled with a setting in the BIOS, and it looks on the master IDE on the primary IDE bus or for a SATA device with a boot flag set. The BIOS then loads into memory whatever program is residing in the first sector of this device, called the Master Boot Record (MBR). The MBR is only 512 bytes in size and contains machine code instructions for booting the machine, called a boot loader, along with the partition table. Once the BIOS finds and loads the boot loader program into memory, it yields control of the boot process to it. This first-stage boot loader is a small machine code binary on the MBR. Its sole job is to locate the second stage boot loader (GRUB) and load the first part of it into memory. F.2.1.2. UEFI-based x86 systemsThe Unified Extensible Firmware Interface (UEFI) is designed, like BIOS, to control the boot process (through boot services) and to provide an interface between system firmware and an operating system (through runtime services). Unlike BIOS, it features its own architecture, independent of the CPU, and its own device drivers. UEFI can mount partitions and read certain file systems. When an x86 computer equipped with UEFI boots, the interface searches the system storage for a partition labeled with a specific globally unique identifier (GUID) that marks it as the EFI System Partition (ESP). This partition contains applications compiled for the EFI architecture, which might include bootloaders for operating systems and utility software. UEFI systems include an EFI boot manager that can boot the system from a default configuration, or prompt a user to choose an operating system to boot. When a bootloader is selected, manually or automatically, UEFI reads it into memory and yields control of the boot process to it. F.2.2.1. The GRUB boot loader for x86 systemsThe system loads GRUB into memory, as directed by either a first-stage bootloader in the case of systems equipped with BIOS, or read directly from an EFI System Partition in the case of systems equipped with UEFI. GRUB has the advantage of being able to read ext2, ext3, and ext4 partitions and load its configuration file - /boot/grub/grub.conf (for BIOS) or /boot/efi/EFI/redhat/grub.conf (for UEFI) - at boot time. Refer to Section E.7, "GRUB Menu Configuration File" for information on how to edit this file. The GRUB bootloader in Red Hat Enterprise Linux 6 supports ext2, ext3, and ext4 file systems. It does not support other file systems such as VFAT, Btrfs or XFS. Furthermore, GRUB does not support LVM. Once the second stage boot loader is in memory, it presents the user with a graphical screen showing the different operating systems or kernels it has been configured to boot (when you update the kernel, the boot loader configuration file is updated automatically). On this screen a user can use the arrow keys to choose which operating system or kernel they wish to boot and press Enter. If no key is pressed, the boot loader loads the default selection after a configurable period of time has passed. Once the second stage boot loader has determined which kernel to boot, it locates the corresponding kernel binary in the /boot/ directory. The kernel binary is named using the following format - /boot/vmlinuz-<kernel-version> file (where <kernel-version> The boot loader then places one or more appropriate initramfs images into memory. The initramfs is used by the kernel to load drivers and modules necessary to boot the system. This is particularly important if SCSI hard drives are present or if the systems use the ext3 or ext4 file system. Once the kernel and the initramfs image(s) are loaded into memory, the boot loader hands control of the boot process to the kernel. F.2.2.2. Boot Loaders for Other ArchitecturesOnce the kernel loads and hands off the boot process to the init command, the same sequence of events occurs on every architecture. So the main difference between each architecture's boot process is in the application used to find and load the kernel. For example, the IBM eServer pSeries architecture uses yaboot, and the IBM System z systems use the z/IPL boot loader. Consult the sections of this guide specific to these platforms for information on configuring their boot loaders. When the kernel is loaded, it immediately initializes and configures the computer's memory and configures the various hardware attached to the system, including all processors, I/O subsystems, and storage devices. It then looks for the compressed initramfs image(s) in a predetermined location in memory, decompresses it directly to /sysroot/, and loads all necessary drivers. Next, it initializes virtual devices related to the file system, such as LVM or software RAID, before completing the initramfs processes and freeing up all the memory the disk image once occupied. The kernel then creates a root device, mounts the root partition read-only, and frees any unused memory. At this point, the kernel is loaded into memory and operational. However, since there are no user applications that allow meaningful input to the system, not much can be done with the system. To set up the user environment, the kernel executes the /sbin/init program. F.2.4. The /sbin/init ProgramThe /sbin/init program (also called init) coordinates the rest of the boot process and configures the environment for the user. When the init command starts, it becomes the parent or grandparent of all of the processes that start up automatically on the system. First, it runs the /etc/rc.d/rc.sysinit script, which sets the environment path, starts swap, checks the file systems, and executes all other steps required for system initialization. For example, most systems use a clock, so rc.sysinit reads the /etc/sysconfig/clock configuration file to initialize the hardware clock. Another example is if there are special serial port processes which must be initialized, rc.sysinit executes the /etc/rc.serial file. The init command then processes the jobs in the /etc/event.d directory, which describe how the system should be set up in each SysV init runlevel. Runlevels are a state, or mode, defined by the services listed in the SysV /etc/rc.d/rc<x>.d/ directory, where <x> is the number of the runlevel. For more information on SysV init runlevels, refer to Section F.4, "SysV Init Runlevels". Next, the init command sets the source function library, /etc/rc.d/init.d/functions, for the system, which configures how to start, kill, and determine the PID of a program. The init program starts all of the background processes by looking in the appropriate rc directory for the runlevel specified as the default in /etc/inittab. The rc directories are numbered to correspond to the runlevel they represent. For instance, /etc/rc.d/rc5.d/ is the directory for runlevel 5. When booting to runlevel 5, the init program looks in the /etc/rc.d/rc5.d/ directory to determine which processes to start and stop. Below is an example listing of the /etc/rc.d/rc5.d/ directory: K05innd -> ../init.d/innd K05saslauthd -> ../init.d/saslauthd K10dc_server -> ../init.d/dc_server K10psacct -> ../init.d/psacct K10radiusd -> ../init.d/radiusd K12dc_client -> ../init.d/dc_client K12FreeWnn -> ../init.d/FreeWnn K12mailman -> ../init.d/mailman K12mysqld -> ../init.d/mysqld K15httpd -> ../init.d/httpd K20netdump-server -> ../init.d/netdump-server K20rstatd -> ../init.d/rstatd K20rusersd -> ../init.d/rusersd K20rwhod -> ../init.d/rwhod K24irda -> ../init.d/irda K25squid -> ../init.d/squid K28amd -> ../init.d/amd K30spamassassin -> ../init.d/spamassassin K34dhcrelay -> ../init.d/dhcrelay K34yppasswdd -> ../init.d/yppasswdd K35dhcpd -> ../init.d/dhcpd K35smb -> ../init.d/smb K35vncserver -> ../init.d/vncserver K36lisa -> ../init.d/lisa K45arpwatch -> ../init.d/arpwatch K45named -> ../init.d/named K46radvd -> ../init.d/radvd K50netdump -> ../init.d/netdump K50snmpd -> ../init.d/snmpd K50snmptrapd -> ../init.d/snmptrapd K50tux -> ../init.d/tux K50vsftpd -> ../init.d/vsftpd K54dovecot -> ../init.d/dovecot K61ldap -> ../init.d/ldap K65kadmin -> ../init.d/kadmin K65kprop -> ../init.d/kprop K65krb524 -> ../init.d/krb524 K65krb5kdc -> ../init.d/krb5kdc K70aep1000 -> ../init.d/aep1000 K70bcm5820 -> ../init.d/bcm5820 K74ypserv -> ../init.d/ypserv K74ypxfrd -> ../init.d/ypxfrd K85mdmpd -> ../init.d/mdmpd K89netplugd -> ../init.d/netplugd K99microcode_ctl -> ../init.d/microcode_ctl S04readahead_early -> ../init.d/readahead_early S05kudzu -> ../init.d/kudzu S06cpuspeed -> ../init.d/cpuspeed S08ip6tables -> ../init.d/ip6tables S08iptables -> ../init.d/iptables S09isdn -> ../init.d/isdn S10network -> ../init.d/network S12syslog -> ../init.d/syslog S13irqbalance -> ../init.d/irqbalance S13portmap -> ../init.d/portmap S15mdmonitor -> ../init.d/mdmonitor S15zebra -> ../init.d/zebra S16bgpd -> ../init.d/bgpd S16ospf6d -> ../init.d/ospf6d S16ospfd -> ../init.d/ospfd S16ripd -> ../init.d/ripd S16ripngd -> ../init.d/ripngd S20random -> ../init.d/random S24pcmcia -> ../init.d/pcmcia S25netfs -> ../init.d/netfs S26apmd -> ../init.d/apmd S27ypbind -> ../init.d/ypbind S28autofs -> ../init.d/autofs S40smartd -> ../init.d/smartd S44acpid -> ../init.d/acpid S54hpoj -> ../init.d/hpoj S55cups -> ../init.d/cups S55sshd -> ../init.d/sshd S56rawdevices -> ../init.d/rawdevices S56xinetd -> ../init.d/xinetd S58ntpd -> ../init.d/ntpd S75postgresql -> ../init.d/postgresql S80sendmail -> ../init.d/sendmail S85gpm -> ../init.d/gpm S87iiim -> ../init.d/iiim S90canna -> ../init.d/canna S90crond -> ../init.d/crond S90xfs -> ../init.d/xfs S95atd -> ../init.d/atd S96readahead -> ../init.d/readahead S97messagebus -> ../init.d/messagebus S97rhnsd -> ../init.d/rhnsd S99local -> ../rc.local As illustrated in this listing, none of the scripts that actually start and stop the services are located in the /etc/rc.d/rc5.d/ directory. Rather, all of the files in /etc/rc.d/rc5.d/ are symbolic links pointing to scripts located in the /etc/rc.d/init.d/ directory. Symbolic links are used in each of the rc directories so that the runlevels can be reconfigured by creating, modifying, and deleting the symbolic links without affecting the actual scripts they reference. The name of each symbolic link begins with either a K or an S. The K links are processes that are killed on that runlevel, while those beginning with an S are started. The init command first stops all of the K symbolic links in the directory by issuing the /etc/rc.d/init.d/<command> stop command, where <command> is the process to be killed. It then starts all of the S symbolic links by issuing /etc/rc.d/init.d/<command> start. After the system is finished booting, it is possible to log in as root and execute these same scripts to start and stop services. For instance, the command /etc/rc.d/init.d/httpd stop stops the Apache HTTP Server. Each of the symbolic links are numbered to dictate start order. The order in which the services are started or stopped can be altered by changing this number. The lower the number, the earlier it is started. Symbolic links with the same number are started alphabetically. After the init command has progressed through the appropriate rc directory for the runlevel, Upstart forks an /sbin/mingetty process for each virtual console (login prompt) allocated to the runlevel by the job definition in the /etc/event.d directory. Runlevels 2 through 5 have all six virtual consoles, while runlevel 1 (single user mode) has one, and runlevels 0 and 6 have none. The /sbin/mingetty process opens communication pathways to tty devices , sets their modes, prints the login prompt, accepts the user's username and password, and initiates the login process. In runlevel 5, Upstart runs a script called /etc/X11/prefdm. The prefdm script executes the preferred X display manager - gdm, kdm, or xdm, depending on the contents of the /etc/sysconfig/desktop file. Once finished, the system operates on runlevel 5 and displays a login screen. Previously, the sysvinit package provided the init daemon for the default configuration. When the system started, this init daemon ran the /etc/inittab script to start system processes defined for each runlevel. The default configuration now uses an event-driven init daemon provided by the Upstart package. Whenever particular events occur, the init daemon processes jobs stored in the /etc/event.d directory. The init daemon recognizes the start of the system as such an event. Each job typically specifies a program, and the events that trigger init to run or to stop the program. Some jobs are constructed as tasks, which perform actions and then terminate until another event triggers the job again. Other jobs are constructed as services, which init keeps running until another event (or the user) stops it. For example, the /etc/events.d/tty2 job is a service to maintain a virtual terminal on tty2 from the time that the system starts until the system shuts down, or another event (such as a change in runlevel) stops the job. The job is constructed so that init will restart the virtual terminal if it stops unexpectedly during that time: # tty2 - getty## This service maintains a getty on tty2 from the point the system is# started until it is shut down again.start on stopped rc2start on stopped rc3start on stopped rc4start on started prefdmstop on runlevel 0stop on runlevel 1stop on runlevel 6respawnexec /sbin/mingetty tty2 F.3. Running Additional Programs at Boot TimeThe /etc/rc.d/rc.local script is executed by the init command at boot time or when changing runlevels. Adding commands to the bottom of this script is an easy way to perform necessary tasks like starting special services or initialize devices without writing complex initialization scripts in the /etc/rc.d/init.d/ directory and creating symbolic links. The /etc/rc.serial script is used if serial ports must be setup at boot time. This script runs setserial commands to configure the system's serial ports. Refer to the setserial man page for more information. The SysV init runlevel system provides a standard process for controlling which programs init launches or halts when initializing a runlevel. SysV init was chosen because it is easier to use and more flexible than the traditional BSD-style init process. The configuration files for SysV init are located in the /etc/rc.d/ directory. Within this directory, are the rc, rc.local, rc.sysinit, and, optionally, the rc.serial scripts as well as the following directories: init.d/ rc0.d/ rc1.d/ rc2.d/ rc3.d/ rc4.d/ rc5.d/ rc6.d/
The init.d/ directory contains the scripts used by the /sbin/init command when controlling services. Each of the numbered directories represent the six runlevels configured by default under Red Hat Enterprise Linux. The idea behind SysV init runlevels revolves around the idea that different systems can be used in different ways. For example, a server runs more efficiently without the drag on system resources created by the X Window System. Or there may be times when a system administrator may need to operate the system at a lower runlevel to perform diagnostic tasks, like fixing disk corruption in runlevel 1. The characteristics of a given runlevel determine which services are halted and started by init. For instance, runlevel 1 (single user mode) halts any network services, while runlevel 3 starts these services. By assigning specific services to be halted or started on a given runlevel, init can quickly change the mode of the machine without the user manually stopping and starting services. The following runlevels are defined by default under Red Hat Enterprise Linux: 0 - Halt
1 - Single-user text mode
2 - Not used (user-definable)
3 - Full multi-user text mode
4 - Not used (user-definable)
5 - Full multi-user graphical mode (with an X-based login screen)
6 - Reboot
In general, users operate Red Hat Enterprise Linux at runlevel 3 or runlevel 5 - both full multi-user modes. Users sometimes customize runlevels 2 and 4 to meet specific needs, since they are not used. The default runlevel for the system is listed in /etc/inittab. To find out the default runlevel for a system, look for the line similar to the following near the bottom of /etc/inittab: id:5:initdefault:
The default runlevel listed in this example is five, as the number after the first colon indicates. To change it, edit /etc/inittab as root. Be very careful when editing /etc/inittab. Simple typos can cause the system to become unbootable. If this happens, either use a boot CD or DVD, enter single-user mode, or enter rescue mode to boot the computer and repair the file. It is possible to change the default runlevel at boot time by modifying the arguments passed by the boot loader to the kernel. For information on changing the runlevel at boot time, refer to Section E.8, "Changing Runlevels at Boot Time". F.4.2. Runlevel UtilitiesOne of the best ways to configure runlevels is to use an initscript utility. These tools are designed to simplify the task of maintaining files in the SysV init directory hierarchy and relieves system administrators from having to directly manipulate the numerous symbolic links in the subdirectories of /etc/rc.d/. Red Hat Enterprise Linux provides three such utilities: /sbin/chkconfig - The /sbin/chkconfig utility is a simple command line tool for maintaining the /etc/rc.d/init.d/ directory hierarchy.
/usr/sbin/ntsysv - The ncurses-based /sbin/ntsysv utility provides an interactive text-based interface, which some find easier to use than chkconfig. Services Configuration Tool - The graphical Services Configuration Tool (system-config-services) program is a flexible utility for configuring runlevels.
Refer to the chapter titled Services and Daemons in the Red Hat Enterprise Linux Deployment Guide for more information regarding these tools. To shut down Red Hat Enterprise Linux, the root user may issue the /sbin/shutdown command. The shutdown man page has a complete list of options, but the two most common uses are: /sbin/shutdown -h now
and /sbin/shutdown -r now
After shutting everything down, the -h option halts the machine, and the -r option reboots. PAM console users can use the reboot and halt commands to shut down the system while in runlevels 1 through 5. For more information about PAM console users, refer to the Red Hat Enterprise Linux Deployment Guide. If the computer does not power itself down, be careful not to turn off the computer until a message appears indicating that the system is halted. Failure to wait for this message can mean that not all the hard drive partitions are unmounted, which can lead to file system corruption. |
| |
