Master boot record

From Wikipedia, the free encyclopedia

Structure of a Master Boot Record

Address			Description		Size in bytes
Hex	Oct	Dec
0000	0000	0	Code Area		max. 440
01B8	0670	440	Optional Disk signature		4
01BC	0674	444	Usually Nulls; 0x0000		2
01BE	0676	446	Table of primary partitions (Four 16-byte entries, IBM Partition Table scheme)		64
01FE	0776	510	55h	MBR signature; 0xAA55[1]	2
01FF	0777	511	AAh
MBR, total size: 446 + 64 + 2 =					512

A Master Boot Record (MBR), or partition sector, is the 512-byte boot sector that is the first sector ("Sector 0") of a partitioned data storage device such as a hard disk. (The boot sector of a non-partitioned device is a Volume Boot Record, these are usually different, although it is possible to create a record that acts as both; it is called Multi Boot Record.) The MBR may be used for one or more of the following:

• Holding a disk's primary partition table.^[2]
• Bootstrapping operating systems, after the computer's BIOS passes execution to machine code instructions contained within the MBR.
• Uniquely identifying individual disk media, with a 32-bit disk signature; even though it may never be used by the machine the disk is running on.^[1][2][3][4]

Due to the broad popularity of IBM PC-compatible computers, this type of MBR is widely used, to the extent of being supported by, and incorporated into, other computer types, including newer cross-platform standards for bootstrapping and partitioning.^{[citation needed]}

Contents 1 MBRs and disk partitioning 2 MBRs and system bootstrapping 3 MBRs and disk identity 4 Programming Considerations 5 Differences in MBR Code 6 Editing/replacing MBR Contents 7 Backing up/restoring the MBR 7.1 DR-DOS 7.2 MS-DOS and Windows 7.3 Unix-like systems 8 Re-creating a lost partition table 9 Footnotes 10 References 11 Further reading 12 See also 13 External links

[edit] MBRs and disk partitioning

Layout of one 16-byte partition record

Offset	Description
0x00	(1 byte) Status[3] (0x80 = bootable, 0x00 = non-bootable, other = malformed[4])
0x01	(3 bytes) Cylinder-head-sector address of the first sector in the partition[5]
0x04	(1 byte) Partition type[5]
0x05	(3 bytes) Cylinder-head-sector address of the last sector in the partition[6]
0x08	(4 bytes) Logical block address of the first sector in the partition
0x0C	(4 bytes) Length of the partition, in sectors

The MBR is not located in a partition, it is located at the Main Boot Record area in front of the first Partition.

Where a data storage device has been partitioned with (what Microsoft terms) the MBR Partition Table scheme (i.e., the conventional IBM PC partitioning scheme), the master boot record contains the primary partition entries in its partition table. The partition table entries for other, secondary, partitions are stored in Extended Boot Records, BSD disklabels, and Logical Disk Manager metadata partitions that are described by those primary entries.^[6]

By convention, there are exactly four primary partition table entries in the MBR Partition Table scheme, although some DOS operating systems did extend this to five (PTS-DOS)^[7] or even eight (AST or NEC DOS)^[8][9] entries.

Where a data storage device has been partitioned with the GUID Partition Table scheme, the Master Boot Record will still contain a partition table, but its only purpose is to indicate the existence of the GUID Table and to prevent utility programs that only understand the MBR Partition Table scheme from creating any partitions in what they would see as only free space on the disk.

[edit] MBRs 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 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.

The conventional MBR code expects the MBR Partition Table scheme to have been used, and scans the list of (primary) partition entries in its embedded partition table to find the only one that is marked with the active flag. It then loads and runs the Volume Boot Record for that partition. (Thus the master boot record, like other boot sectors, is a target for boot-sector infecting computer viruses. See boot sector.)

The MBR replacement code in some boot managers can perform a variety of tasks, and what those tasks are varies from boot manager to boot manager. In some, for example, it loads the remainder of the boot manager code from the first track of the disk, which it assumes to be "free" space that is not allocated to any disk partition, and executes it. In others, it uses a table of embedded disk locations to locate the remainder of the boot manager code to load and to execute. (Both approaches have problems. The first relies on behavior that is not universal across all disk partitioning utilities. The second requires that the embedded list of disk locations be updated when changes are made that would relocate the remainder of the code.)

On machines that do not use IA-32 processors, and on machines that use Extensible Firmware Interface (EFI) firmware, this design is unsuitable, and the MBR is not used as part of the system bootstrap. On the latter, the firmware is instead capable of directly understanding the GPT partitioning scheme and the FAT filesystem format, and loads and runs programs held as files in the EFI System Partition. The MBR will only be involved insofar as it might contain the partition table if the MBR Partition Table scheme has been used.

There are some MBR replacement code, that emulates EFI firmware's bootstrap, which makes non-EFI machines capable of booting from GPT partitioning scheme. (Typical example is Multi Boot Record, which can be used as MBR and as Volume Boot Record in the bootstrap process, hence the name. It detects GPT table and loads the EFI compatible code from disk to complete this task.)

[edit] MBRs and disk identity

In addition to the bootstrap code and a partition table, master boot records may contain a Windows NT disk signature. This is a 32-bit value that is intended to uniquely identify the disk medium (as opposed to the disk unit — the two not necessarily being the same for removable hard disks).

The disk signature was introduced by Windows NT version 3.5, but is now used by several operating systems, including the Linux kernel version 2.6 and later. Linux uses the NT disk signature at boot time to determine the location of the boot volume.^[10]

Windows NT (and later Microsoft operating systems) use the disk signature as an index to all the partitions on any disk ever connected to the computer under that OS; these signatures are kept in Registry keys, primarily for storing the persistent mappings between disk partitions and drive letters. It may also be used in boot.ini files (though most do not), to describe the location of bootable Windows NT (or later) partitions.^[11] One key (among many) where NT disk signatures appear in a Windows 2000/XP Registry is:

HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices

If a disk's signature stored in the MBR were A8 E1 B9 D2 (in that order) and its first partition corresponded with logical drive C: under Windows, then the REG_BINARY data under the key value, \DosDevices\C:, would be:

A8 E1 B9 D2 00 7E 00 00 00 00 00 00

The first four bytes are said disk signature. (Note: In other keys, these bytes may appear in reverse order from that found in the MBR sector.) These are followed by eight more bytes, forming a 64-bit Integer, in little endian notation, which are used to locate the byte offset of this partition. In this case, 00 7E corresponds to the hexadecimal value 0x7E00 (32,256dec). Dividing this byte offset by 512 (size of a hard disk's physical sector in bytes) results in 63, which is the physical sector number (or LBA) containing the first block of the partition (^[7]).

If this disk had another partition with the values 00 F8 93 71 02 following the disk signature (under, e.g., the key value \DosDevices\D:), it would begin at byte offset 0x27193f800 (10,495,457,280dec), which is also the first byte of physical Sector 20,498,940.

[edit] Programming Considerations

Assume that the system being programmed uses the BIOS MBR scheme, as stated above, and the system BIOS locates a valid MBR on a partitioned drive in its boot sequence. As stated above, conventional MBR code loads and runs the operating-system-dependent Volume Boot Record (or bootloader) code that is located at the beginning of the disk's "active" partition. The MBR can simply assume that the one active partition on the current drive is supposed to boot, or alternately, it can be programmed as a Dual boot MBR. A dual boot MBR must interact with the user to determine which partition on which drive should boot, and may transfer control to the MBR of a different drive.

The BIOS will load the first valid MBR that it finds into hexadecimal physical address 0x7c00, and jump to that address. Some of the end of the 512 byte sector is preallocated for the partition table and other information (see above), so the MBR program must be tiny enough to fit within 440 bytes of memory. The MBR program may communicate with the user, examine the partition table, or perform some housekeeping tasks such as enabling the A20 line, or changing to Unreal mode from Real mode. Eventually, the MBR will need to perform its main task, and load the program that will perform the next stage of the boot process, usually by making use of the INT 13 BIOS call.

Typical boot sector code also expects to be loaded at physical address 0x7c00, even though all the memory from physical address 0x501 (address 0x500 is the last one used by the BIOS)^{[citation needed]} to somewhere short of 0x9ffff is typically available in Real mode (a total of up to 640 KB minus the first 1281 bytes of memory)^[8]. Since 0x7c00 is the location where the MBR is already running, one of the first tasks of an MBR is usually to relocate itself somewhere else in memory -- most often at 0x600 (for Microsoft code). A conventional Volume Boot Record is only one sector long; but it does no harm and is trivial to allow the MBR to load significantly more than just one sector. Some bootloaders are longer than one sector, so loading more than one sector can speed up the boot process.

[edit] Differences in MBR Code

Even different versions of the MS-DOS FDISK program, not to mention the partitioning utilities for other types of operating systems, may write variations of code to the MBR sector. For example, the bytes of code written by FDISK under MS-DOS 6.22, Windows 98 and the Recovery Console of a Windows XP install CD are all different. Yet, no matter how great a difference exists in the MBR code, such as that written by an MS-DOS 3.30 install compared to the MBR produced by Windows XP, they will all load the boot sector of any OS residing in the "active" primary partition.

The following table shows how the Standard Microsoft MBR Code (created by MS-DOS 3.30 through Windows 95) would appear in a disk editor:

Absolute Sector 0 (Cylinder 0, Head 0, Sector 1)
       0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F
0000  FA 33 C0 8E D0 BC 00 7C 8B F4 50 07 50 1F FB FC  .3.....|..P.P... 
0010  BF 00 06 B9 00 01 F2 A5 EA 1D 06 00 00 BE BE 07  ................ 
0020  B3 04 80 3C 80 74 0E 80 3C 00 75 1C 83 C6 10 FE  ...<.t..<.u..... 
0030  CB 75 EF CD 18 8B 14 8B 4C 02 8B EE 83 C6 10 FE  .u......L....... 
0040  CB 74 1A 80 3C 00 74 F4 BE 8B 06 AC 3C 00 74 0B  .t..<.t.....<.t.
0050  56 BB 07 00 B4 0E CD 10 5E EB F0 EB FE BF 05 00  V.......^.......
0060  BB 00 7C B8 01 02 57 CD 13 5F 73 0C 33 C0 CD 13  ..|...W.._s.3...
0070  4F 75 ED BE A3 06 EB D3 BE C2 06 BF FE 7D 81 3D  Ou...........}.=
0080  55 AA 75 C7 8B F5 EA 00 7C 00 00 49 6E 76 61 6C  U.u.....|..Inval
0090  69 64 20 70 61 72 74 69 74 69 6F 6E 20 74 61 62  id partition tab
00A0  6C 65 00 45 72 72 6F 72 20 6C 6F 61 64 69 6E 67  le.Error loading
00B0  20 6F 70 65 72 61 74 69 6E 67 20 73 79 73 74 65   operating syste
00C0  6D 00 4D 69 73 73 69 6E 67 20 6F 70 65 72 61 74  m.Missing operat
00D0  69 6E 67 20 73 79 73 74 65 6D 00                 ing system.

A total of only 219 bytes (the zero-byte at 0DAh is necessary); 139 executable code bytes, plus 80 bytes comprising its English set of error messages.

In contrast, the MBR code created by a Windows 2000 or XP install (seen in this next table) has a total of 383 bytes for its English version:

Absolute Sector 0 (Cylinder 0, Head 0, Sector 1)
       0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F
0000  33 C0 8E D0 BC 00 7C FB 50 07 50 1F FC BE 1B 7C  3.....|.P.P....|
0010  BF 1B 06 50 57 B9 E5 01 F3 A4 CB BD BE 07 B1 04  ...PW...........
0020  38 6E 00 7C 09 75 13 83 C5 10 E2 F4 CD 18 8B F5  8n.|.u..........
0030  83 C6 10 49 74 19 38 2C 74 F6 A0 B5 07 B4 07 8B  ...It.8,t.......
0040  F0 AC 3C 00 74 FC BB 07 00 B4 0E CD 10 EB F2 88  ..<.t...........
0050  4E 10 E8 46 00 73 2A FE 46 10 80 7E 04 0B 74 0B  N..F.s*.F..~..t.
0060  80 7E 04 0C 74 05 A0 B6 07 75 D2 80 46 02 06 83  .~..t....u..F...
0070  46 08 06 83 56 0A 00 E8 21 00 73 05 A0 B6 07 EB  F...V...!.s.....
0080  BC 81 3E FE 7D 55 AA 74 0B 80 7E 10 00 74 C8 A0  ..>.}U.t..~..t..
0090  B7 07 EB A9 8B FC 1E 57 8B F5 CB BF 05 00 8A 56  .......W.......V
00A0  00 B4 08 CD 13 72 23 8A C1 24 3F 98 8A DE 8A FC  .....r#..$?.....
00B0  43 F7 E3 8B D1 86 D6 B1 06 D2 EE 42 F7 E2 39 56  C..........B..9V
00C0  0A 77 23 72 05 39 46 08 73 1C B8 01 02 BB 00 7C  .w#r.9F.s......|
00D0  8B 4E 02 8B 56 00 CD 13 73 51 4F 74 4E 32 E4 8A  .N..V...sQOtN2..
00E0  56 00 CD 13 EB E4 8A 56 00 60 BB AA 55 B4 41 CD  V......V.`..U.A.
00F0  13 72 36 81 FB 55 AA 75 30 F6 C1 01 74 2B 61 60  .r6..U.u0...t+a`
0100  6A 00 6A 00 FF 76 0A FF 76 08 6A 00 68 00 7C 6A  j.j..v..v.j.h.|j
0110  01 6A 10 B4 42 8B F4 CD 13 61 61 73 0E 4F 74 0B  .j..B....aas.Ot.
0120  32 E4 8A 56 00 CD 13 EB D6 61 F9 C3 49 6E 76 61  2..V.....a..Inva
0130  6C 69 64 20 70 61 72 74 69 74 69 6F 6E 20 74 61  lid partition ta
0140  62 6C 65 00 45 72 72 6F 72 20 6C 6F 61 64 69 6E  ble.Error loadin
0150  67 20 6F 70 65 72 61 74 69 6E 67 20 73 79 73 74  g operating syst
0160  65 6D 00 4D 69 73 73 69 6E 67 20 6F 70 65 72 61  em.Missing opera
0170  74 69 6E 67 20 73 79 73 74 65 6D 00 00 00 00 00  ting system.....
0180  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0190  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
01A0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
01B0  00 00 00 00 00 2C 44 63                          .....,Dc

The first 300 bytes are executable code, followed by 80 bytes (including the zero-byte at 017Bh) which contain its error messages; plus the 3 bytes at the end (from 01B5h through 01B7h) used by the code to locate the beginning of each error message, for a total of 383 bytes. The space in-between (presently filled with zero-bytes) is available for longer error messages written in other languages; in which case, the last 3 bytes would be adjusted for their lengths.

[edit] Editing/replacing MBR Contents

Though it is possible to directly manipulate the bytes in the MBR sector using various Disk Editors, Microsoft-based operating systems have included the means to write fixed sets of functioning code to the MBR sector for some time. Since MS-DOS 5.0, the DOS-mode program FDISK has included the (undocumented, but widely used) switch /mbr, which will rewrite the MBR code. (Caution: Using the FDISK /MBR command from MS-DOS 6.22/Windows 95, or any earlier versions, may zero-out the partition table under some circumstances; especially if the last two bytes of the MBR sector are not 55h followed by AAh. If a DOS boot is necessary, use the FDISK program from a Windows 98, or other FAT32 capable boot disk, as a safer alternative; to ensure only the code area, not the partition table, is overwritten.) Under Windows 2000 or later, the Recovery Console can be used to write new MBR code to a hard disk using its fixmbr command.

Some third-party utilities may also be used for directly editing the contents of partition tables (without requiring any knowledge of hexadecimal or disk/sector editors).^[12]

In Linux install-mbr is used as the MBR manager. ^[13][14]

[edit] Backing up/restoring the MBR

Note: If you decide to back up your MBR sector, be sure to save the file on an emergency diskette or other backup device, or just print out a text representation of its hexadecimal bytes as you would see them in a disk editor. Simply storing the file on the same disk drive it was copied from will do no good if the disk's partition table has been erased.

[edit] DR-DOS

In DR-DOS 6 (and possibly other versions), the FDISK program has an additional option to "Re-write Master Boot Record". When this is done the old MBR is stored in a file, OLDMBR.BIN. This file can be copied. If it is present on a disk, FDISK will instead prompt to "Restore Original Boot Record", and the file will be re-loaded as the disk's boot record.

[edit] MS-DOS and Windows

For MS-DOS and Windows-based operating systems, a number of third-party utilities exist for backing-up the MBR and/or partition table data. (See the "External links" section below.)

In any case, one can use the official fixmbr command from the Windows recovery console ^[15]

It is possible to install Linux and keep the Windows MBR untouched. ^[16]

[edit] Unix-like systems

The dd utility, which is available on most Unix-like systems, can be used to create backup images of the master boot record. Care should be taken when using the dd utility, as incorrect values for its parameters can cause data corruption. You must have the appropriate access to the target device in order to use these commands successfully.

To back up the MBR of a hard disk or other storage device, use the following command to create a file named mbr.bin containing the entire contents of the master boot record:

# dd if=device of=mbr.bin bs=512 count=1

where device is the path of the device file corresponding to the entire contents of the storage device whose MBR is to be backed up. For example, the primary master IDE device (ATA bus 0, device 0) is typically represented by the device file /dev/hda under Linux.

To restore the MBR from a backup file to a storage device, use the following command, which replaces the first 512 bytes with the contents of the file named mbr.bin:

# dd if=mbr.bin of=device bs=512 count=1

To back up or restore only the executable code area, assuming that the executable code uses at most 446 bytes, use the option bs=446 instead of bs=512 when executing the appropriate command. If a full 512-byte backup has already been made, a 446-byte partial restore can still be used, but the opposite is not true (dd cannot copy more bytes from a file than it contains). Using a partial restore can be useful if both the code area and the partition table have been changed and it is necessary to restore only the original code without losing the new partition table.

Note: Before proceeding with any of the partial commands above, it is advisable to ascertain the correct number of bytes to copy from or restore to the MBR, since the size of the executable code area can vary.

Another way to repair the mbr of your USB device is install lilo then type (replacing x with the letter of your flash device) :

lilo -M /dev/sdx

[edit] Re-creating a lost partition table

If the primary partition table in the MBR is either overwritten accidentally or altered, there are programs, like TestDisk, that will search the rest of the hard disk for patterns that indicate where the partitions are located and then re-create the MBR partition table, making the partitions available once again.

[edit] Footnotes

• ^  1. On all IBM PC, PC compatible or any other little-endian computers, hexadecimal numbers of two or more bytes are always stored on media or in memory in reverse order (for more efficient CPU processing). Thus, the hex number 0xAA55 (or AA55h) will appear in a disk editor as the sequence: 55 AA.
• ^  2. In cases where the disk has a BIOS overlay or Boot manager installed, the partition table may be moved to some other physical location on the drive; e.g., a BIOS overlay often places a copy of the original MBR contents in the second sector ("Sector 1") then hides itself from any subsequently booted OS or application, so the MBR copy in Sector 1 is treated as if it were still residing in the first sector.
• ^  3. The status fields in an unextended partition table record are used by the embedded bootstrap code within the MBR to determine which partition is bootable (it is referred to as the active partition, and there can only be one active/bootable partition within the MBR). The status fields in an extended partition table record may also be used by boot manager programs to determine which partitions are bootable.
• ^  4. Formally, values other than 0x00 and 0x80 in this field have undefined meanings and the bootstrap program may display an error message if this occurs. In practice, their meaning depends upon what the actual bootstrap code within the MBR has been written to accept. Some MBR bootstrap programs specifically look for the value 0x80 to indicate the bootable ("active") partition, others simply look for a non-zero value, and yet others look for any value with the top bit set.
• ^  5. Starting Sector fields are limited to 1024 cylinders, 255 heads, and 63 sectors. Sector counts have always begun with a 1; not zero, and due to an early error in MS-DOS, the heads are generally limited to 255 instead of 256. When a CHS address is too large to fit into these fields, the tuple (1023, 254, 63) is used.
• ^  6. Ending Sector fields have the same limitations as the Starting Sector fields (see Footnote 5 above).
• ^  7. Unlike the sector count used in the Sectors value of CHS tuples; which counts from one, the Absolute or LBA Sectors value starts counting from zero.
• ^  8. Very old machines may have less than 640 KB (A0000h or 655,360 bytes) of memory, and newer machines may allocate significant amounts of memory for BIOS uses. The INT 12 BIOS call may help in determining how much memory can safely be allocated (it simply reads the Base Memory size in KB from Segment:Offset location 0040h:0013h). In theory, only 64255 bytes is guaranteed (beginning at 0x501 and ending at 0x0ffff); in practice it is safe to assume at least 382.74 KB (ending at 0x5ffff) are available on modern hardware.

[edit] References

1. ^ Peter C Norton and Scott Clark (2002). Peter Norton's New Inside the PC. Sams Publishing, 360–361. ISBN 0672322897. 
2. ^ Michael W. Graves (2004). A+ Guide To PC Hardware Maintenance and Repair. Thomson Delmar, 276. ISBN 1401852300. 
3. ^ Jean Andrews (2003). Upgrade and Repair with Jean Andrews. Thomson Course Technology, 646. ISBN 1592001122. 
4. ^ William Boswell (2003). Inside Windows Server 2003. Addison-Wesley Professional, 13. ISBN 0735711585. 
5. ^ Andries Brouwer. List of partition identifiers for PCs. Partition types.
6. ^ Roderick W. Smith (2000). The Multi-Boot Configuration Handbook. Que Publishing, 260–261. ISBN 0789722836. 
7. ^ Andries Brouwer. Properties of partition tables. Partition types. PTS-DOS uses "a special 5th partition entry in front of the other four entries in the MBR and corresponding AAP-aware MBR bootstrap code." (Brouwer).
8. ^ Brouwer, ibid. Some OEM systems, such as AST DOS (type 14h) and NEC DOS (type 24h) had 8 instead of 4 partition entries in their MBR sectors.
9. ^ Daniel B. Sedory. Notes on the Differences in one OEM version of the DOS 3.30 MBR. Master Boot Records. Shows an 8-entry partition table and where its boot code differs from MS-DOS 3.30.
10. ^ Matt Domsch. Re: RFC 2.6.0 EDD enhancements. Linux Kernel Mailing List.
11. ^ Microsoft. Windows May Use Signature() Syntax in the Boot.ini File. KnowledgeBase.
12. ^ For example, Power Quest's Partition Table Editor (PTEDIT32.EXE), which runs under Windows operating systems, is still available here: Symantec's FTP site.
13. ^ install-mbr - What is install-mbr
14. ^ www.wlug.org.nz/install-mbr(8)
15. ^ Recovery Console
16. ^ To install Linux and keep Windows untouched like a virgin - JustLinux Forums

[edit] Further reading

• P. Brady. Details of how GRUB fits into hardisk layout on a PC. www.pixelbeat.org.
• H. Gilbert. Partitions and Volumes. PC Lube & Tune.

• Ray Knights. Ray's Place. MBR and Windows Boot Sectors (includes code disassembly and explanations of boot process).
• Hale Landis. Master Boot Record. How It Works.
• Daniel B. Sedory. MBRs (Master Boot Records). Boot Records Revealed!. (Mirror site) (Another mirror site)
• Understanding and Working with the MBR. www.cpqlinux.com.

[edit] See also

• Boot loader
• BIOS interrupt call
• Disk cloning
• GUID Partition Table A more modern partitioning scheme, replacing the purpose of the MBR
• GNU Parted
• PBR
• Recovery disc

[edit] External links

• Standard MBR code dissasembly
• MBRWizard! The MBR Management Utility - freeware for Linux and Windows
• HxD - A freeware Windows disk editor which can be used to explore and back up critical sectors, such as the MBR.
• rohPod - A simple block oriented disk editor, which can repair MBRs and works even over the network. Works on Linux, Mac OS X and Windows
• MBRtool, a DOS program designed to backup, restore and manipulate hard disk MBR.
• Booting 100+ Operating systems - An example of GRUB usage to boot every type of Operating Systems. Contains a lot of info about booting.