Introduction In this article, we’ll take a closer look at the booting process of the Linux operating system. We’ve already described the booting process in this article, especially how the system boots if the system partition is encrypted. Let’s take a look again at the same picture that was presented in that article: We can see from the picture that the booting process starts from the MBR (Master Boot Record), but actually, the booting process begins with the BIOS and continues from there. It’s the BIOS’s job to tell the computer which hard drives are available and to try to search for an active MBR record in the primary hard drive. The MBR record then tells the booting process where the /boot partition is located. Afterwards, the /boot partition is read and examined for any boot loader, which in our case is GRUB. At that point, the booting of a computer is handed to the GRUB boot loader, which loads the grub.conf file and the kernel of the Linux system and then mounts the root partition, which in this case is /dev/sda3. The execution continues with the kernel image located on the /boot partition. The kernel is loaded and the execution is handed over to the Gentoo init process (with a PID number 1), which is already located on the system partition and is responsible for starting the entire system. The init process takes care of everything the system needs to boot up successfully. One of the things it does is to start the required scripts, usually located in the /etc/rc.d/ directory. It must also mount the partitions that are listed in the /etc/fstab configuration file. Once everything is done, the login window appears, allowing us to log in to our operating system.[1] We’ve described the process of booting the Linux operating system only, but it’s quite the same for other operating systems too. In the next part of the article, we’ll take a look at more details regarding the booting process but only at what happens until the operating system itself gains control and does its thing. This way, we’ll eliminate the need to explain the booting process of every single operating system, because each and every OS does things differently and we’re not interested in those at the moment. BIOS and the MBR First, we must be aware that the majority of computers have something called the BIOS that begins the initial booting process right after we turn on the computer. But why do we even need BIOS? The reason is that the boot loader is located on a hard drive we have in our machine, and right upon turning on the computer, the processor doesn’t know anything about the boot loader being available on the hard drive. It’s the BIOS’s job to find and load the boot loader installed on the hard drive. We all know that when we turn on the computer, the BIOS first scans for devices, determines the amount of memory available, etc. After that, the BIOS must scan for bootable devices as configured in the BIOS settings, in that order. Typically, the BIOS finds the hard drive that contains the MBR (Master Boot Record), which must also contain the primary boot loader code. When the BIOS finds the MBR record, it passes control to the primary boot loader. The primary boot loader must then scan the partition table that is also written in the MBR record and find the active partition, which contains the secondary boot loader. Let’s first dump the MBR in Linux and check its contents. To do that, we must copy the first sector of the disk to the mbr.bin file with the dd command like this:
Now we can use the all-powerful file command to display the contents of the MBR in a more readable format. We could read the hex bytes directly, but why should we? Note that we’ve used the tr command only to replace all the ‘;’ characters with the new line characters to make the output easier to read:
We can see that the MBR image has knowledge of three partitions, which have the ID of 0x83 that identifies them as ext3 file system. We can see that none of the partitions is marked as active partitions, but that isn’t absolutely necessary for the system to boot successfully (my system boots fine without this). But let’s mark the first partition as bootable with the fdisk command:
We’ve entered the p command in the fdisk to display all the partitions. We can see from the output that none of the partitions is currently active. After that, we used the a command to mark the first partition as active and printed the partitions again. This time, the first partition contains the ‘*’ character in the output in the second column, which means that that partition is currently active. At the end, we also have to enter the w command to save the changes we’ve just made to the MBR sector. Now we need to reboot the system for the changes to take effect. After rebooting, we should dump the contents of the MBR sector again and print them with the file command. The contents of the MBR are shown below:
We can see that the first partition is the active partition. We’ve identified that the MBR contains the first boot loader as well as the partition table, which is very important information since, without it, the operating system cannot boot. The job of the BIOS is to identify the first bootable device that contains the MBR record and pass control to the primary boot loader, who must then determine which partition is active and load the secondary boot loader from that partition. The structure of the normal MBR record is as follows (the picture was taken from [3]): You can see that the first boot loader takes the first 446 bytes of the 512-byte MBR, which is 88% of the size. There are also four partition entries, which clearly gives us the idea why we can only set up four primary partitions in any partition editor. If we want to set up more partitions, we have to use logical partitions. The MBR entry also ends with the boot signature 0x55aa, as we can see on the picture above. Let’s dump the contents of the mbr.bin file we’ve dumped previously:
Notice that the signature of the MBR is indeed 0x55aa at the end of the dump. The secondary boot loader is often GRUB or LILO for Linux and Bootmgr for Windows. Their job is to load the kernel and boot the operating system. The primary boot loader searches for the active partition and loads its VBR (Volume Boot Record) into memory. The VBR is a boot sector that contains the machine code for bootstrapping programs, usually operating systems stored in other parts of the device.[2] It’s also often the case that we install the GRUB or LILO boot loader directly into the MBR, because if we don’t, the BIOS still needs a primary boot loader that loads the secondary one. But why shouldn’t we install GRUB directly in the MBR as the primary boot loader instead? This is actually the default way that GRUB/LILO is installed today. Let’s take a look at how we would install GRUB to be the primary and secondary boot loader. To install Grub as the primary boot loader, therefore on the MBR, we should run the following:
But if we would like to install Grub on the VBR of a partition /dev/sda1, we should run the following:
Let’s also take a look at the contents of the /boot/grub/ folder, which are listed below:
This gives us a clear indication that the boot loader must also support the file system that the system is using. In our case, since we’re using ext3 file system, GRUB should be able to support it, because it must mount it and pass control to the operating system. GRUB supports the following file systems: ext2, DOS FAT16, FAT32, FFS, JFS, ReiserFS, MinixFS, UFS, XFS, VstaFS and Iso9660. Conclusion We’ve taken a look at how GRUB boots the Linux operating system, but we’ve also reviewed the role the BIOS has in the whole picture. We’ve seen that the BIOS is pretty important when it comes to booting the primary boot loader, as without it, it wouldn’t be possible to boot the operating system from the hard drive in normal computers. References: [1] Dejan Lukan, LUKS: Swap, Root and Boot Partitions, accessible at http://resources./luks-swap-root-boot-partitions/. [2] Volume boot record, accessible at http://en./wiki/Volume_boot_record. [3] Master boot record, accessible at http://en./wiki/Master_boot_record.
|
|
来自: astrotycoon > 《boot》