Ctrlk
VitePress 镜像站QQ 群 787969044视频教程Ⅰ视频教程Ⅱ
discord
For the complete documentation index, see llms.txt. This page is also available as Markdown.

15.1 Boot Loaders

The FreeBSD boot process consists of five core stages: firmware initialization (BIOS or UEFI) → boot loader (boot0/boot1/boot2) → loader boot → kernel initialization → user space initialization, where the loader stage enables parameterized configuration through loader.conf. This section analyzes the boot process and explains the key configuration items of loader.conf.

Overview of the FreeBSD Boot Process

The FreeBSD boot process is a multi-stage ordered sequence, starting from the hardware Power-On Self-Test (POST), proceeding through firmware initialization, boot loader execution, kernel loading, and finally entering user space initialization. The loader is the final stage of the boot loading process.

The FreeBSD boot process can be divided into the following stages:

  1. POST (Power-On Self-Test): After the computer is powered on, the CPU first executes the initialization code in the firmware (BIOS or UEFI), completing hardware self-testing and basic device configuration.

  2. Firmware Boot Stage: After POST completes, the firmware locates the boot device according to the boot order.

  • In BIOS mode, the firmware reads the boot code from the disk's Master Boot Record (MBR) or Volume Boot Record (VBR);

  • In UEFI mode, the firmware loads an EFI application from the EFI System Partition (ESP). FreeBSD's UEFI boot program is located at /EFI/freebsd/loader.efi.

  1. Boot Loader Stage: FreeBSD's boot loader is divided into four stages (in BIOS mode: boot0/boot1/boot2/loader, in UEFI mode: loader.efi). Among them, boot0 is stage 0 (boot manager), boot1 and boot2 are stages 1 and 2, and loader is stage 3. The final stage loader(8) is an interactive boot loader that reads the /boot/loader.conf configuration file, loads the kernel and modules, and then transfers control to the kernel.

  2. Kernel Initialization Stage: After the kernel is loaded, it first probes hardware and initializes devices, then mounts the root file system and starts the init(8) process. init(8) is always the first user space process started by the kernel, and its process ID (PID) is always 1.

init(8) signal parameters (BSD init does not use the System V runlevel mechanism):

Signal
Action

SIGUSR1

Halt

SIGUSR2

Halt and power off (requires hardware support)

SIGWINCH

Halt, power off, then reboot (requires hardware support)

SIGTERM

Terminate multi-user operation and enter single-user mode

SIGINT

Terminate all processes and reboot the system

SIGTSTP

Prevent further logins (reboot(8) and halt(8) send this signal before shutdown to prevent new logins)

SIGHUP

Re-read the ttys(5) file

Note:

If the secure level is enabled too early (greater than 1), it may prevent fsck(8) from repairing inconsistent file systems. It is recommended to set the secure level at the end of /etc/rc. When running init(8) in a Jail, the secure level is set independently for the Jail and does not affect the host system.

  1. User Space Initialization Stage: init(8) reads the /etc/rc script, which starts system services according to the configuration in /etc/rc.conf, ultimately bringing the system into multi-user mode.

FreeBSD Boot Process Under Traditional Boot (BIOS + MBR)

Boot Manager (Stage 0)

boot0cfg only applies to BIOS/MBR boot mode and is not applicable to UEFI systems (UEFI uses efibootmgr(8)).

The boot manager code in the MBR is sometimes referred to as stage 0 of the boot process. By default, FreeBSD uses the boot0 boot manager.

The MBR installed by the FreeBSD installer is based on /boot/boot0. Due to the limitations of the partition table and the 0x55AA identifier at the end of the MBR, the size and functionality of boot0 are limited to 446 bytes.

Tip

At the end of the MBR, there is also a two-byte signature field with the value 0x55AA, known as the Sector Marker. This field typically also marks the end of Extended Boot Records (EBR) and boot sectors.

If boot0 and multiple operating systems are installed, a message similar to the following will be displayed at boot time:

References

Stage 1 and Stage 2

Conceptually, stage 1 and stage 2 are components of the same program residing in the same disk area. Due to space constraints, they are divided into two parts but are always installed together.

They are copied by the FreeBSD installer from /boot/boot.

These two stages reside outside the file system, in the first track of the boot partition, starting from the first sector. This is where boot0 or other boot managers look for the subsequent boot program.

Stage 1's boot1 is very simple due to its 512-byte size limitation. It knows just enough about the FreeBSD bsdlabel (which stores partition information) to find and execute boot2.

Stage 2's boot2 is slightly more complex; it can recognize the FreeBSD file system and find files within it. It provides a simple interface for selecting the kernel or loader to run. It runs the loader, which is more complex and capable of reading boot configuration files. If the boot process is interrupted at stage 2, the following interactive screen will be displayed:

Stage 3 (loader)

The loader is the final stage of the stage 3 boot process. It resides on the file system, typically at /boot/loader.

The loader provides an interactive configuration method using a built-in command set, supplemented by a more powerful interpreter that has a more complex command set. Starting from FreeBSD 12.0, the default script interpreter is Lua (previously Forth), while a Simple interpreter is retained to support pure built-in commands.

During initialization, the loader probes the console and disks, and determines which disk to boot from. It sets variables accordingly and starts an interpreter through which users can pass commands via scripts or interactively.

The loader then reads /boot/loader.rc, which by default reads /boot/defaults/loader.conf (setting reasonable default values for variables) and /boot/loader.conf (for local changes to these variables). loader.rc then loads the selected modules and kernel based on these variables.

Finally, by default, the loader waits 10 seconds for a user keypress; if uninterrupted, it boots the kernel. If the user interrupts this process, a prompt supporting the command set will appear, where the user can adjust variables, unload all modules, load modules, and then boot or reboot.

Common built-in commands of the loader are as follows:

Command
Description

autoboot seconds

Continues booting the kernel if not interrupted within the given time span (seconds). It displays a countdown; the default time span is 10 seconds.

boot [-options] [kernelname]

Immediately boots the kernel, with any specified options or kernel name.

boot-conf

Re-performs automatic module configuration based on specified variables (most commonly kernel). This command only makes sense after using unload to change variables first.

help [topic]

Displays help messages read from /boot/loader.help.

include filename

Reads the specified file and interprets it line by line. Errors immediately abort the file inclusion.

load [-t type] filename

Loads a kernel, kernel module, or file of the given type.

ls [-l] [path]

Displays a list of files in the given path.

lsdev [-v]

Lists all devices from which modules may be loaded.

lsmod [-v]

Displays loaded modules.

more filename

Displays the specified file, pausing at each page.

reboot

Immediately reboots the system.

set variable, set variable=value

Sets the specified environment variable.

unload

Removes all loaded modules.

The following are several practical examples of using the loader.

Boot the default kernel in single-user mode:

Unload the default kernel and modules, then load the previous kernel or another specified kernel:

Use /boot/kernel/kernel to reference the default kernel that came with the installation, or use /boot/kernel.old/kernel to reference the previous kernel installed before a system upgrade or custom kernel configuration.

Use the following commands to load the default modules with another kernel. Note that the full path of the module does not need to be specified at this point:

Load an automated kernel configuration script:

Final Stage

After the kernel is loaded by the loader or boot2 (boot2 can bypass the loader and load the kernel directly), the kernel checks the boot flags and adjusts its behavior accordingly. Commonly used boot flags are as follows:

Option
Description

-a

During kernel initialization, prompt for the device to mount as the root file system.

-C

Boot the root file system from CDROM.

-s

Boot into single-user mode.

-v

Output more detailed information during kernel boot.

For more information about other boot flags, refer to boot(8).

After the kernel finishes booting, it transfers control to the user process init(8), which is located at /sbin/init, or the program path specified by the init_path variable in the loader. This is the final stage of the boot process.

The boot sequence ensures that the file systems available on the system are consistent. If a UFS file system is inconsistent and fsck cannot repair the inconsistencies, init will downgrade the system to single-user mode so that the system administrator can directly resolve the issue. If the file systems are fine, the system will boot into multi-user mode.

Single-User Mode

A user can specify single-user mode by booting with -s or by setting the boot_single variable in the loader. You can also enter single-user mode from multi-user mode by running shutdown now. Upon entering single-user mode, the following will be displayed:

If the user presses Enter, the system will enter the default POSIX shell. To specify a different shell, enter the full path of the shell.

Single-user mode is typically used to repair a system that cannot boot due to file system inconsistencies or boot configuration file errors. It can also be used to reset the root password when it is unknown. Since the single-user mode prompt provides complete local access to the system and its configuration files, these operations are possible. There is no network in this mode.

Although single-user mode is practical for repairing systems, it poses a security risk unless the system is in a physically secure location. By default, anyone who can gain physical access to the system and boot into single-user mode will have complete control over the system.

Multi-User Mode

If init finds the file systems are fine, or the user has completed operations in single-user mode and enters exit to leave single-user mode, the system enters multi-user mode and starts the system's resource configuration.

The resource configuration system reads default configuration from the /etc/defaults/rc.conf file and system-specific configuration from the /etc/rc.conf file. It then mounts the file systems listed in /etc/fstab and starts network services, system daemons, and startup scripts for locally installed packages.

For more information about the resource configuration system, refer to rc(8) and check the scripts in the /etc/rc.d directory.

Shutdown Process

When a controlled shutdown is performed using shutdown(8), init(8) attempts to run the script /etc/rc.shutdown, then sends the TERM signal to all processes, followed by the KILL signal to any processes that do not terminate in time.

Functionality and File Structure of loader.conf

loader.conf is the core configuration file in the FreeBSD system boot process; see loader.conf(5). This file is read during the boot loader loader(8) stage and is used to specify the kernel to boot, parameters to pass to the kernel, and additional modules to load. It can also set all variables supported by loader(8).

The file structure related to loader.conf(5) is as follows:

loader.conf is the core file for system boot configuration, located at /boot/loader.conf. Configuration written here takes effect earlier than the rc.conf file, but improper configuration may prevent the system from booting properly.

Note

It is not recommended to modify the /boot/defaults/loader.conf file directly. For custom configuration, use the /boot/loader.conf file or the /boot/loader.conf.local file to extend local settings. The /boot/loader.conf.local file has the highest priority and is specifically for machine-specific settings.

loader.conf Configuration for Standard ZFS Installation

In the standard ZFS installation scheme, the /boot/loader.conf file typically contains the following configuration (using 15.0-RELEASE as an example):

This file is automatically written by the bsdinstall(8) installer during system installation. Specifically, the usr.sbin/bsdinstall/scripts/zfsboot script writes the three configuration lines kern.geom.label.disk_ident.enable="0", kern.geom.label.gptid.enable="0", and zfs_enable="YES" respectively. Therefore, in systems using the standard ZFS installation scheme, these three lines constitute the entire initial content of the /boot/loader.conf file.

Content Structure and Description of the Default Configuration File

The default configuration file is located in the source code at stand/defaults/loader.conf. The following content is based on the version at loader.conf.5: "console" setting does not document multi-value possibility:

Configuring the Boot Selection Screen Timeout

The timeout for the boot selection screen is controlled by the autoboot_delay parameter, which defines the time the system waits for user intervention before automatically booting the default kernel.

To adjust the timeout, edit the /boot/loader.conf file and add the following entry:

Parameter description: 2 sets the system boot automatic boot delay to 2 seconds.

Simplifying Boot Output

Simplifying system boot output can be approached from multiple levels: reducing kernel loading messages at the boot loader level, disabling status messages during service startup, and optimizing wait logic in network configuration.

As shown in the figure below, after setting, you can see the FreeBSD boot Logo.

FreeBSD Boot Logo

References

Configuration and Application of the Console Screen Saver

By default, the console driver does not perform any special processing when the screen is idle. If the monitor needs to remain on and idle for long periods, a screen saver should be enabled to prevent burn-in.

Configuring the Screen Saver Using bsdconfig

The screen saver can be configured using the bsdconfig tool:

After executing the command, the following interface will be displayed:

Menu
Description

1 None Disable the screensaver

1 None Disable the screen saver

2 Blank Blank screen

2 Blank Display a blank screen

3 Beastie "BSD Daemon" animated screen saver (graphics)

3 Beastie "BSD Daemon" animated screen saver (graphics)

4 Daemon "BSD Daemon" animated screen saver (text)

4 Daemon "BSD Daemon" animated screen saver (text)

5 Dragon Dragon screensaver (graphics)

5 Dragon Dragon screen saver (graphics)

6 Fade Fade out effect screen saver

6 Fade Fade out effect screen saver

7 Fire Flames effect screen saver

7 Fire Flames effect screen saver

8 Green "Green" power saving mode (if supported by monitor)

8 Green "Green" power saving mode (if supported by monitor)

9 Logo FreeBSD "logo" animated screen saver (graphics)

9 Logo FreeBSD "logo" animated screen saver (graphics)

a Rain Rain drops screen saver

a Rain Rain drops screen saver

b Snake Draw a FreeBSD "snake" on your screen

b Snake Draw a FreeBSD "snake" on your screen

c Star A "twinkling stars" effect

c Star A "twinkling stars" effect

d Warp A "stars warping" effect

d Warp A "stars warping" effect

Timeout Set the screen saver timeout interval

Timeout Set the screen saver timeout interval

Select a screen saver style: In the main menu, select 7 Console, then select 5 Saver Configure the screen saver, and here select 3 Beastie "BSD Daemon" animated screen saver (graphics).

Set the screen timeout: In the main menu, select 7 Console, then select 5 Saver Configure the screen saver, then select Timeout Set the screen saver timeout interval. The unit is seconds.

Manual Configuration

You can also set the screen saver by manually editing the configuration file. Edit the /etc/rc.conf file and add the following configuration:

The available screen saver modules are as follows:

You can customize the boot loader logo to personalize the system boot interface. The following logos are available by default:

Logo Name
Description

fbsdbw

FreeBSD black and white logo

beastie

Little daemon color logo

beastiebw

Little daemon black and white logo

orb

Color Orb logo under UEFI

orbbw

Default black and white Orb logo

none

No logo

Using fbsdbw as an example, add the following to the /boot/loader.conf file:

The effect after reboot is as follows:

fbsdbw
beastie
beastiebw
orb
orbbw
none

References

Exercises

  1. Modify autoboot_delay to 0 and enable boot_mute, compare the output differences between two system boots, and analyze the design trade-offs of the boot loader between user experience and debugging needs.

  2. Review the source code of the /boot/loader.conf.d/ directory loading mechanism, create a custom configuration file and verify its priority relationship with the main configuration file, and analyze the impact of distributed configuration design on system management.

  3. Customize a BMP format boot logo to replace the default logo, and document the loading process and format requirements.

Previous14.4 Privilege Escalation ToolsNext15.2 Boot Messages (dmesg)

Last updated