docs/handbook/handbook-boot-blocks.mdwn

   1 \r
   2 ----\r
   3 \r
   4 ## 7.3 The Boot Manager and Boot Stages \r
   5 \r
   6 ### 7.3.1 The Boot Manager \r
   7 \r
   8 The code in the MBR or boot manager is sometimes referred to as ***stage zero*** of the boot process. This subsection discusses two of the boot managers previously mentioned:  **boot0**  and  **LILO** .\r
   9 \r
  10  **The** boot0 ** Boot Manager:** The MBR installed by FreeBSD's installer or [boot0cfg(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#boot0cfg&section8), by default, is based on `/boot/boot0`. (The  **boot0**  program is very simple, since the program in the MBR can only be 446 bytes long because of the slice table and `0x55AA` identifier at the end of the MBR.) If you have installed  **boot0**  and multiple operating systems on your hard disks, then you will see a display similar to this one at boot time:\r
  11 \r
  12  **Example 7-1. `boot0` Screenshot** \r
  13 \r
  14     \r
  15     F1 DOS\r
  16     F2 FreeBSD\r
  17     F3 Linux\r
  18     F4 ??\r
  19     F5 Drive 1\r
  20     \r
  21     Default: F2\r
  22 \r
  23 \r
  24 Other operating systems, in particular Windows®, have been known to overwrite an existing MBR with their own. If this happens to you, or you want to replace your existing MBR with the DragonFly MBR then use the following command:\r
  25 \r
  26     \r
  27     # fdisk -B -b /boot/boot0 device\r
  28 \r
  29 \r
  30 where `***device***` is the device that you boot from, such as `ad0` for the first IDE disk, `ad2` for the first IDE disk on a second IDE controller, `da0` for the first SCSI disk, and so on. Or, if you want a custom configuration of the MBR, use [boot0cfg(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#boot0cfg&section8).\r
  31 \r
  32  **The LILO Boot Manager:** To install this boot manager so it will also boot DragonFly, first start Linux and add the following to your existing `/etc/lilo.conf` configuration file:\r
  33 \r
  34     \r
  35     other=/dev/hdXY\r
  36     table=/dev/hdX\r
  37     loader=/boot/chain.b\r
  38     label=DragonFly\r
  39 \r
  40 \r
  41 In the above, specify DragonFly's primary partition and drive using Linux specifiers, replacing `***X***` with the Linux drive letter and `***Y***` with the Linux primary partition number. If you are using a SCSI drive, you will need to change `***/dev/hd***` to read something similar to `***/dev/sd***`. The `loader=/boot/chain.b` line can be omitted if you have both operating systems on the same drive. Now run `/sbin/lilo -v` to commit your new changes to the system; this should be verified by checking its screen messages.\r
  42 \r
  43 ### 7.3.2 Stage One, /boot/boot1, and Stage Two, /boot/boot2 \r
  44 \r
  45 Conceptually the first and second stages are part of the same program, on the same area of the disk. Because of space constraints they have been split into two, but you would always install them together. They are copied from the combined file `/boot/boot` by the installer or  **disklabel**  (see below).\r
  46 \r
  47 They are located outside file systems, in the first track of the boot slice, starting with the first sector. This is where [ boot0](boot-blocks.html#BOOT-BOOT0), or any other boot manager, expects to find a program to run which will continue the boot process. The number of sectors used is easily determined from the size of `/boot/boot`.\r
  48 \r
  49 They are found on the boot sector of the boot slice, which is where [ boot0](boot-blocks.html#BOOT-BOOT0), or any other program on the MBR expects to find the program to run to continue the boot process. The files in the `/boot` directory are copies of the real files, which are stored outside of the DragonFly file system.\r
  50 \r
  51 `boot1` is very simple, since it can only be 512 bytes in size, and knows just enough about the DragonFly ***disklabel***, which stores information about the slice, to find and execute `boot2`.\r
  52 \r
  53 `boot2` is slightly more sophisticated, and understands the DragonFly file system enough to find files on it, and can provide a simple interface to choose the kernel or loader to run.\r
  54 \r
  55 Since the [ loader](boot-blocks.html#BOOT-LOADER) is much more sophisticated, and provides a nice easy-to-use boot configuration, `boot2` usually runs it, but previously it was tasked to run the kernel directly.\r
  56 \r
  57  **Example 7-2. boot2 Screenshot** \r
  58 \r
  59     \r
  60     &gt;&gt; DragonFly/i386 BOOT\r
  61     Default: 0:ad(0,a)/boot/loader\r
  62     boot:\r
  63 \r
  64 \r
  65 If you ever need to replace the installed `boot1` and `boot2` use [disklabel(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#disklabel&section8):\r
  66 \r
  67     \r
  68     # disklabel -B diskslice\r
  69 \r
  70 \r
  71 where `***diskslice***` is the disk and slice you boot from, such as `ad0s1` for the first slice on the first IDE disk.\r
  72 \r
  73 ### 7.3.3 Stage Three, `/boot/loader` \r
  74 \r
  75 The loader is the final stage of the three-stage bootstrap, and is located on the file system, usually as `/boot/loader`.\r
  76 \r
  77 The loader is intended as a user-friendly method for configuration, using an easy-to-use built-in command set, backed up by a more powerful interpreter, with a more complex command set.\r
  78 \r
  79 #### 7.3.3.1 Loader Program Flow \r
  80 \r
  81 During initialization, the loader will probe for a console and for disks, and figure out what disk it is booting from. It will set variables accordingly, and an interpreter is started where user commands can be passed from a script or interactively.\r
  82 \r
  83 The loader will then read `/boot/loader.rc`, which by default reads in `/boot/defaults/loader.conf` which sets reasonable defaults for variables and reads `/boot/loader.conf` for local changes to those variables. `loader.rc` then acts on these variables, loading whichever modules and kernel are selected.\r
  84 \r
  85 Finally, by default, the loader issues a 10 second wait for key presses, and boots the kernel if it is not interrupted. If interrupted, the user is presented with a prompt which understands the easy-to-use command set, where the user may adjust variables, unload all modules, load modules, and then finally boot or reboot.\r
  86 \r
  87 #### 7.3.3.2 Loader Built-In Commands \r
  88 \r
  89 These are the most commonly used loader commands. For a complete discussion of all available commands, please see [loader(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#loader&section8).\r
  90 \r
  91 autoboot `***seconds***`:: Proceeds to boot the kernel if not interrupted within the time span given, in seconds. It displays a countdown, and the default time span is 10 seconds.boot [`***-options***`] [`***kernelname***`]:: Immediately proceeds to boot the kernel, with the given options, if any, and with the kernel name given, if it is.boot-conf:: Goes through the same automatic configuration of modules based on variables as what happens at boot. This only makes sense if you use `unload` first, and change some variables, most commonly `kernel`.help [`***topic***`]:: Shows help messages read from `/boot/loader.help`. If the topic given is `index`, then the list of available topics is given.include `***filename***` ...:: Processes the file with the given filename. The file is read in, and interpreted line by line. An error immediately stops the include command.load [`-t` `***type***`] `***filename***`:: Loads the kernel, kernel module, or file of the type given, with the filename given. Any arguments after filename are passed to the file.ls [`-l`] [`***path***`]:: Displays a listing of files in the given path, or the root directory, if the path is not specified. If `-l` is specified, file sizes will be shown too.lsdev [`-v`]:: Lists all of the devices from which it may be possible to load modules. If `-v` is specified, more details are printed.lsmod [`-v`]:: Displays loaded modules. If `-v` is specified, more details are shown.more `***filename***`:: Displays the files specified, with a pause at each `LINES` displayed.reboot:: Immediately reboots the system.set `***variable***`, set `***variable***`=`***value***`:: Sets the loader's environment variables.unload:: Removes all loaded modules.\r
  92 \r
  93 #### 7.3.3.3 Loader Examples \r
  94 \r
  95 Here are some practical examples of loader usage:\r
  96 \r
  97
  98 * To simply boot your usual kernel, but in single-user mode:\r
  99       \r
 100       boot -s\r
 101   \r
 102
 103 * To unload your usual kernel and modules, and then load just your old (or another) kernel:\r
 104       \r
 105       unload\r
 106       load `***kernel.old***`\r
 107   \r
 108   You can use `kernel.GENERIC` to refer to the generic kernel that comes on the install disk, or `kernel.old` to refer to your previously installed kernel (when you have upgraded or configured your own kernel, for example).\r
 109    **Note:** Use the following to load your usual modules with another kernel:\r
 110       \r
 111       unload\r
 112       set kernel="`***kernel.old***`"\r
 113       boot-conf\r
 114   \r
 115
 116 * To load a kernel configuration script (an automated script which does the things you would normally do in the kernel boot-time configurator):\r
 117       \r
 118       load -t userconfig_script `***/boot/kernel.conf***`\r
 119   \r
 120 \r
 121 ----\r
 122 \r
 123 \r