Processo de Startup do Linux

Notas do Editor

1. Firmware usually has provisions for loading some fixed, small amount of code. In the Intel world, that’s a 512 byte “boot sector”. Even the Linux hackers can’t fit an operating system into 512 bytes! The game is to load a series of increasingly larger and more capable code segments. The two-stage process seems sufficient, in theory. The first fixed-length piece of code loads a larger, arbitrary length code segment. Due to other constraints, it is often convenient to “bootstrap” a more capable loader which can then load the final target (or another, more capable loader). By “hardware bootstrap” I mean the mechanism that loads the first bit of code, the primary. Some authors just use the term “bootstrap”. Even if the firmware can boot your kernel directly, it is convenient to interpose a software loader for additional flexibility. Updating firmware is not easy when you need to do something slightly differently. Updating a software loader is much easier.
2. When you power-on the Intel, it reads a “start address” from location 0xfffffff0 and jumps to that location. In the standard PC configuration, this address is the BIOS entry point. Strangely, the location 0xfffffff0 is also part of BIOS (the high 64K of memory). This indirect mechanism allows Intel chips to be used in non-PC settings. Everything happens in real-mode so some memory mapping tricks are used to make the high BIOS addresses reachable in real-mode. After executing the POST, BIOS enters the bootstrap interrupt handler and tries to load a boot sector using the BIOS-defined order. For a floppy, BIOS always loads the first sector. For a hard disk, the first sector which is a Master Boot Record (MBR or mboot) containing some code and a partition table are loaded. The loaded code searches the partition table for the active (bootable) partition. If the MBR is from the active partition we are done. If the active partition is some other partition, the MBR code loads the boot sector of that partition. This is sometimes referred to as a partition boot sector or pboot. There are further complications for extended and logical partitions. Eventually the “correct” boot sector is loaded. Each boot sector contains a “magic number” to verify that it is, indeed, a boot sector. If the magic number is verified, then the boot sector code is executed.
3. The “map installer” is controlled by the text file lilo.conf which identifies the desired boot scenario and details available boot images. Rerun /sbin/lilo anytime boot-related files change! That includes lilo.conf, the kernel itself, the boot loaders, the disk partition structure, etc. Newer versions of LILO keep most files in /boot by default. Under RedHat 6.1 the compressed kernel image is called vmlinuz. The actual primary and secondary bootloaders (the “real” LILO) live in the file /boot/boot.b. You can generate your own if you are clever enough but most people use the supplied loaders. Certain boot scenarios require loading additional loaders (for example, to boot off a logical partition). LILO supports this via the concept of a “chain loader”. The default chain loader is available as /boot/chain.b. The file /boot/map contains the actual sector map with a variety of other information. See the Technical Overview for details. Finally, the /boot directory may also contain an initial ramdisk image (initrd) used during boot.