Booting and Shutting Down Your SuSE Linux Enterprise Server
This chapter is from the book
This chapter is from the book
This chapter is from the book
This chapter explores the various states a server goes through during startup and shutdown procedures. We first examine the path a machine takes from the moment power is applied to a fully running system and how it can be shut down safely.
We also discuss the concept of runlevels and how they are used to control the various applications available on a server. We then explore the preparations required to facilitate system recovery should the server experience difficulties.
As with all things, it is best to start at the beginning: boot loaders.
Boot Loaders
A systematic chain of events is triggered when power is applied to a machine. Commonly, this is called cold booting or simply booting. As power is applied to the system, a process called the Power On Self Test (POST) is initiated. This stage verifies that the hardware present within the system is operating properly and the saved configuration for the detected hardware within the system matches what is actually preset.
At the end of the POST, control is passed to the Basic Input Output System (BIOS). This small set of instructions loads the stored configuration setting for the various pieces of hardware present within the server. These settings include the date, time, hard drive geometry, and the memory mappings of the various devices.
When this stage has successfully completed, the BIOS loads and executes the instruction found in the Master Boot Record (MBR) of the primary boot device. The MBR is relatively small and is in essence a pointer to the location of the next routine to be executed.
At this point, the SUSE LINUX install passes control over to a piece of software in the MBR that permits the loading of the system kernel. This type of program is called a boot loader.
"The Installation Overview" section of Chapter 1 presented two separate boot loaders available with the default install of SUSE Enterprise Server: LILO and Grub. Both of these routines allow for the targeting of the boot process to a specific boot device, kernel, and unique collection of kernel parameters.
Both LILO and Grub are two-stage boot loaders. The first stage is small enough to be made resident within the Master Boot Record of the volume. Its sole purpose is to properly load the second stage. Though both of these boot loaders have the same goal, there are significant differences in their capabilities. The YaST configuration utility should be used to configure the behavior of both boot loaders.
LILO
The LInux LOader (LILO) is a more static boot loader than its counterpart Grub. The LILO application keeps track of the physical location of the kernel on the volume and stores the reference in a file. At boot time, the application can pass control to the kernel by loading it directly by reference.
LILO maintains a list of possible boot targets in its configuration file. The file /etc/lilo.conf contains both parameters that affect LILO’s behavior as well as a list of valid boot targets and kernel options for each.
In the case of a SUSE server, the default configuration includes
The SUSE kernel and the appropriate parameters that take full advantage of the detected hardware
A failsafe SUSE kernel with most advanced functions such as ACPI and SVGA turned off
An 8-second clock for selecting which kernel configuration to use to boot the machine
Listing 3.1 shows a sample LILO configuration from an SLES install. In this example, the header information shows the 8-second (80 tenths of a second) timeout and the default boot option label of Linux. You can also see the removal of APM, ACPI, and other facilities in the Failsafe option. Further details on the options available in lilo.conf can be found in the SLES Administrator’s manual as well as on the following web page: http://www.novell.com/documentation/oes/index.html?page=/documentation/oes/sles_admin/data/sec-lilo-overview.html.
LISTING 3.1: SAMPLE LILO CONFIGURATION
# Modified by YaST2. Last modification on Thu Jan 6 11:40:50 2005 message = /boot/message timeout = 80 prompt default = Linux boot = /dev/sda image = /boot/vmlinuz label = Linux initrd = /boot/initrd optional root = /dev/sda1 append = "selinux=0 splash=silent resume=/dev/sda3 showopts elevator=cfq" image = /boot/vmlinuz label = Failsafe initrd = /boot/initrd optional root = /dev/sda1 vga = normal append = "showopts ide=nodma apm=off acpi=off noresume selinux=0 barrier=off nosmp noapic maxcpus=0 3" image = /boot/memtest.bin label = Memory_Test optional append = ""
At boot time, the boot loader relies on the physical location of the kernel on the device. This location is identified by the actual Cylinder, Head and Sector (CHS) where the kernel resides on the disk. When a kernel is defined in the /etc/lilo.conf file, it is not immediately available for access through LILO. To enable the new kernel, the LILO routine must be run with the -C option. This option will cause the lilo.conf file to be read; the identified kernels will be located on the device and their physical location (CHS) updated in the LILO map file. Failure to perform this extra step will render the new kernel inaccessible at boot time.
Though it may seem a serious limitation to limit kernel accessibility at boot time, it does provide assurance that the selections are those produced through the appropriate routines.
Grub
The GRand Unified Bootloader is more commonly called Grub. This boot loader program is significantly more dynamic than LILO. As you can see in Listing 3.2, there are many similarities between the formatting and information contained in both boot loader configuration files.
In addition to the boot options available through LILO, Grub adds the capability of redirecting the boot to a floppy. Keep in mind that even if you removed the system’s capacity to boot off a floppy in the BIOS, this boot loader, once loaded from the primary boot device, presents the floppy as a valid alternate boot device.
LISTING 3.2: GRUB menu.lst
# Modified by YaST2. Last modification on Wed Jan 5 10:16:38 2005 color white/blue black/light-gray default 0 timeout 8 gfxmenu (hd0,0)/boot/message ###Don’t change this comment - YaST2 identifier: Original name: linux### title Linux kernel (hd0,0)/boot/vmlinuz root=/dev/sda1 selinux=0 splash=silent resume=/dev/sda2 elevator=cfq showopts initrd (hd0,0)/boot/initrd ###Don’t change this comment - YaST2 identifier: Original name: floppy### title Floppy root (fd0) chainloader +1 ###Don’t change this comment - YaST2 identifier: Original name: failsafe### title Failsafe kernel (hd0,0)/boot/vmlinuz root=/dev/sda1 showopts ide=nodma apm=off acpi=off vga=normal noresume selinux=0 barrier=off nosmp noapic maxcpus=0 3 initrd (hd0,0)/boot/initrd
Grub is different from LILO in that the information in the file is interpreted dynamically as the machine is being booted. This has the benefit of allowing new kernels to be quickly added to the system. The Grub menu.lst file can be updated with any text editor, and unlike LILO, no further steps are necessary to make the option available at boot time. Additional information on GRUB can be found in the man pages or at the GRUB home page at http://www.gnu.org/software/grub/grub.html.
An additional feature available through Grub is the capability to modify the menu entries. Pressing Esc when the graphical Grub menu is present triggers Grub to offer the ncurses version of the boot menu. In this version of the menu, you can edit individual lines controlling the kernel parameters. Instructions on how to do this are provided at the bottom of the boot option screen, as shown in Figure 3.1.
)
Figure 3.1 GRUB edit options available a boot time.
One of the benefits of this option is that you can boot directly into single user mode. In the case of a machine going down for an unknown reason, you can carefully bring up the system in single user mode by dynamically editing the kernel line and adding the word single to the end of the line. Boot the system at this point, and you will have a minimally booted environment in which you can perform some diagnostics before trying to bring up the whole system.
Of course, this extra flexibility is also a double-edged sword. Individuals with access to the system can also modify the kernel parameters during the boot sequence. Securing the console should mitigate against this exposure. This can be done through configuring the BIOS, GRUB, or both to require a password at boot time. This approach must be balanced against the physical security of the server and the requirements of having the machine in service. A power failure or unexpected reboot with these options configured would leave the server unable to boot until manual intervention was provided.