Inside the Linux boot process (2006)(ibm.com)
ibm.com
Inside the Linux boot process (2006)
https://www.ibm.com/developerworks/library/l-linuxboot/
31 comments
I appreciate the article is from 2006, but it would be nice to see a similar write up for recent EFI-based machines and maybe other architectures, as well.
I just did a lot of reading about EFI to get my system booting again, so I'll write a bit about it. Cunningham's law and all that.
On system startup, the CPU begins executing from the EFI ROM - a few-megabyte chip on the motherboard somewhere. The EFI is essentially a simple (won't say small) OS: it can enumerate devices and partitions, mount filesystems, draw graphics, and connect to the internet (shudder). It provides APIs for these capabilities to the loaded EFI executables. EFIs are either 32-bit or 64-bit so its boot code must switch from real mode at some point.
After handling whatever system initialization, the EFI looks through the connected disks in the order configured by the user, searching for an EFI system partition. This partition is FAT32 and has a special GPT partition attribute to mark it. These partitions are usually 100-500MB and are usually the first partition on the disk. If found, the EFI mounts this partition.
At this point, the boot process depends on the value of various EFI variables, which you can inspect with the `efivar` command on linux. These instruct the EFI bootloader to load various EFI executables, which are PE-format but otherwise fairly normal. First it will load any drivers specified by the `Driver####` and `DriverOrder` variables, which could be used to enable the EFI bootloader to load from e.g. a RAID controller or a BTRFS partition. I haven't seen this used in practice, however. Next it will run an executable specified by a `Boot####` variable, depending on the `BootNext` or `BootOrder` variables or a user-selection at the EFI boot menu. These EFI applications are stored in vendor-specific directories of the EFI system partition like `/EFI/Fedora/shimx64.efi`. These applications are usually either an EFI shim which executes a traditional bootloader, or a traditional bootloader compiled as an EFI application. EFI could also be used to directly boot a kernel, such as linux compiled with EFISTUB enabled.
If the EFI isn't able to boot any of the registered entries, it will usually run the EFI Shell (if installed) or try to run whatever is at `/EFI/BOOT/bootx64.efi`.
On system startup, the CPU begins executing from the EFI ROM - a few-megabyte chip on the motherboard somewhere. The EFI is essentially a simple (won't say small) OS: it can enumerate devices and partitions, mount filesystems, draw graphics, and connect to the internet (shudder). It provides APIs for these capabilities to the loaded EFI executables. EFIs are either 32-bit or 64-bit so its boot code must switch from real mode at some point.
After handling whatever system initialization, the EFI looks through the connected disks in the order configured by the user, searching for an EFI system partition. This partition is FAT32 and has a special GPT partition attribute to mark it. These partitions are usually 100-500MB and are usually the first partition on the disk. If found, the EFI mounts this partition.
At this point, the boot process depends on the value of various EFI variables, which you can inspect with the `efivar` command on linux. These instruct the EFI bootloader to load various EFI executables, which are PE-format but otherwise fairly normal. First it will load any drivers specified by the `Driver####` and `DriverOrder` variables, which could be used to enable the EFI bootloader to load from e.g. a RAID controller or a BTRFS partition. I haven't seen this used in practice, however. Next it will run an executable specified by a `Boot####` variable, depending on the `BootNext` or `BootOrder` variables or a user-selection at the EFI boot menu. These EFI applications are stored in vendor-specific directories of the EFI system partition like `/EFI/Fedora/shimx64.efi`. These applications are usually either an EFI shim which executes a traditional bootloader, or a traditional bootloader compiled as an EFI application. EFI could also be used to directly boot a kernel, such as linux compiled with EFISTUB enabled.
If the EFI isn't able to boot any of the registered entries, it will usually run the EFI Shell (if installed) or try to run whatever is at `/EFI/BOOT/bootx64.efi`.
You made an incorrect assumption about real mode.
* https://superuser.com/a/345333/38062
* https://superuser.com/a/345333/38062
Well you could start with http://jdebp.eu./FGA/efi-boot-process.html .
How difficult would it be to register the dependencies of the boot process, and only run the full boot process when those dependencies have been touched, using a generated and quickly loadable binary image otherwise?
Windows does something similar. https://www.howtogeek.com/243901/the-pros-and-cons-of-window...
I think most of the boot process is initializing hardware, so I don't see how you avoid it.
How come recovering from hibernation is much faster then?
My (perhaps overly simple) conclusion is that the boot process is doing stuff it doesn't need to do.
My (perhaps overly simple) conclusion is that the boot process is doing stuff it doesn't need to do.
recovering from hibernation is much faster then?
Is it? Not in my experience running Debian.
Although, hibernation does have the advantage for magnetic disks of being a single file that can be read sequentially, rather than a bunch of files scattered throughout the disk. But I believe certain tools can help with that, by profiling and optimizing those accesses at boot time.
Is it? Not in my experience running Debian.
Although, hibernation does have the advantage for magnetic disks of being a single file that can be read sequentially, rather than a bunch of files scattered throughout the disk. But I believe certain tools can help with that, by profiling and optimizing those accesses at boot time.
The boot process does hardware detection and configuration, while resuming from hibernate basically involves nothing more than writing the last-saved configuration back to the hardware. It's relying on the assumption that the hardware hasn't changed since it was last hibernated.
> It's relying on the assumption that the hardware hasn't changed since it was last hibernated.
Which is also true in 99% of cases when I boot.
Which is also true in 99% of cases when I boot.
This could be related to that the applications on the OS left running when you hibernated do not need to start from scratch.
Because a hibernated machine is still powered on. So you're correct in a way, the "boot process" from hibernation does skip a lot of things.
Problem is, you can't utilize those shortcuts when doing a completely cold boot. Like another commenter said, in that case most of the boot time is preparing hardware.
Problem is, you can't utilize those shortcuts when doing a completely cold boot. Like another commenter said, in that case most of the boot time is preparing hardware.
No, a hibernated machine is powered off, you're thinking of standby. Hibernation dumps a memory image to disk which is then loaded on next boot. As laptop standby power modes has gotten much better, and memory sizes bigger, hibernation seems to have fallen out of fashion.
Parent seems to confuse two different kinds of boot. The one discussed in the article concerns itself with getting the OS loaded and beginning to execute that. Traditionally, this is where booting ends. But you OS still needs to do a lot of work, starting services, loading widgets and helpers and Bonzi Buddy etc. It's perhaps debatable if this can still be considered part of the boot process, since the OS is loaded and executing user space code, but it's certainly part of the startup process. I believe this is the process parent is referring to.
Parent seems to confuse two different kinds of boot. The one discussed in the article concerns itself with getting the OS loaded and beginning to execute that. Traditionally, this is where booting ends. But you OS still needs to do a lot of work, starting services, loading widgets and helpers and Bonzi Buddy etc. It's perhaps debatable if this can still be considered part of the boot process, since the OS is loaded and executing user space code, but it's certainly part of the startup process. I believe this is the process parent is referring to.
I'm sorry but the article has very little to do with the actual boot process of modern distributions.
I run modern distributions and it describes at a high level the way my dual boot (and modern) laptop works. Not everyone uses EFI and systemd or Windows.
The comments on that article look like they've been mangled at some point in the past!
It's like bash gone wild, look at one of the links they actually work
http:\/\/tldp.org\/HOWTO\/Bootdisk-HOWTO\
Edit: I'm using Firefox
http:\/\/tldp.org\/HOWTO\/Bootdisk-HOWTO\
Edit: I'm using Firefox
article is from 2006