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. BIOS BOOT DEVICES Many modern BIOSes allow for a number of boot devices. It is important to ensure that the boot volume for your SUSE server be identified as the first boot device following the install process. This prevents a driver floppy or CD from booting your server into an unknown state in the event of an unscheduled restart. "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. PASSWORDS AND SYSTEM RESTARTS Passwords can be applied at several levels within a computer. Most modern servers allow for passwords at the BIOS level to prevent unauthorized modification of parameters such as the boot device sequence. This is excellent if you want to prevent someone with physical access to a machine from booting an alternate operating system from removable media. The downside is that you then have another password to keep track of in your disaster recovery password file (see Chapter 10, "Data Backup and Disaster Recovery"). Another level of password protection is available with both boot loaders distributed with SUSE LINUX. This level prevents the selection and execution of a boot process until the proper password is entered. Used in conjunction with the BIOS password, this level offers an attractive protection against a quick local intrusion into the system. On the downside: This level of password protection will not stop a local attacker with a screwdriver from resetting the BIOS and removing the password. If this is achieved, booting off additional media could lead to a password bypass on the rest of the disk subsystem. Also, having a password on the boot loader will keep the system from rebooting in the case of an unscheduled restart. This may or may not be an attractive feature at 2 a.m. As always, physical security is a must. If an intruder has access to the machine for an extended period of time, password security, to a first approximation, is moot. 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. LILOThe 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
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[View full width] # 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 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. GrubThe 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. NOTE LILO can be used to boot a system from a floppy if the kernel is also present on the same floppy. LILO requires a map file to locate the kernel it wishes to boot from. Because the kernel location is not necessarily constant from floppy to floppy, if the boot loader on the primary hard drive is used, the map file stored on the hard drive may not point to the appropriate location should the incorrect floppy be entered in the drive. GRUB, on the other hand, does not require a map file. Pointing a boot configuration to a known good kernel on a floppy is therefore possible. Though this is technically possible, you might want to wonder about the validity of doing this. Starting a system from an incorrect kernel could yield disastrous results. Booting from an up-to-date rescue floppy would be the only scenario in which this should be considered acceptable. Listing 3.2. Grub menu.lst[View full width] # 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 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. |
noapic maxcpus=0 3" image = /boot/memtest.bin label = Memory_Test optional append = "" 
EAN: 2147483647
Pages: 134