Booting Process in Linux and Windows
Booting Process in Linux and Windows
Booting Process in Linux and Windows
GROUP NUMBER: 22
Booting Process In Linux and Windows
S/ NAMES MARTRICULE
N
1 Elroy Ankelmbom Kimbi UBA19E0168
Yonghabichia
2 Nogho Tidang Belviane Uba19E0337
Title
This assignment is focused on what happens from the moment a system is powered up to the
time a login prompt is available. Those are the fundamentals of the boot process. When an
Operating System is properly installed, the BIOS/UEFI points to a specific media device.
Assuming it’s a local hard drive, the master boot record (MBR) of that device points to the boot-
loader. Once an option to boot the OS(es) is selected in the boot-loader, it loads the OS into
RAM. The boot-loader focuses on loading and starting the boot time tasks and processes found
within the operating system.
2. The second is the Basic Input/Output System (BIOS), which is stored in flash memory on
the motherboard. The central processing unit (CPU) in an embedded system invokes the
reset vector to start a program at a known address in flash/ROM. The boot block is
always at track 0, cylinder 0, head 0 of the boot device. Here is tested the boot medium
(hard disk, floppy unit, CD-ROM's). The loader from a ROM loads the boot sector
(block), which in turn loads the operating system from the active partition. This block
contains the Grub (GNU GRand Unified Boot Loader) for LINUX, which boots the
operating system. This boot loader is less than 512 bytes in length (a single sector), and
its job is to load the second-stage boot loader GRUB. The boot configuration is
grub.conf. Grub is installed at the MBR (Master Boot Record), or at the first sector of
the active partition loading the operating system.
3. When a boot device is found, the first-stage boot loader is loaded into RAM and
executed. The primary boot loader that resides in the MBR is a 512-byte image
containing both program code and a small partition table. The first 446 bytes are the
primary boot loader, which contains both executable code and error message text. The
next sixty-four bytes are the partition table, which contains a record for each of four
partitions (sixteen bytes each). The MBR ends with two bytes that are defined as the
magic number. The magic number serves as a validation check of the MBR. The job of
the primary boot loader is to find and load the secondary boot loader (stage 2). It does
this by looking through the partition table for an active partition. When it finds an active
partition, it scans the remaining partitions in the table to ensure that they’re all inactive.
When this is verified, the active partition’s boot record is read from the device into RAM
and executed. A master boot record (MBR), or partition sector, is the 512-byte boot
sector that is the first sector ("LBA/absolute sector 0") of a partitioned data storage
device such as a hard disk. (The boot sector of a non-partitioned device is a volume boot
record. These are usually different, although it is possible to create a record that acts as
both; it is called a multi-boot record). The MBR may be used for one or more of the
following:
Uniquely identifying individual disk media, with a 32-bit disk signature; even though it
may never be used by the machine the disk is running on.
Due to the broad popularity of IBM PC-compatible computers, this type of MBR is widely
used, to the extent of being supported by and incorporated into other computer types
including newer cross-platform standards for bootstrapping and partitioning.
od -xa mbr.bin
4. The secondary, or second-stage, boot loader could be more aptly called the kernel
loader The task at this stage is to load the Linux kernel and optional initial RAM disk
(initrd). The second-stage boot loader is in RAM and executed a splash screen is
commonly displayed, and Linux and an optional initial RAM disk (temporary root file
system) are loaded into memory. When the images are loaded, the second-stage boot
loader passes control to the kernel image and the kernel is decompressed and
initialized. At this stage, the second-stage boot loader checks the system hardware,
enumerates the attached hardware devices, mounts the root device, and then loads the
necessary kernel modules.
From the GRUB command-line, you can boot a specific kernel with a named initrd image
as follows:
grub> boot
If you don’t know the name of the kernel to boot, just type a forward slash (/) and press
the Tab key. GRUB will display the list of kernels and initrd images.
The compressed Linux kernel is compressed is located in /boot and contains a small bit
of code which will decompress it and load it into memory.
5. After locating standard devices using initrd and verifying video capability, the kernel
verifies hardware configuration (floppy drive, hard disk, network adapters, etc),
configures the drivers for the system displaying messages on screen and system log.
During the boot of the kernel, the initial-RAM disk (initrd) that was loaded into memory
by the stage 2 boot loader is copied into RAM and mounted. This initrd serves as a
temporary root file system in RAM and allows the kernel to fully boot without having to
mount any physical disks. Since the necessary modules needed to interface with
peripherals can be part of the initrd, the kernel can be very small, but still support a
large number of possible hardware configurations. After the kernel is booted, the root
file system is pivoted where the initrd root file system is unmounted and the real root
file system is mounted.
The initrd function allows you to create a small Linux kernel with drivers compiled as
loadable modules. These loadable modules give the kernel the means to access disks
and the file systems on those disks, as well as drivers for other hardware assets.
Because the root file system is a file system on a disk, the initrd function provides a
means of bootstrapping to gain access to the disk and mount the real root file system.
6. The kernel tries to mount the file-systems from /etc/fstab and the system files. The
location of system files is configurable during recompilation, or with other programs –
LiLo and rdev. The file system type is automatically detected from the partition table
(commonly ext2 and ext3 in LINUX). If the mount fails, a so-called kernel panic will
occur, and the system will “freeze”.