Search all pages
Professions, Sciences, Humanities, Business, ...
Text-based, GUI, Audio, Video, Keyboards, Mouse, Images,...
Conversions, tests, processing, manipulation,...
Integer, Floating point, Matrix, Statistics, Boolean, ...
Algorithms, Memory, Process control, Debugging, ...
Data storage, Integrity, Encryption, Compression, ...
Networks, protocols, Interprocess, Remote, Client Server, ...
Timing, Calendar and Clock, Audio, Video, Printer, Controls...
Management, Filtering, File & Directory access, Viewers, ...
RocketLink!--> Man page versions:
BOOT(8) OpenBSD System Manager's Manual (I386 Architecture) BOOT(8)
boot - system bootstrapping procedures
Power fail and crash recovery. Normally, the system will reboot itself at
power-up or after crashes. An automatic consistency check of the file
systems will be performed, and unless this fails, the system will resume
Cold starts. The PC AT clones will perform a POST (Power On Self Test)
upon being booted cold. This test will find and initialize memory, key-
board, and other devices. It will search for and initialize any exten-
sion ROMs that are present, and then attempt to boot the operating system
from an available boot drive. Failing this, older IBM systems came up in
The newer PC AT clones attempt to boot off the drive specified in the
BIOS setup, or if it is an older BIOS, it will start with checking for a
disk in floppy drive A (otherwise known as drive 0) first, and failing
that, attempt to boot the hard disk C (otherwise known as hard disk con-
troller 1, drive 0).
Warm starts. The BIOS loads the first block (at physical location: track
0, head 0, sector 1) off the boot device into memory, and if the last two
bytes in the block match the signature 0x55AA, the BIOS considers the
block a valid bootable drive. The BIOS then proceeds to call the machine
code program in this block. If the BIOS is current, it will also pass
the boot drive to the boot block in register %dl.
There are two different types of boot blocks on devices. There is the
MBR (master boot record), and the PBR (partition boot record). A digres-
sion into a little piece of history will quickly give light as to why
this is so. In the beginning, the PC ``architecture'' came with a single
or dual floppy drives, and no hard drives. The only type of bootable
sectors on any device were the PBRs. They were responsible for loading
the rest of the operating system from the right device. When hard disks
came out, it was felt that such a huge space should be able to be parti-
tioned into separate drives, and this is where the MBR was invented.
The MBR relocates itself upon being loaded and invoked by the BIOS. Em-
beded within the MBR is a partition table, with four partitions table en-
tries. The MBR code traverses this table (which was loaded with the MBR
by the BIOS), looking for an active entry, and then loads the MBR or PBR
from the disk location specified by the partition table entry. So in all
reality, the MBR is nothing more than a fancy chaining PBR.
Note: The MBR could load another MBR, which is the case when you are
booting off an extended partition. In other words, the first block of an
extended partition is really an MBR, which will then load the correspond-
ing MBR or PBR out of its extended partition's partition table.
WARNING: This portion of the ``PC BIOS Architecture'' is a mess, and a
The PC BIOS has an API to manipulate any disk that the BIOS happens to
support. This interface uses 10 bits to address the cylinder, 8 bits to
address the head, and 6 bits to address the sector of a drive. This re-
stricts any application using the BIOS to being able to address only 1024
cylinders, 256 heads, and 63 (since the sectors are 1 based) sectors on a
disk. These limitations proved to be fine for roughly 3 years after the
debut of hard disks on PC computers.
Many (if not all) newer drives have many more cylinders than the BIOS API
can support, and likely more sectors per track as well. To allow the
BIOS the ability of accessing these large drives, the BIOS would ``re-
map'' the cylinder/head/sector of the real drive geometry into something
that would allow the applications using the BIOS to access a larger por-
tion of the drive, still using the restricted BIOS API.
The reason this has become a problem, is that any modern OS will use its
own drivers to access the disk drive, bypassing the BIOS completely.
However, the MBR, PBR, and partition tables are all still written using
the original BIOS access methods. This is for backwards compatibility to
the original IBM PC!
So the gist of it is, the MBR, PBR, and partition table need to have BIOS
geometry offsets and cylinder/head/sector values for them to be able to
load any type of operating system. This geometry can, and likely will,
change whenever you move a disk from machine to machine, or from con-
troller to controller. They are controller and machine specific.
/bsd system code
/usr/mdec/mbr system MBR image
/usr/mdec/biosboot system primary stage bootstrap (PBR)
/boot system second stage bootstrap
halt(8), reboot(8), shutdown(8), installboot(8), boot(8)
The ``PC BIOS Architecture'' makes this process very prone to weird and
wonderfull interactions between differing operating systems. There is no
published standard to the MBR and PBR, which makes coding these a night-
mare. Somebody *please* write me a decent BIOS, and make them (the mass-
es) use it!
OpenBSD 2.3 September 4, 1997 2
Source: OpenBSD 2.6 man pages. Copyright: Portions are copyrighted by BERKELEY
SOFTWARE DESIGN, INC., The Regents of the University of California, Massachusetts
Institute of Technology, Free Software Foundation, FreeBSD Inc., and others.
(Corrections, notes, and links courtesy of RocketAware.com)
FreeBSD Sources for boot_i386(8)
RocketLink!--> Man page versions:
Search | About | Comments | Submit Path: RocketAware > man pages >
RocketAware.com is a service of Mib Software
Copyright 1999, Forrest J. Cavalier III. All Rights Reserved.
We welcome submissions and comments