MirBSD manpage: boot_i386(8)

BOOT_I386(8)             BSD System Manager's Manual              BOOT_I386(8)


     boot_i386 - i386 system bootstrapping procedures


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 avail-
     able boot drive. Failing this, older IBM systems come up in ROM BASIC.

     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 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. Em-
     bedded within the MBR is a partition table, with four partition 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
     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.

Geometry translation

     WARNING: This portion of the "PC BIOS Architecture" is a mess, and a com-
     patibility 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 res-
     tricts 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. How-
     ever, 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.

Boot process options

     On most OpenBSD systems, booting OpenBSD from the BIOS will eventually
     load the OpenBSD-specific 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

     In case of system crashes, the kernel will usually enter the kernel de-
     bugger, 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.


     /bsd                default system kernel
     /bsd.mp             multi-processor capable kernel
     /bsd.rd             standalone installation kernel, suitable for disaster
     /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, also known as ldbsd.com or pxeboot)


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


     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. There are published standards to PXE and El Torito,
     which makes coding these a nightmare. (This is not a contradiction,
     although the abyss between specification and implementation is much worse
     with ACPI.)

MirBSD #10-current            September 4, 1997                              1

Generated on 2022-12-24 01:00:14 by $MirOS: src/scripts/roff2htm,v 1.113 2022/12/21 23:14:31 tg Exp $ — This product includes material provided by mirabilos.

These manual pages and other documentation are copyrighted by their respective writers; their sources are available at the project’s CVSweb, AnonCVS and other mirrors. The rest is Copyright © 2002–2022 MirBSD.

This manual page’s HTML representation is supposed to be valid XHTML/1.1; if not, please send a bug report — diffs preferred.

Kontakt / Impressum & Datenschutzerklärung