From owner-freebsd-doc Mon Nov 8 2:58:46 1999 Delivered-To: freebsd-doc@freebsd.org Received: from terrapin.ru.ac.za (terrapin.ru.ac.za [146.231.128.6]) by hub.freebsd.org (Postfix) with ESMTP id 5A62814E66 for ; Mon, 8 Nov 1999 02:58:15 -0800 (PST) (envelope-from nbm@mithrandr.moria.org) Received: from duca.dialup.ru.ac.za ([146.231.98.24] helo=mithrandr.moria.org) by terrapin.ru.ac.za with esmtp (Exim 3.03 #1) id 11kmUq-0004EB-00 for doc@FreeBSD.org; Mon, 08 Nov 1999 12:58:00 +0200 Received: (qmail 32791 invoked by uid 1001); 8 Nov 1999 10:26:06 -0000 Date: Mon, 8 Nov 1999 12:26:06 +0200 From: Neil Blakey-Milner To: FreeBSD Documentation Project Subject: boot-process description (who wants it?) Message-ID: <19991108122606.A32759@mithrandr.moria.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=DocE+STaALJfprDB X-Mailer: Mutt 0.95.1i Organization: Rhodes University Computer Users' Society X-Operating-System: FreeBSD 4.0-CURRENT i386 X-URL: http://rucus.ru.ac.za/~nbm/ Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Hi, I've run out of time on this, so if someone feels like taking it and polishing it, I'd appreciate it. I've had to rush the last half, and it's missing kernel userconfig description, and a more in-depth discussion of rc. Have fun, Neil -- Neil Blakey-Milner nbm@rucus.ru.ac.za --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="chapter.sgml" The Bootstrapping Process 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 focusses 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 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-use 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 Once the kernel has finished booting, it passes control to the user 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. --DocE+STaALJfprDB-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message