2/19/13

Ubuntu 12 boot process explained

Johntron

Python, PHP, Zend, Django, Mobile, and Linux web development guru About
Effe c t ive Gr ap h Layo u t

Contact Creations Hire

Ubuntu 12 boot process explained

Ive been trying to convert my existing Ubuntu 12.04 server (running this website) to RAID1 for various reasons. Throughout the process, Ive learned a ton about the Linux boot process (aka bootstrapping), and realized a high-level explanation would really help other developers like myself. What follows is a starting place for anyone trying to recover a Linux system or do something other than a default install the nitty gritty can be found elsewhere.

A d v i c e (11) C ommuni c at i on (2) Ec onomi c s (1) Hac ki ng (1) M ob i le (2) P r ogr ammi ng (6) S EO (1) S t r at egy (1) Ut i li t i es (1)

you@email.com

Subscribe

Step 1: hardware to software

This first step is the part that seems like magic to a lot of people, possibly because its something that just happens and is very difficult to debug when things go wrong due to a general lack of information. Once power is applied, a motherboard initializes a Basic Input/Output System (BIOS). The BIOS performs some basic tests of the hardware (POST), then looks to the boot device (usually a hard drive) with the highest priority to see what to do next. Please note, newer hardware uses something called the Unified Extensible Firmware Interface. I will not be covering UEFI, but some crucial information is included below.

Step 2: BIOS to bootloader

The BIOSs ultimate goal is to transfer control to some higher-level system. The BIOS looks at the beginning of devices (highest-priority first) until it finds a Master Boot Record (MBR) and attempts to launch any bootloader it finds.
johntron.com/hacking/ubuntu-12-boot-process-explained/ 1/5

2/19/13

Ubuntu 12 boot process explained

Unfortunately, for historical reasons the MBR is very small and GRUB doesnt fit into such a small space. For this reason, GRUB places boot.im g in the MBR which simply jumps to the location on disk immediately after the MBR (called the postMBR gap) from which the rest of GRUB ( core.im g ) is loaded. At this point we are presented with the GRUB menu.

Step 3: Bootloader to kernel

Once GRUB is up and running it decompresses and loads the Linux kernel from the path specified by the linux command typically /vmlinuz or some variation. The kernel is able to (eventually) get us a user space to do the things we really care about, but were not quite done with GRUB. The Linux kernel is responsible for initializing devices and preparing the system for use by the OS. A kernel that supports every device out there would necessarily be massive. To keep the kernel small and platform agnostic, a pluggable architecture is used. The kernel can load other modules to accomplish its goals. So where are these modules located? In a compressed archive called initramfs! So where is initramfs? Ubuntu 12.10 relies on GRUB to inject initramfs into the kernel (see initrd ). This approach uses the kernels (deprecated) initrd system (see External initram fs im ages ). So the /initrd.img is named like an initrd archive, but its really a initramfs archive.

Step 4: kernel to init

Now that the kernel is up and running and has access to any modules it might need, it sets up core components of the system then transfers control to the first userspace process, /init (located in initramfs). /init is simply a shell script that overwrites the temporary filesystem mounted by the kernel with the root filesystem used by the OS. The last action taken by /init (the shell script) is to launch the init (the daemon). The init daemon is located at /sbin/init on Ubuntu and acts as the direct- or indirect-parent process of all other processes. Ubuntu uses its own version of init referred to as upstart . In addition to acting as a primordial ancestor, upstart also launches Ubuntu services configured to start at boot, kills services when necessary, and supervises them while theyre running. If youve ever used the service command or edited anything under /etc/init.d, youve dealt with upstart.

Failure conditions

johntron.com/hacking/ubuntu-12-boot-process-explained/

2/5

2/19/13

Ubuntu 12 boot process explained

BIOS/MBR vs. (U)EFI/GPT

Manufacturers and OS distributions are currently transitioning from BIOS and MBRs to UEFI and GPTs. BIOS and MBRs were not built with 2TB hard drives in mind similarly to 32-bit systems with lots of RAM, they simply cannot access (address) these large drives because they simply dont have the vocabulary. The Unified Extensible Firm ware Interface (previously known as simply EFI, but people united and we now call it UEFI) and GUID Partition Table (GPT) format were created to address this limitation (and others). UEFI is a protocol describing how hardware and software should communicate. This means a (U)EFI motherboard will require a UEFI image (bootlooader) and OS that understands UEFI (Windows does). Older hardware can be made to use UEFI images by essentially bootstrapping UEFI from BIOS (think BIOS -> MBR -> UEFI). Conversely, many UEFI images include legacy support for BIOS (Windows 7 for instance), so they can work on older hardware. The specification for the GPT format is a subset of the UEFI specification. While GPT and UEFI are closely intertwined, hardware and software created during the BIOS-to-UEFI transitory period often provides legacy support for BIOS and MBR. When building a system, be sure to check if your OS will work with your motherboard. Some BIOS motherboards can be upgraded (by flashing the ROM) to use UEFI, and some include support for both UEFI and BIOS, this is not always the case (and will probably not be the case in the near future). If your motherboard cannot do UEFI, make sure your OS includes legacy support for BIOS. Similarly, even though BIOS was designed to use MBRs and UEFI was designed for GPTs, BIOS systems can be configured to use the MBR to bootstrap EFI/GPT this does
johntron.com/hacking/ubuntu-12-boot-process-explained/ 3/5

2/19/13

Ubuntu 12 boot process explained

not mean that UEFI systems can use GPT to bootstrap BIOS/MBR!

Does it have to be so confusing?

I was struck by the complexity of the bootup process was and wondered why it had been designed this way. I understand how transistors work, how they are combined to create a binary system, how binary operations are organized into an instruction set, how an instruction set is used by a compiler to provide high-level programming languages, and how high-level programming languages are used to describe tasks for the hardware to perform. Still, the boot process seemed like a mystical magical thing that ends with a command prompt when things go well and the impression of a keyboard on my forehead when things go wrong. I think part of the reason its so mystical is because theres so many moving pieces. Transistors, binary, and instruction sets are each pretty simple, so why was the bootup process designed to be so complex? The short answer is it wasnt (designed). The complexity is the result of shoehorning newer functionality into an old design. I wonder if early systems had something like GRUB and also how hard they to recover from disaster. Anyone thats ever used LILO will understand how powerful todays bootloaders and kernels are. While this extra complexity is confusing it provides certain niceties like allowing us to load GRUB modules at runtime so we can access disparate filesystems. Interestingly, it is possible to compile a very small version of the Linux kernel that will fit in the MBR and act as the bootloader. While this eliminates the need for GRUB altogether, this type of setup will probably not include the disaster recovery that GRUB provides, and a more robust system would probably just use UEFI hardware and a recent version of the Linux kernel. In the future systems will be even more powerful but also more intuitive. BIOS and MBR are currently deprecated and are being replaced by UEFI and GPT which are much simpler to setup and provide more functionality. In the future boot sectors will not be required at the beginning of disks. While chainloading (using a bootloader to bootstrap another bootloader) will still be possible, it wont be necessary, so GRUB initialization may become a single-stage process. Even though GRUB now provides UEFI support for newer hardware, the Linux kernel has had native UEFI support since version 3.3 (Ubuntu 12.10 comes with version 3.5). Someday, GRUB will probably be obsolete; however, it looks like reality it will even m ore com plex thanks to Microsoft .

Useful links
In sid e t h e Lin u x b o o t p r o c e ss Lin u x st ar t u p p r o c e ss Th e syst e m in it ializat io n B o o t P r o c e ss Ho w t o fix Lin u x b o o t p r o b le ms HO WTO : B o o t & In st all U b u n t u fr o m t h e Gr u b Re sc u e P r o mp t Ho w c an I c h an ge /c o n ve r t a U b u n t u M B R d r ive t o a GP T, an d make U b u n t u b o o t fr o m EFI? GP T vs M B R GP T Exp lain e d Ke r n e l P ar ame t e r s

johntron.com/hacking/ubuntu-12-boot-process-explained/

4/5

2/19/13

Ubuntu 12 boot process explained

This entry was posted on Sunday, January 6th, 2013 at 1:54 am and is filed under hacking . You can follow any responses to this entry through the RSS 2.0 feed. You can leave a respo nse , or t rackback from your own site.

0 comments
Leave a message...

Com m unity Share

Discussion

No one has commented yet.

C o m m e n t fe e d

Su b s cri b e vi a e m a i l

2010 J ohn S y r i nek R S S Dog f or C hr i st mas

johntron.com/hacking/ubuntu-12-boot-process-explained/

5/5