Transcript Hard-Disk Partitions

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 16byte 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.
The code in volume boot records is invoked either directly by the
machine's firmware or indirectly by an MBR or a boot manager.
ROM BIOS
MBR
VBR
Grand Unified Bootloader
(GRUB)
REF:
http://www.pixelbeat.org/docs/disk/
1
2
3
4
Consider the hard-disk
layout with 4 partitions for
a Linux distribution
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/hda
dd 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.