Synopsis #
The installer can partition disks and install a working base system, but it cannot decide whether the hardware, applications, recovery access, and storage plan fit the intended workload. A useful preflight check resolves those questions before any disk is modified.
This guide does not repeat the installer screens. It establishes the evidence needed to choose an image, recognize unsupported hardware, preserve existing data, and recover if networking or boot fails after installation.
Select a supported release #
Begin with Supported FreeBSD releases , whose dates are maintained from the official support table . A supported release receives applicable security advisories and errata. Development snapshots and release candidates serve different purposes and should not be selected as a shortcut to newer hardware support on a system that needs predictable maintenance.
Read all three documents for the intended release:
- release notes describe important changes;
- hardware notes identify supported architectures and devices;
- errata records late-breaking problems and workarounds.
For 15.1-RELEASE, these are the release notes , hardware notes , and errata .
Inventory the hardware #
Record the exact controller and device identities rather than the product model alone. A laptop name such as “ThinkPad” does not identify its Wi-Fi, graphics, audio, or storage controller.
From an existing BSD or Linux installation, save equivalent information for:
- CPU architecture and firmware mode;
- storage controllers and target disks;
- Ethernet and Wi-Fi chipsets;
- graphics adapter and display outputs;
- audio, webcam, Bluetooth, and other required peripherals.
When FreeBSD can be booted without installing, inspect its view of the system:
$ uname -m
$ pciconf -lv
$ usbconfig list
$ ifconfig -l
$ sysctl hw.model hw.physmem
Search the installed manual pages for driver names reported by pciconf. The absence of a device from ifconfig -l or mixer tools is evidence to investigate, not proof that a configuration file is missing.
For a desktop or laptop, continue with the hardware preflight , which separates live-environment evidence from the package-based graphics, browser, and desktop checks that require an installed test system.
Test the workload, not only boot #
A successful installer boot proves little about a daily workload. Test the facilities that would make the installation unusable if absent:
- Bring up the required network path.
- Confirm that the storage controller and every intended disk appear.
- Check graphics modes and console access.
- Exercise required USB, audio, and input devices where the live environment permits it.
- Verify that critical applications exist as FreeBSD packages or have a documented alternative.
Containers that require Linux cgroups or namespaces do not become native FreeBSD workloads through the Linux binary compatibility layer. Decide whether a jail, bhyve virtual machine, remote service, or different host is required before replacing an existing development environment.
Identify every disk by more than position #
Record device size, model, serial number, and existing partition table:
# camcontrol devlist
# geom disk list
# gpart show
Device names can change when controllers or USB devices are added. Match the intended installation target by several attributes. Disconnecting unrelated removable or backup disks during installation reduces ambiguity.
Back up important data to another system or removable device and perform a restore check. A backup that has not been read does not justify repartitioning its source.
Decide the storage boundary #
Before starting bsdinstall, decide:
- whether the host will use ZFS or UFS;
- which data needs separate datasets or file systems;
- whether full-disk encryption is required;
- where swap belongs;
- where independent backups will be stored;
- whether dual boot or existing partitions must be preserved.
The storage-layout guide provides a decision framework. Automatic ZFS partitioning is suitable for many dedicated systems, but it should not replace an explicit decision when other operating systems or existing data share the disks.
Prepare recovery access #
Keep the installer media until the new system has booted, updated, and passed its workload checks. A remote server also needs an out-of-band console, a tested provider console, or a proven serial-console recovery path before firewall, network, loader, or upgrade changes are made. When ZFS boot environments are available, record the boot-environment recovery path before the first risky system change.
Record the following outside the machine being installed:
- firmware and boot-menu access;
- network addressing, VLAN, DNS, and gateway information;
- encryption recovery material;
- pool and dataset names;
- the location of backups and the first restore step.
The boot-path diagnostic guide records the evidence that distinguishes firmware, loader, kernel, root-filesystem, and service failures.