*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->OpenBSD man pages -> i386/boot_i386 (8)              



NAME    [Toc]    [Back]

     boot_i386 - i386 system bootstrapping procedures

DESCRIPTION    [Toc]    [Back]

   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,
keyboard, and
     other devices.  It will search for and initialize any extension ROMs that
     are  present,  and then attempt to boot the operating system
from an available
 boot drive.  Failing this, older IBM systems come 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 controller
 1, drive 0).

   Warm starts    [Toc]    [Back]
     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 0xAA55, 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 digression
 into a little piece of history will quickly give  light
as to why
     this  is so.  In the beginning, the PC ``architecture'' came
with single
     or dual floppy drives, and no hard drives.  The only type of
     sectors  on any device were the PBRs.  They were responsible
for loading
     the rest of the operating system from  the  correct  device.
When hard
     disks came out, it was felt that such a huge space should be
able to be
     partitioned into separate drives, and this is when  the  MBR
was invented.

     The  MBR  relocates  itself upon being loaded and invoked by
the BIOS.  Embedded
 within the MBR is a partition table, with four partition table entries.
   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 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 corresponding
  MBR  or  PBR  out of its extended partition's partition

   Geometry translation    [Toc]    [Back]
     WARNING: This portion of the ``PC BIOS Architecture''  is  a
mess, and a
     compatibility nightmare.

     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 restricts
 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
     can support, and likely more sectors per track as well.   To
allow the
     BIOS  the  ability of accessing these large drives, the BIOS
would ``remap''
 the cylinder/head/sector of the  real  drive  geometry
into something
     that would allow the applications using the BIOS to access a
larger portion
 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
     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 controller
 to controller.   They  are  controller  and  machine

   Boot process options    [Toc]    [Back]
     On  most OpenBSD systems, booting OpenBSD from the BIOS will
     load the i386 bootstrapping code.  This versatile program is
described in
     a  separate document, boot(8).  Other bootstrapping software
may be used,
     and can chain-load the OpenBSD bootstrapping  code,  or  directly load the
     kernel.   In the latter case, refer to your bootloader documentation to
     know which options are available.

   Abnormal system termination    [Toc]    [Back]
     In case of system crashes, the kernel will usually enter the
kernel debugger,
  ddb(4),  unless it is not present in the kernel, or
it is disabled
     via the ddb.panic sysctl.  Upon leaving ddb, or if  ddb  was
not entered,
     the  kernel  will  halt the system if it was still in device
     phase, or attempt a dump to the configured dump  device,  if
possible.  The
     crash  dump will then be recovered by savecore(8) during the
next multiuser
 boot cycle.  It is also possible  to  force  other  behaviours from ddb.

FILES    [Toc]    [Back]

     /bsd                default system kernel
     /usr/mdec/mbr       system MBR image
     /usr/mdec/biosboot  system primary stage bootstrap (PBR)
     /usr/mdec/boot       system  second stage bootstrap (usually
also installed
                         as /boot)
     /usr/mdec/pxeboot   PXE bootstrap

SEE ALSO    [Toc]    [Back]

     ddb(4),  boot(8),  halt(8),  init(8),  installboot(8),  pxeboot(8), reboot(8),
     savecore(8), shutdown(8)

BUGS    [Toc]    [Back]

     The  ``PC  BIOS Architecture'' makes this process very prone
to weird and
     wonderful interactions between different operating  systems.

     There  is  no  published  standard to the MBR and PBR, which
makes coding
     these a nightmare.

OpenBSD     3.6                        September     4,      1997
[ Back ]
 Similar pages
Name OS Title
boot FreeBSD system bootstrapping procedures
boot_i386 FreeBSD system bootstrapping procedures
boot_mvme68k OpenBSD mvme68k system bootstrapping procedures
boot_alpha OpenBSD Alpha system bootstrapping procedures
boot_sparc OpenBSD sparc system bootstrapping procedures
boot_vax OpenBSD vax-specific system bootstrapping procedures
boot_amd64 OpenBSD amd64 system bootstrapping procedures
boot_cats OpenBSD CATS system bootstrapping procedures
boot_hppa OpenBSD hppa system bootstrapping procedures
boot_sparc64 OpenBSD sparc64 system bootstrapping procedures
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service