Logical structure

  • Partitioning is the creation of logical drives (that hold data) on a disk.
  • Partitions can be primary or extended (IDE legacy).
  • Partitions can be hidden. Newer OS's do that for reasons of being able to rewrite or reinstall the OS. And so can adversaries. If there is a difference between the physical size of a disk and the space used by the partitions, time to investigate what else is on there.
  • The Master Boot Record (MBR) resides in the first (zero) sector of a data storage device and contains the Master boot code and the Master Partition Table holding information about each partition formatted on the HD.
  • The Boot Sector is the sector of a storage device containing the code for bootstrapping (starting up) a system. It can be a volume boot record or a master boot record. It is always the first sector of the first track and contains a program that loads the rest of the OS in RAM. In Unix it is called the superblock. Each valid boot sector has two bytes (0x55AA), a boot sector signature, at the end of the sector.
  • The BIOS is used to initiate the Power-On Self Test (POST). The POST initialises all of the hardware:
    • Initialises keyboard and other system hardware.
    • It used to count RAM but this is often no longer done, what with the huge amounts of RAM common today, and because most RAM is ECC capable RAM it is no longer needed.
    • Checks disk drives
    • Attempts to find a valid OS
  • The Boot Loader is the program that loads the OS in memory. A multiple stage boot loader is a number of small programs calling each other and the last one loads the OS.

  • The system clock generates a series of clock ticks that initialise the CPU. A detailed example: Booting an Intel Architecture System, Part I: Early Initialization
  • The CPU searches the ROM BIOS for the first instruction of the start-up program.
  • The first instruction is to run the POST and determine the memory addresses.
  • POST checks the BIOS chip and the CMOS RAM (system date, time and setup parameters)
  • If no battery failure, POST checks the functioning of the hardware devices in its inventory and initialises the CPU. If all is well, that completes POST.
  • The BIOS looks into CMOS to find the drive where the OS is installed.
  • The BIOS checks the boot record of the drive to find the beginning of the OS and its initialisation file.
  • BIOS initialises the OS and copies its own files into memory.
  • The OS takes over.
  • The OS performs yet another inventory of system memory and availabilities and loads the necessary (peripheral) device drivers.
  • BIOS loads and executes the MBR boot loader.
  • MBR loads and executes the GRUB boot loader (or LILO in old systems).
    • MBR is located in the 1st sector of the bootable disk, typically /dev/hda, or /dev/sda.
    • It is less than 512 bytes in size and has three components
      • primary boot loader info in 1st 446 bytes
      • partition table info in next 64 bytes
      • mbr validation check in last 2 bytes.
  • The Grand Unified Bootloader (GRUB) loads and executes Kernel and initrd images. Initial RAM Disk (initrd) is used by the kernel as temporary root file system until the kernel is fully booted and the real root file system is mounted. It also contains the necessary drivers to access the hard drive partitions and other hardware.
    • GRUB displays a splash screen. With multiple kernel images installed, users can choose which one is to be executed. GRUB waits for few seconds, if no choice is made, it loads the default kernel image as specified in the grub configuration file /boot/grub/grub.cfg. The /etc/default/grub file contains customisations.
    • GRUB has knowledge of the filesystem (LILO did not).
  • The kernel mounts the root file system as specified in root= in the GRUB configuration file.
  • The kernel executes the /sbin/init program. Because init is the first program to be executed by the kernel, it has Process ID (PID) 1. As of Debian jessie, the boot process switches its default init to systemd for event-driven and parallel initialisation.
  • Init or systemd looks at system file(s) (differs per distro) to determine the required Linux runlevel and loads the associated runlevel programs.
    • 0 – Halt
    • 1 – Single user mode
    • 2, 3 – Multi-user modes
    • 4 – Unused
    • 5 – X11
    • 6 – Reboot

Roughly speaking:

  • The POST checks whether all hardware is working fine.
  • The bootstrap loader code is invoked to load the bootmgr file.
  • The MBR is accessed.
  • The boot loader boot.ini is started.
  • The complete kernel is loaded along with the login screen.

In detail:

Although it has a Linux kernel, the boot process is nothing like other Unix systems, and is based on the BSD Darwin engine. During single-user boot, the following things happen:

  • The firmware (either BIOS or EFI) initializes the hardware.
    • On BIOS machines, the screen is black and shows white text during this process.
    • On EFI machines, the screen is gray and shows nothing during this process (this applies to Intel Macs, other EFI machines might have other implementations).
  • The boot loader is loaded by the firmware.
    • On BIOS machines, boot is loaded and a boot-132 message is shown.
    • On EFI machines, efiboot is loaded and an Apple logo but no spinner is shown (this applies to Intel Macs, other EFI machines might have other implementations).
  • The boot loader reads /Library/Preferences/SystemConfiguration/com.apple.Boot.plist
    • If the file is not present, the boot loader prints an error message.
  • The boot loader loads XNU and the kernel extensions (kexts).
    • On BIOS machines, a spinning star or a list of kexts being loaded is shown.
    • On EFI machines, an Apple logo but no spinner is shown (this applies to Intel Macs, other EFI machines might have other implementations)
  • XNU is loaded.
    • If the essential KEXTs (especially the Platform Expert, which is in AppleACPIPlatform.kext) were loaded successfully as well, the kernel starts and prints a copyright message mentioning University of California at Berkeley.
  • XNU loads KEXTs (for the first time; those with OSBundleRequired set to “Root”) and waits for the root device.
    • If the root device can be accessed using the available kexts, the kernel prints the message “Got root device”; at some point thereafter the rest of the KEXTs are loaded (those without OSBundleRequired set to “Root”).
    • If the root device cannot be accessed using the available kexts, the message reads “Still waiting for root device…” instead.
  • The kernel starts /sbin/launchd on the root device.
  • launchd starts /bin/launchctl.
  • launchctl starts /bin/bash.