Chapter 17: Managing and Understanding the Boot Procedure

Goal

Sommaire

Boot process

Booting Steps

1. Au boot le BIOS exécute le MBR (Master Boot Record) situé sur le premier secteur (512 octets) du support bootable choisi (disque, CD, clef USB, ...)
2. Le MBR scanne le disque pour trouver la partition bootable (flag)
3. Le MBR lance le boot loader (chargeur de démarrage) du secteur de boot (premier secteur) de la partition bootable
4. Le bootloader charge le noyau en mémoire et l'exécute
5. Le bootloader charge le ramdisk initrd.img en mémoire
6. 2 bootloader possibles:
   - Lilo (Linux Loader)
   - Grub (Grand Unified Bootloader)
   
7. Une fois le noyau chargé en mémoire, il lance le premier processus /bin/init
8. init est le père de tous les autres processus qui seront créés par l'appel system fork()
9. init lit le fichier /etc/inittab pour savoir :
   - quel est le fichier à exécuter pour continuer le chargement du système
   - quel est le runlevel (niveau d'exécution) par défault
   - comment lancer les services pour un runlevel donné
   

Grand Unified Bootloader (GRUB)

Grand Unified Bootloader (GRUB)

Settings

Boot files

commands

protect boot configuration access

add an OS entry

During the boot process, everything is logged to the /var/log/dmesg file. You can also use the dmesg command to query information about the boot process after the system has booted. When the system’s drivers are in place, the kernel executes the /sbin/init program.

The init program is the first process created by the kernel. It is responsible for the rest of the boot process and setting up the environment for the user. First, it consults the /etc/inittab file, which defines how the rest of the boot process will go. The /etc/inittab file lists the default runlevel to boot into and the system initialization script (/etc/rc.d/rc.sysinit). I describe what a runlevel is and how it is used later in this chapter. Let’s look at the /etc/inittab file to see what the init process goes through:

Grub

Files and Directories

Understanding GRUB 2

The GRUB 2 boot loader makes sure that you can boot Linux. GRUB 2 is installed in the boot sector of your server’s hard drive and is configured to load a Linux kernel and the initramfs:

■ The kernel is the heart of the operating system, allowing users to interact with the hardware that is installed in the server.

■ The initramfs contains drivers that are needed to start your server. It contains a mini file system that is mounted during boot. In it are kernel modules that are needed during the rest of the boot process (for example, the LVM modules and SCSI modules for accessing disks that are not supported by default).

Normally, GRUB 2 works just fine and does not need much maintenance. In some cases, though, you might have to change its configuration. To apply changes to the GRUB 2 configuration, the starting point is the /etc/default/grub file. In this file, you’ll find options that tell GRUB what to do and how to do it.

Apart from the configuration in /etc/default/grub, there are a few configuration files in /etc/grub.d. In these files, you’ll find rather complicated shell code that tells GRUB what to load and how to load it. You typically do not have to modify it. You also will not need to modify anything if you want to make it possible to select from different kernels while booting. GRUB 2 picks up new kernels automatically and adds them to the boot menu automatically, so nothing has to be added manually.

Based on the configuration files mentioned previously, the main configuration file / boot/grub2/grub.cfg is created. Even if this looks like a configuration file that can be manually modified, you should never do that, because it will get overwritten at some point. This will happen, for instance, after updating the kernel. The RPM from which the kernel is updated will run a post-installation script that regenerates

Modifying Default GRUB 2 Boot Options

To apply modifications to the GRUB 2 boot loader, the file /etc/default/grub is your entry point; do not change the contents of the /boot/grub2/grub.cfg configuration file directly.

The most important line in this file is GRUB_CMDLINE_LINUX, which defines how the Linux kernel should be started.

In this line, you can apply permanent fixes to the GRUB 2 configuration. Some likely candidates for removal are the options rhgb and quiet . These options tell the kernel to hide all output while booting. That is nice to hide confusing messages for end users, but if you are a server administrator, you probably just want to remove these options.

Kickstart

Kickstart

Kickstart installation steps

Create a Kickstart configuration file

The system-config-kickstart utility presents a number of graphical dialog boxes, takes inputs from the user, then creates a text file with Kickstart directives that correspond to the user's choices. Each dialog box corresponds to a category of questions as ked by the Red Hat installer, Anaconda . Optionally, an existing configuration file can be passed as an argument and system-config-kickstart will use it to populate values for configuration options. system-config-kickstart is provided by the system-config-kickstart package.

Creating a Kickstart configuration file from scratch with a text editor is rare. The Anaconda installer creates a file called /root/anaconda-ks.cfg that contains the Kickstart directives that can be used to generate the freshly installed system . This file makes a good starting point when creating a Kickstart configuration file with a text editor.

ksvalidator is a utility that checks for syntax errors in a Kickstart configuration file. It will ensure keywords and options are properly used, but it will not validate URL paths, individual packages, or groups, nor any part of %post or %pre scripts. For instance, if the firewall - - disabled directive is misspelled, ksvalidator could produce one of the following errors:

Publish the Kickstart configuration file to Anaconda

The installer must be able to access the Kickstart file to begin an automated installation. Although there are several methods to make the Kickstart configuration file available, the most common is through a network server such as an FTP server, a web server, or an NFS server. Network servers facilitate Kickstart file maintenance because changes only need to be made once and take effect immediately. Providing Kickstart files on USB or CD-ROM is a not her convenient way to publish configuration files. The Kickstart configuration file is embedded on the boot media used to start the installation. When changes a remade , new installation media must be generated. It is possible to provide the Kickstart file on a local disk. This allows a quick way to rebuild a development server.

Boot Anaconda and point it to the Kickstart

For virtual machine installations using the Virtual Machine Manager or virt-manager, the Kickstart URL can be specified in a box under URL Options.