How to Manage FreeBSD Boot Process?
The act of starting a computer and loading the operating system is known as "booting" or "the bootstrap process". FreeBSD's boot process offers a large degree of customization options for what occurs when the system begins, such as the ability to choose between several operating systems installed on the same machine, different versions of the same operating system, or a different kernel.
This chapter describes the available setup choices. It explains how to modify the FreeBSD boot process, including everything that occurs prior to the FreeBSD kernel starting, probing for devices, and starting to init. This happens when the font color of boot messages transitions from dazzling white to gray.
After reading this tutorial, you will be able to identify:
-
The components and interactions of the FreeBSD bootstrap system.
-
Options that are supplied to the FreeBSD bootstrap components to influence the booting process.
-
The essentials of configuring device suggestions.
-
How to boot a FreeBSD system into single- and multi-user mode, as well as how to properly shut it down.
What is FreeBSD Boot Process?
The problem posed by turning on a computer and launching the operating system is intriguing. The machine is incapable of doing any tasks until the operating system is activated. This involves the execution of applications from a disk. How is the operating system launched if the computer cannot execute a program from the disk without the operating system and the operating system programs are on the disk?
In the early days of computers, the process used to load the operating system was referred to as bootstrap. Since then, it has been abbreviated to "booting".
The Basic Input/Output System (BIOS) is responsible for loading the operating system on x86 hardware. The BIOS searches the hard drive for the Master Boot Record (MBR), which must be at a certain location. The BIOS has sufficient information to load and execute the MBR and thinks that the MBR completes the remaining activities required in loading the operating system, with assistance from the BIOS.
FreeBSD supports both the older MBR standard and the more modern GUID Partition Table (GPT) for booting. GPT partitioning is often seen on machines utilizing the Unified Extensible Firmware Interface (UEFI). FreeBSD can nonetheless boot from GPT partitions on devices with just a legacy BIOS if gptboot is installed. Work is under progress to enable direct UEFI booting.
When the code inside the MBR interacts with the user, it is often referred to as a boot manager. Typically, the boot manager contains additional code on the disk's first track or inside the file system. The basic FreeBSD boot manager boot0, often known as Boot Easy, and GNU GRUB, which is used by several Linux variants, are examples of boot managers.
If just one operating system is loaded, the MBR looks for the disk's first bootable (active) slice and then executes the code on that slice to load the rest of the operating system. When numerous operating systems are available, a separate boot manager may be installed to provide a selection of operating systems from which the user can choose.
The remaining FreeBSD bootstrap system consists of three steps. The first stage has just enough knowledge to place the computer in a certain condition and execute the second step. Before running the third stage, the second stage may accomplish a little bit more. The third phase concludes the loading of the operating system. The job is divided into three parts because the MBR imposes size restrictions on programs that may be executed in stages one and two. By connecting the jobs, FreeBSD is able to offer a loader with more flexibility.
The kernel is subsequently initiated and proceeds to search for and initialize devices. The kernel then passes control to the user process init, which verifies that the disks are in a usable state, begins the user-level resource configuration that mounts file systems, configures network cards to communicate over the network, and starts the processes that have been configured to run at startup.
This section elaborates on these steps and explains how to interact with the FreeBSD boot procedure.
What is Boot Manager?
The FreeBSD 'boot0' boot manager lets the user specify the disk and partition from which an i386 computer (PC) is booted.
A boot manager normally resides on sector 0 of a disk, also known as the Master Boot Record, on personal computers (MBR). The MBR includes both code (to which the PC BIOS transfers control) and data (an integrated table of specified slices).
The boot manager code included in the MBR is also referred to as stage zero of the boot process. FreeBSD employs the boot0 boot manager by default.
Based on /boot/boot0, the MBR is installed by the FreeBSD installer. Due to the slice table and 0x55AA identification at the end of the MBR, boot0 is limited to 446 bytes in size and functionality. If boot0 and several operating systems are installed, a boot message similar to the following will appear:
F1 Windows
F2 FreeBSD
Default: F2
If other operating systems are installed after FreeBSD, they will replace the MBR. You may run the following command if this occurs, or to replace the present MBR with the FreeBSD MBR:
fdisk -B -b /boot/boot0 device
Here device is the boot disk, such as ad0 for the first IDE disk, ad2 for the first IDE disk on a second IDE controller, or da0 for the first SCSI disk.
The boot0cfg software optionally installs the 'boot0' boot manager on the chosen disk and allows the configuration of different operating settings.
To build a customized MBR setup, you may use the boot manager installation/configuration utility, boot0cfg. Syntax of the boot0cfg utility usage is given below:
boot0cfg [-Bv] [-b boot0] [-d drive] [-e bell character] [-f file]
[-i volume-id] [-m mask] [-o options] [-s slice] [-t ticks] disk
What are the 1st and 2nd Stages of the Boot Process?
The first and second phases are conceptually part of the same program on the same disk sector. They have been divided into two pieces because of space concerns, however, they are always put together. The FreeBSD installer or bsdlabel copies them from the merged /boot/boot directory.
These two phases are situated outside of file systems, beginning with the first sector on the first track of the boot slice. This is where boot0 or any other boot manager expects to find an executable application that will continue the booting procedure.
The initial step, boot1, is fairly basic, since its size is limited to 512 bytes. It understands just enough about the FreeBSD bsdlabel, which maintains slice-specific information, to locate and perform boot2.
The second stage, boot2, is significantly more advanced and has sufficient knowledge of the FreeBSD file system to locate files. It may give a straightforward interface for selecting the kernel or loader to execute. It executes loader, which is far more complex, and gives a boot configuration file. If stage two of the boot process is stopped, the following interactive interface is displayed:
>> FreeBSD/i386 BOOT
Default: 0:ad(0,a)/boot/loader
boot:
To replace the installed boot1 and boot2, you may use bsdlabel utility and run the nex command where diskslice is the disk and slice to boot from, such as ad0s1 for the first slice on the first IDE disk:
bsdlabel -B diskslice
If just the disk name, such as ad0, is specified, bsdlabel creates the disk in "dangerously devoted mode", without slices. Double-check the diskslice before hitting return, since this is probably not the intended operation.
What is the 3rd Stage of the Boot Process?
The loader is the third and last phase of FreeBSD's kernel bootstrap procedure. It is often found on the file system as /boot/loader.
The loader is meant to be an interactive approach for configuration, with a built-in command set supported by a more potent interpreter with more complicated commands. It includes a scripting language for automating processes, performing pre-configuration, and aiding in recovery procedures. This scripting language consists mostly of two components. The smaller one is a collection of commands intended for direct use by the casual user, formerly known as "built-in commands". The primary motivation behind these instructions is the ease of usage. The larger component is John Sadler's ANS Forth-compatible Forth interpreter based on FICL.
During startup, the loader will examine the console and disks to determine which disk it will boot from. It initializes variables appropriately and launches an interpreter where user instructions are supplied interactively or from a script.
The loader will then read /boot/loader.rc, which by default reads /boot/defaults/loader.conf, which establishes appropriate defaults for variables, and reads /boot/loader.conf for local modifications to these variables. loader.rc then loads the specified modules and kernel based on these values.
Finally, by default, the loader waits 10 seconds for keystrokes before booting the kernel if no interruptions occur. If interrupted, the user is provided with a prompt that understands the command set, at which point the user may edit variables, unload all modules, load modules, reboot, or boot.
Loader Built-In Commands is a collection of the most popular loader commands. Refer to loader for a comprehensive overview of all possible commands.
-
autoboot seconds: Attempts to start the kernel if it is not interrupted within the specified amount of time, in seconds. The default time span for the displayed countdown is 10 seconds.
-
boot [-options] [kernelname]: Immediately boots the kernel with any settings or kernel name supplied. After an unload command has been sent, a kernel name may be specified on the command line. Otherwise, the kernel that was previously loaded will be utilized. If kernelname is unqualified,
/boot/kerneland/boot/moduleswill be searched. -
boot-conf: Automatically configures modules depending on supplied variables, often kernel. This makes sense only if unload is executed before to modifying any variables.
-
help [topic]: Displays aid messages read the contents of
/boot/loader.help. If the specified topic isindex, the list of the available topics is presented. -
include filename: Reads and analyses the provided file line by line. An error terminates the inclusion immediately.
-
load [-t type] filename: Loads the kernel, kernel module, or file of the specified type with the filename supplied. Any subsequent parameters are sent to the file. If
filenameis unqualified,/boot/kerneland/boot/moduleswill be searched. -
ls [-l] [path]: Displays a list of files inside the supplied path, or the root directory if no path is specified. If the
-loption is given, file sizes are shown as well. -
lsdev [-v]: Enumerates all devices from which it is possible to load modules. If -v is given, more information is printed.
-
lsmod [-v]: Displays loaded module information. If -v is given, more information are shown.
-
more filename: Displays the supplied files with a delay between each
LINES. -
reboot: reboots the system immediately.
-
set variable, set variable=value: Sets the specified environment variables.
-
unload: Removes all modules loaded.
To boot the standard kernel in single-user mode, you may run the next command:
boot -s
To unload the regular kernel and modules and then load the previous or a different kernel, run the next command:
unload
load /path/to/kernelfile
Use /boot/GENERIC/kernel to refer to the kernel that comes with an installation, and /boot/kernel.old/kernel to refer to the kernel that was installed prior to a system update or before setting a custom kernel.
Utilize the following commands to load standard modules with a different kernel. Note that in this instance, the qualified name is optional:
unload
set kernel="mykernel"
boot-conf
You may run the following command to load an automated kernel configuration script:
load -t userconfig_script /boot/kernel.conf
What is the Last Stage of the Boot Process?
Once the kernel is loaded by either loader or boot2, which bypasses loader, it checks any boot flags and changes its behavior as needed. you can find a list of the most common boot flags below.
| Option | Description |
|---|---|
| -a | Ask the kernel to mount the device as the root file system when it starts up. |
| -C | Boot the root file system from a CDROM. |
| -s | Boot into single-user mode. |
| -v | Be more verbose during kernel startup. |
Table 1. FreeBSD Kernel boot options
Once the kernel is done booting, it gives control to the user process init, which is located at /sbin/init or the program path specified in the init path variable in loader. This is the last step in starting up.
The boot sequence makes sure that the system's file systems are all the same. If a UFS file system isn't consistent and fsck can't fix it, init puts the system into single-user mode so the system administrator can fix it directly. The system starts up in multi-user mode, if that doesn't happen.
What is single-user mode?
This mode can be set by booting with the -s option or by changing the boot single variable in loader. You can also get there from multi-user mode by typing shutdown now. This message shows up at the start of single-user mode:
Enter full pathname of shell or RETURN for /bin/sh:
For /bin/sh, you may enter the full pathname of the shell or press RETURN. The default Bourne shell will start if you press Enter. Enter the full path to a different shell to change it.
Most of the time, single-user mode is used to fix a system that won't boot because of a broken file system or a mistake in a boot configuration file. It is used to change the root password if you don't remember it. The single-user mode prompt gives full, local access to the system and its configuration files, so these things are possible. In this mode, you can't connect to other people.
Single-user mode is helpful for fixing a computer, but it's not safe unless the computer is in a safe place. After booting into single-user mode, by default, any user who can physically access a system will have full control over that system.
If the console setting in /etc/ttys is changed to "insecure", the system asks for the root password before going into single-user mode. This makes the system a little safer, but it makes it impossible to reset the root password if it is forgotten.
You may configure an Insecure Console by editing in /etc/ttys as given below:
# name getty type status comments
#
# If console is marked "insecure", then init will ask for the root password
# when going to single-user mode.
console none unknown off insecure
An insecure console means that the physical security of the console isn't good, so single-user mode can only be used by someone who knows the root password.
What is Multi-user mode?
If init finds that the file systems are working, or if the user has finished their commands in single-user mode and typed exit to leave single-user mode, the system goes into multi-user mode and starts setting up the system's resources.
The resource configuration system reads configuration defaults from /etc/defaults/rc.conf and system-specific information from /etc/rc.conf. Then, it mounts the file systems that are listed in /etc/fstab. It starts networking services, various system daemons, and then the locally installed packages' startup scripts.
What is Device Hints?
When the system is about to start up, the boot loader reads the device.hints file and sends its contents to the kernel. It has different variables that control how the kernel boots up. Most of the time, these variables are "device hints", but they can be any kernel-tunable value.
Each line in the file has one variable. Lines that start with a # are called comments, and the boot loader ignores them.
At the Stage 3 boot loader prompt, device hints can also be given. After the boot loader reads the file, you can look at the variables with the show command and use the set and unset commands to add a new variable, change an existing one, or delete a variable. You can also change variables that are set in /boot/device.hints. Device hints you enter at the boot loader aren't permanent, so they won't be used the next time you reboot.
After the system is up and running, you can use the kenv command to print out these variables.
Device drivers set up the device with the help of device hint variables.
Most of the time, ISA device drivers use them to tell where they will look for the right devices and what resources they will try to use.
A device hint line looks like as given below:
hint.driver.unit.keyword="value"
where
-
driveris the name of the driver -
unitis the number of the unit -
keywordis the hint's keyword.
You may use the following options for the keyword parameter:
-
atnames the bus that the device is connected to. -
portgives the device the start address of the I/O ports that it will use. -
portsizelets you know how many ports a device has. -
irqis the number of the interrupt line to use. -
drqis the number of the DMA channel. -
maddrtells the device what physical memory address to use. -
msizetells the device how much physical memory it has. -
flagstells the device how to handle different flag bits. -
disabledfield may be set to "1" field to disable the device.
The syntax for the Stage 3 boot loader is given below:
set hint.driver.unit.keyword=value
The following code shows how to set up the ISA bus for the uart driver:
hint.uart.0.at="isa"
hint.uart.0.port="0x3F8"
hint.uart.0.flags="0x10"
hint.uart.0.irq="4"
The following example disables the ACPI driver:
hint.acpi.0.disabled="1"
To set a tunable variable, you may use the following option:
vm.pmap.pg_ps_enabled=1
What is Shutdown Sequence?
When you use shutdown to do a controlled shutdown, init tries to run the script /etc/rc.shutdown. It then sends the TERM signal to all processes and the KILL signal to any that don't end in time.
On architectures and systems that support power management, you use the next command to turn off the power immediately on a FreeBSD machine:
shutdown -p now
You may run the following command on a FreeBSD system to restart it:
shutdown -r now
To run shutdown, you must be root or a member of the operator group.
You may also use the following command to shutdown your FreeBSD system:
halt
You may also use the next command to reboot your FreeBSD system:
reboot
What is Splash Screen?
When compared to the original boot messages, the splash screen makes the boot screen look better. This screen is shown until a login prompt comes up on the console or from the X display manager.
FreeBSD has two basic environments that can be used. The first is the default command line environment for the legacy virtual console. When the system is done starting up, a console login prompt is shown. The second environment is a graphical one called X11 Desktop. After installing X11 and one of the graphical desktop environments like GNOME, KDE, or XFce, the startx command can be used to bring up the X11 desktop.
Some users like the graphical X11 login screen better than the text-based text login prompt. Display managers like XDM for Xorg, gdm for GNOME, and kdm for KDE, as well as any other from the Ports Collection, basically replace the console login prompt with a graphical login screen. After the user has successfully signed in, they show him or her a graphical desktop.
Before showing the login prompt, the splash screen in the command line environment would hide all the boot probe messages and task startup messages. In an X11 environment, users would see a clearer system start-up that was more like what they would see on a Microsoft Windows or other non-Unix system.
How the Splash Screen Works?
Only 256-color bitmap (.bmp) or ZSoft PCX (.pcx) files can be used for the splash screen function. For standard VGA adapters to work, the splash image files must have a resolution of 320 by 200 pixels or less. Turn on the VESA support that comes with FreeBSD to use larger images with a resolution of up to 1024 by 768 pixels. This is done by loading the VESA module when the system starts up, or by adding a VESA kernel configuration option and building a custom kernel. With VESA support, users can show a splash screen that takes up the whole display screen.
During the booting process, the splash screen is shown. You can turn it off at any time by pressing any key on the keyboard.
Outside of X11, the splash screen is set to be a screen saver. After a certain amount of time without being used, the screen will change to the splash screen and go through steps where the brightness of the image changes from very bright to very dark and back again. You may change how the splash screen (screen saver) works by adding a saver= line to /etc/rc.conf. The splash manual page has a full list of all the screen savers that come with the saver= option. "Warp" is the name of the default screen saver. Note that the saver= option in the /etc/rc.conf only works with virtual consoles. It doesn't change anything for X11 display managers.
Even if the splash screen is turned on, a few boot loader messages, like the boot options menu and a countdown timer, are shown at boot time.
How to Enable the Splash Screen Function?
The splash screen file (.bmp or.pcx) must be put on the root partition, for example in the /boot directory.
Change /boot/loader.conf so it has the following lines:
splash_bmp_load="YES"
bitmap_load="YES"
bitmap_name="/boot/splash.bmp"
For video resolutions larger than 1024 by 768 pixels, change /boot/loader.conf to include the following:
vesa_load="YES"
splash_bmp_load="YES"
bitmap_load="YES"
bitmap_name="/boot/splash.bmp"
Previous example is based on the idea that the splash screen is /boot/splash.bmp. If you want a PCX file, use the following statements, plus the vesa_load="YES" line if the resolution is high enough.
splash_pcx_load="YES"
bitmap_load="YES"
bitmap_name="/boot/splash.pcx"
The name of the file doesn't have to be "splash", as shown above. It can be anything, as long as the type is BMP or PCX. There are some other options in loader.conf:
beastie_disable="YES"
This will stop the boot options menu from showing up, but the countdown prompt for the timed wait will still be there. Even if the boot options menu isn't shown, if you enter a choice at the timed wait countdown prompt, the corresponding boot option will be used.
loader_logo="beastie"
This will change the words "FreeBSD", which are shown by default to the right of the boot options menu, to the colored beastie logo, like older releases had.