Hard-Disk Partitions

Ref: Wikipedia

What and Why

• Disk partitioning – The creation of logical divisions upon a hard

disk that allows one to apply operating system-specific logical formatting.

• Within a partition, – a file system may be created for the storage

of files, – or a partition may be used for other purposes,

such as swap space

Benefits• Partitioning makes it possible to create several file systems (either

of the same type or different) on a single hard disk. • This has many benefits, including:

– The use of multi-booting setups, which allow users to have more than one operating system on a single computer.

– Sharing swap partitions between multiple Linux distributions, so such partitions use less hard drive space.

– Protecting or isolating files, to make it easier to recover a corrupted file system or operating system installation.

– Raising overall computer performance because smaller filesystems are more efficient.

• For instance, large hard drives with only one NTFS filesystem typically have a very large Master File Table (MFT) and it generally takes more time to read this MFT than the smaller MFTs of smaller partitions.

– Higher levels of data organization, raising the user efficiency of the system,

• for example separate partitions dedicated to digital movie processing, photos, email mailboxes or browser cache.

PC BIOS partition types

• Partitions as used in PC compatible computer systems– For example Microsoft Windows and Linux

• Technically, a hard disk should contain – as many as four primary partitions, – or one to three primaries along with a single

extended partition.

• Each of these partitions are described by a 16-byte entry in the Partition Table – which is located in the Master Boot Record.

A Master Boot Record (MBR)

• The 512-byte boot sector that is the first sector ("Sector 0") of a partitioned data storage device such as a hard disk.

The MBR may be used for one or more of the following:• Holding a disk's primary partition table. • Bootstrapping operating systems,

•after the computer's BIOS passes execution to machine code instructions contained within the MBR.

• Uniquely identifying individual disk media, •Using a 32-bit disk signature; even though it may never be used by the machine the disk is running on

The "type" of a partition is identified by a 1-byte code found in its partition table entry.

Some of these codes (such as 0x05 and 0x0F) may be used to indicate the presence of an extended partition, but most are used by operating systems that examine partition tables to decide if a partition contains a file system they can mount/access for reading or writing data.

Partition Types

• A primary (or logical) partition contains one file system. – The "partition type" code for a primary or logical

partition can either correspond • to a file system contained within (e.g. 0x07 means either an

NTFS or an OS/2 HPFS file system) • or indicate the partition has a special use (e.g. code 0x82

usually indicates a Linux swap partition).

• An extended partition is secondary to the primary partition(s). – A hard disk may contain only one extended partition;

which can then be sub-divided into logical drives

Booting

Paradox

• The two figures are rearrangements of each other, with the corresponding triangles and polyominoes having the same areas.

• Nevertheless, the bottom figure has an area one unit larger than the top figure (as indicated by the grid square containing the dot).

http://mathworld.wolfram.com/TriangleDissectionParadox.html

Paradox

• When a computer is first powered on, it doesn't have an operating system in memory.

• The computer's hardware alone cannot perform complex actions such as loading a program from disk.

• So an apparent paradox exists: – to load the operating system into memory,

one appears to need to have an operating system already loaded.

The solution• The solution is to use a special small program,

– called a bootstrap loader, bootstrap or boot loader. • This program's only job is to load other software for the operating

system to start.

• Often, multiple-stage boot loaders are used, in which several small programs of increasing complexity sequentially summon one after the other, until the last of them loads the operating system.

• Boot loaders may face peculiar constraints, especially in size; for instance, on the IBM PC and compatibles, the first stage of boot loaders located on hard drives must fit into the first 446 bytes of the Master Boot Record, in order to leave room for the 64-byte partition table and the 2-byte 0xAA55 'signature', which the BIOS requires for a proper boot loader

MBRs, VBRs and system bootstrapping

• On IA-32 IBM PC compatible machines using the MBR Partition Table scheme, the bootstrapping firmware, contained within the ROM BIOS, loads and executes the master boot record. – Because the i386 family of processors boot up in real mode,

the code in the MBR is: real mode machine language instructions.

• This code in the MBR normally passes control by chain loading the Volume Boot Record of the active (primary) partition,

– although some boot managers replace that conventional code with their own [e.g. GRUB].

• Volume Boot Record– Volume Boot Record contains code for booting programs

(usually, but not necessarily, operating systems) stored in other parts of the volume

– On partitioned devices, it is the first sector of an individual partition on the device [the first sector of the entire device instead being a Master Boot Record (MBR)].

– On non-partitioned storage devices, it is the first sector of the device.

ROM BIOS

MBR

VBR

The code in volume boot records is invoked either directly by the machine's firmware or indirectly by an MBR or a boot manager.

Grand Unified Bootloader (GRUB)

REF: http://www.pixelbeat.org/docs/disk/

Consider the hard-disk layout with 4 partitions for a Linux distribution1 2 3 4

Concentrate on the expanded region

We’ll examine its structure and how GRUB fits in.

Note the structure is the same for windows systems, only the content (grub) is different.

MBR

• The first sector (512 bytes) is the MBR and consists of, – 446 bytes bootloader, – 64 bytes partition table and a – 2 byte signature (0xAA55). – It get its name because it is the first boot record that

is loaded, which can then load other boot records from various locations on the disk.

– NOTE: In Linux you can get a hex-dump a hexdump of this first sector of the disk

• # dd bs=512 count=1 if=/dev/hda | od -Ax -tx1z -v – (changing /dev/hda as appropriate for your setup):

The DOS compatibility region

This region is optional as far as linux is concerned at least, but is added by default by most partition managers. It is 63 sectors (32,256 bytes).

GRUB uses this region to store its stage 1.5, which is filesystem specific code used to find the operating system image on the "boot" filesystem.

GRUB uses this region to store its stage 1.5, which is filesystem specific code used to find the operating system image on the "boot" filesystem. Currently GRUB does not need all this space as can be seen for the copies of all the stage 1.5 files in the boot partition

Therefore one could theoretically use the last 44 sectors of this region (22,528 bytes) for anything. There is no point in creating a filesystem in here as the overhead would be too much, but you could dd stuff in and out like:dd bs=512 seek=20 count=44 if=myfile of=/dev/hdadd bs=512 skip=20 count=44 if=/dev/hda of=myfile

GRUB 1 boot process• GRUB or the GRand Unified Bootloader is the

usual bootloader used on linux systems, and resides on the system as described above. The boot process with GRUB is as follows:

– BIOS code reads MBR from a disk (looks at last 2 bytes to verify if MBR).

– Starts executing bootloader code (GRUB stage 1). – Bootloader jumps to location (sector num) of next

stage. This sector num is stored at a particular location in the bootloader "code" at GRUB install time and usually points to a stage 1.5 located in the "DOS compat space" immediately after the MBR.

– Stage 1.5 knows about the boot filesystem so it opens the filesystem on the specified (at install time) partition. It looks for the stage 2 executable here and executes it.

• Note since stage 1.5 knows about the boot filesystem it gives much greater flexibility in upgrading stage 2 and the kernel etc. as their new locations don't need to be written to the earlier GRUB stages.

Stage 2• Stage 2 contains most of the GRUB logic. • It loads the menu.lst file and executes the statements, usually providing a

menu to the user etc.

• Subsequent steps are distro specific this describe a fedora linux distribution:

• When GRUB starts booting one of the entries, it reads the initial ramdisk and starts the kernel running telling it about the ramdisk.

• In the initial ramdisk, the nash shell is run to parse the /linuxrc file. It essentially finds the location of the filesystem it itself is on and passes that to the kernel as its root filesystem. This allows for greater flexibility of the devices the kernel resides on.

• The kernel reads its root filesystem and executes /bin/init by default. This in turn parses /etc/inittab which usually sets up the login consoles and starts executing the scripts in /etc/init.d

• These scripts start various subsystems, culminating in starting X. X in turn starts the display manager which gives a login prompt.

New GRUB

• GRUB 2 boot process• The structure of GRUB has changed quite a bit with

version 2, (which is still in development at the time of writing).

• Instead of stage 1, stage 1.5 and stage 2 images it has a collection of modules that can be combined in different ways.

• To mirror the functionality the original GRUB's stages as described, you would have for example: – stage 1 = boot.img– stage 1.5 = diskboot.img+kernel.img+pc.mod+ext2.mod (the

core image)– stage 2 = normal.mod+_chain.mod

The boot process for GRUB 2• BIOS code reads MBR from a disk (looks at last 2 bytes to verify if

MBR). • Starts executing bootloader code (boot.img). • This loads the first sector of the core image (diskboot.img), whose

location was stored at a particular location in boot.img at GRUB install time and usually points to the core image located in the "DOS compat space" immediately after the MBR. diskboot.img in turn loads and executes the rest of the core image.

• These core image modules know about the boot filesystem and can open the filesystem on the specified (at install time) partition. It looks for and loads modules there, including normal.mod

• normal.mod loads the grub.cfg file and executes the statements, usually providing a menu to the user etc.

• This is a more flexible mechanism. For example one can prepend pxeboot.img to the core image instead of diskboot.img. This will then load the whole core image from the network and then start executing kernel.img.