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 »
Ubuntu 12 boot process explained I’ve been trying to convert my existing Ubuntu 12.04 server (running this website) to RAID1 for various reasons. Throughout the process, I’ve 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.
Contact Creations Hire
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)
[email protected]
Subscribe
Step 1: hardware to software This first step is the part that seems like magic to a lot of people, possibly because it’s 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 BIOS’s 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 doesn’t 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 we’re 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 kernel’s (deprecated) initrd system (see “External initram fs im ages“). So the /initrd.img is named like an initrd archive, but it’s 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 they’re running. If you’ve ever used the service command or edited anything under /etc/init.d, you’ve 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 MBR’s to UEFI and GPT’s. BIOS and MBR’s 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 don’t 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 MBR’s and UEFI was designed for GPT’s, 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 it’s so mystical is because there’s 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 wasn’t (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 that’s ever used LILO will understand how powerful today’s 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 won’t 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
0
Leave a message...
Discussion
Com m unity
Share
#
No one has commented yet.
r
C o m m e n t fe e d
m
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
