From d3c2c41234d250a56bc6fbd61f3b07a6e60bdc42 Mon Sep 17 00:00:00 2001 From: Neil Blakey-Milner Date: Fri, 14 Jan 2000 11:04:56 +0000 Subject: [PATCH] Addition of my boot process documentation released on -doc, now that phk's previous section has been removed. --- .../books/handbook/internals/chapter.sgml | 508 +++++++++++++++++- 1 file changed, 504 insertions(+), 4 deletions(-) diff --git a/en_US.ISO_8859-1/books/handbook/internals/chapter.sgml b/en_US.ISO_8859-1/books/handbook/internals/chapter.sgml index 467da85b31..473901f14b 100644 --- a/en_US.ISO_8859-1/books/handbook/internals/chapter.sgml +++ b/en_US.ISO_8859-1/books/handbook/internals/chapter.sgml @@ -1,7 +1,7 @@ @@ -9,11 +9,511 @@ The FreeBSD Booting Process + + + Introduction + + Bootstrapping is the process + whereby a computer probes and initializes its devices, and + works out what programs it is supposed to run. + + This involves the use of special Read Only Memory chips, + which determine what further operations to do, and these + usually pass control to other chips that do consistency and + memory tests, configure devices, and provide a mechanism for + programs to determine what configuration details were + determined. + + In standard personal computers, this involves the BIOS, + which oversees the bootstrap, and CMOS, which stores + configuration; and these understand disks, and they also + understand where on the disk to find a program that will know + how to load up an operating system. + + This chapter will not deal with this first part of the + bootstrap process, and focuses on what happens after control + is passed to the program on the disk. + + + + Overview of the boot process + + FreeBSD uses a three-stage bootstrap by default, which + basically entails three programs which basically call each + other in order (the two boot + blocks, and the loader), and which build on the + previous programs understanding and provide increasing amounts + of sophistication. + + The kernel is then started, during which devices are + probed for and initialized for use. Once the kernel boot + process is finished, it passes control to the user process + init, which then makes sure the disks are in a usable state, + and then starts the user-level resource configuration which + then mounts filesystems, sets up network cards to act on the + network, and generally starts all the processes that usually + are run on a FreeBSD system at startup. + + + + The boot blocks: Bootstrap stages 1 and 2 + + The boot blocks are responsible for finding (usually) the + loader, and running it, and thus need to understand how to + find that program on the filesystem, how to run the program, + and also allow minor configuration of how they work. + + + boot0 + + There is actually a preceding bootblock, named boot0, + which lives on the Master Boot + Record, the special part of the disk that the + system bootstrap looks for and runs, and it simply shows a + list of possible slices to boot from. + + boot0 is very simple, since the program in the + MBR can only be 512 bytes large. + + It displays something like this: + + + boot0 screenshot + + +F1 DOS +F2 FreeBSD +F3 Linux +F4 ?? +F5 Drive 1 + +Default: F2 + + - The FreeBSD booting process is described in the &man.boot.8; and - &man.loader.8; manual pages. - + + boot1 + + boot1 is found on the boot sector of the boot slice, + which is where boot0, or + any other program on the MBR expects to + find the program to run to continue the boot process. + + boot1 is very simple, since it too can only be 512 bytes + large, and knows just enough about the FreeBSD + disklabel, which stores information + about the slice, to find and execute boot2. + + + + boot2 + + boot2 is slightly more sophisticated, and understands + the FreeBSD filesystem enough to find files on it, and can + provide a simple interface to choose the kernel or loader to + run. + + Since the 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. + + + boot2 screenshot + + >> FreeBSD/i386 BOOT +Default: 0:wd(0,a)/kernel +boot: + + + + + + loader: Bootstrap stage three + + The loader is the final stage of the three-stage + bootstrap, and is located on the filesystem, usually as + /boot/loader. + + + While /boot/boot0, + /boot/boot1, and + /boot/boot2 are files there, they are + not the actual copies in the MBR, the boot + sector, or the disklabel respectively. + + 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. + + + loader program flow + + 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 then + the interpreter is started, and the easy-to-use commands are + explained to it. + + 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. + + Finally, by default, the loader issues a 10 second wait + for keypresses, and boots the kernel if it is 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. + + A more technical discussion of the process is available + in &man.loader.8; + + + + loader built-in commands + + The easy-to-use command set comprises of: + + + + autoboot seconds + + + Proceeds to boot the kernel if not interrupted + within the time span given, in seconds. It displays a + countdown, and the default timespan 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. + + + + + 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 + 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 + path + + + Displays a listing of files in the given path, or + the root directory, if the path is not specified. If + is specified, file sizes will be + shown too. + + + + lsdev + + + Lists all of the devices from which it may be + possible to load modules. If is + specified, more details are printed. + + + + + lsmod + + + Displays loaded modules. If is + specified, more details are shown. + + + + + more filename + + + Display the files specified, with a pause at each + LINES displayed. + + + + + reboot + + + Immediately reboots the system. + + + + + set variable + set + variable=value + + + Set loader's environment variables. + + + + + + + loader examples + + Here are some practical examples of loader usage. + + + + To simply boot your usual kernel, but in single-user + mode: + + boot -s + + + + To unload your usual kernel and modules, and then + load your old (or another) kernel: + + unload + load kernel.old + + 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've upgraded + or configured your own kernel, for example). + + + + To load a kernel configuration script (an automated + script which does the things you'd normally do in the + kernel boot-time configurator): + + load -t userconfig_script + /boot/kernel.conf + + + + + + + Kernel interaction during boot + + Once the kernel is loaded by either loader (as usual) or boot2 (bypassing the loader), it + examines its boot flags, if any, and adjusts its behaviour as + necessary. + + + Kernel bootflags + + Here are the more common boot flags: + + + + + + + during kernel initialization, ask for the device + to mount as as the root file system. + + + + + + + + boot from CDROM. + + + + + + + + run UserConfig, the boot-time kernel + configurator + + + + + + + + boot into single-user mode + + + + + + + + be more verbose during kernel startup + + + + + + There are other boot flags, read &man.boot.8; for more + information on them. + + + + + + + + Init: Process control initialization + + Onqe the kernel has finished booting, it passes control to + the usqr process init, which is located at + /sbin/init, or the program path specified + in the init_path variable in + loader. + + + Automatic reboot sequence + + The automatic reboot sequence makes sure that the + filesystems available on the system are consistent. If they + are not, and fsck can not fix the + inconsistencies, init drops the system + into single-user mode + for the system administrator to take care of the problems + directly. + + + + Single-user mode + + This mode can be reached through the automatic reboot + sequence, or by the user booting with the + or setting the + boot_single variable in + loader. + + It can also be reached by calling + shutdown without the reboot + () or halt () options, + from multi-user + mode. + + If the system console console is set + to insecure in + /etc/ttys, then the system prompts for + the root password before initiating single-user mode. + + + An insecure console in /etc/ttys + + # name getty type status comments +# +# This entry needed for asking password when init goes to single-user mode +# If you want to be asked for password, change "secure" to "insecure" here +console none unknown off insecure + + + + An insecure console means that you + consider your physical security to the console to be + insecure, and want to make sure only someone who knows the + root password may use single-user mode, and it does not + mean that you want to run your console insecurely. Thus, + if you want security, choose insecure, + not secure. + + + + + Multi-user mode + + If init finds your filesystems to be + in order, or once the user has finished in single-user mode, the + system enters multi-user mode, in which it starts the + resource configuration of the system. + + + Resource configuration (rc) + + The resource configuration system reads in + configuration defaults from + /etc/defaults/rc.conf, and + system-specific details from + /etc/rc.conf, and then proceeds to + mount the system filesystems mentioned in + /etc/fstab, start up networking + services, starts up miscellaneous system daemons, and + finally runs the startup scripts of locally installed + packages. + + &man.rc.8; is a good reference to the resource + configuaration system, as is examining the scripts + themselves. + + + + + + Shutdown sequence + + Upon controlled shutdown, via shutdown, + init will attempt to run the script + /etc/rc.shutdown, and then proceed to send + all processes the terminate signal, and subsequently the kill + signal to any that don't terminate timely. + + + PC Memory Utilization