CODEWITHSUNDEEP
unixbootbootloader
Neha Somani
Neha Somani

Reputation: 112

On what parameters boot sequence varies?

Does every Unix flavor have same boot sequence code ? I mean there are different kernel version releases going on for different flavors, so is there possibility of different code for boot sequence once kernel is loaded? Or they keep their boot sequence (or code) common always?

Edit: I want to know into detail how boot process is done.

  1. Where does MBR finds a GRUB? How this information is stored? Is it by default hard-coded?

  2. Is there any block level partion architecture available for boot sequence?

  3. How GRUB locates the kernel image? Is it common space, where kernel image is stored?

I searched a lot on web; but it shows common architecture BIOS -> MBR -> GRUB -> Kernel -> Init.

I want to know details of everything. What should I do to know this all? Is there any way I could debug boot process?

Thanks in advance!

Upvotes: 0

Views: 114

Answers (1)

Matteo Italia
Matteo Italia

Reputation: 126867

First of all, the boot process is extremely platform and kernel dependent.

The point is normally getting the kernel image loaded somewhere in memory and run it, but details may differ:

  • where do I get the kernel image? (file on a partition? fixed offset on the device? should I just map a device in memory?)
  • what should be loaded? (only a "core" image? also a ramdisk with additional data?)
  • where should it be loaded? Is additional initialization (CPU/MMU status, device initialization, ...) required?
  • are there kernel parameters to pass? Where should they be put for the kernel to see?
  • where is the configuration for the bootloader itself stored (hard-coded, files on a partition, ...)? How to load the additional modules? (bootloaders like GRUB are actually small OSes by themselves)

Different bootloaders and OSes may do this stuff differently. The "UNIX-like" bit is not relevant, an OS starts being ostensibly UNIXy (POSIX syscalls, init process, POSIX userland,...) mostly after the kernel starts running.

Even on common x86 PCs the start differs deeply between "traditional BIOS" and UEFI mode (in this last case, the UEFI itself can load and start the kernel, without additional bootloaders being involved).

Coming down to the start of a modern Linux distribution on x86 in BIOS mode with GRUB2, the basic idea is to quickly get up and running a system which can deal with "normal" PC abstractions (disk partitions, files on filesystems, ...), keeping at minimum the code that has to deal with hardcoded disk offsets.

  1. GRUB is not a monolithic program, but it's composed in stages. When booting, the BIOS loads and executes the code stored in the MBR, which is the first stage of GRUB. Since the amount of code that can be stored there is extremely limited (few hundred bytes), all this code does is to act as a trampoline for the next GRUB stage (somehow, it "boots GRUB");
  2. the MBR code contains hard-coded the address of the first sector of the "core image"; this, in turn, contains the code to load the rest of the "core image" from disk (again, hard-coded as a list of disk sectors);
  3. Once the core image is loaded, the ugly work is done, since the GRUB core image normally contains basic file system drivers, so it can load additional configuration and modules from regular files on the boot partition;

  4. Now what happens depends on the configuration of the specific boot entry; for booting Linux, usually there are two files involved: the kernel image and the initrd:

    • initrd contains the "initial ramdrive", containing the barebones userland mounted as / in the early boot process (before the kernel has mounted the filesystems); it mostly contains device detection helpers, device drivers, filesystem drivers, ... to allow the kernel to be able to load on demand the code needed to mount the "real" root partition;
    • the kernel image is a (usually compressed) executable image in some format, which contains the actual kernel code; the bootloader extracts it in memory (following some rules), puts the kernel parameters and initrd memory position in some memory location and then jumps to the kernel entrypoint, whence the kernel takes over the boot process;

  5. From there, the "real" Linux boot process starts, which normally involves loading device drivers, starting init, mounting disks and so on.

Again, this is all (x86, BIOS, Linux, GRUB2)-specific; points 1-2 are different on architectures without an MBR, and are are skipped completely if GRUB is loaded straight from UEFI; 1-3 are different/avoided if UEFI (or some other loader) is used to load directly the kernel image. The initrd thing may be not involved if the kernel image already bundles all that is needed to start (typical of embedded images); details of points 4-5 are different for different OSes (although the basic idea is usually similar). And, on embedded machines the kernel may be placed directly at a "magic" location that is automatically mapped in memory and run at start.

Upvotes: 2

Related Questions