boot_amd64



BOOT_AMD64(8)       OpenBSD System Manager's Manual (AMD64)      BOOT_AMD64(8)


NAME

     boot_amd64 - amd64 system bootstrapping procedures


DESCRIPTION

   Cold starts
     The Athlon64 computers and 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.

     The boot drive is usually specified in the BIOS setup.

   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 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
     bootable 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 table.

   Geometry translation
     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 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 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 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
     controller to controller.  They are controller and machine specific.

   Boot process options
     On most OpenBSD systems, booting OpenBSD from the BIOS will eventually
     load the OpenBSD-specific amd64 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
     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
     configuration 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 multi-user boot cycle.  It is also possible to force other
     behaviours from ddb.


FILES

     /bsd                default system kernel
     /bsd.sp             single processor capable kernel
     /bsd.mp             multiprocessor capable kernel
     /bsd.rd             standalone installation kernel, suitable for disaster
                         recovery
     /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

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


BUGS

     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 5.4                     April 20, 2011                     OpenBSD 5.4

[Unix Hosting | Open-Source | Contact Us]
[Engineering & Automation | Software Development | Server Applications]