2
BEFORE YOU INSTALL

Getting FreeBSD running on your computer isn’t enough, no matter how much that first install might satisfy you. It’s just as important that your install be successful. A successful install is one that works for its intended purpose. Servers have very different requirements than desktops, and a server’s intended function can completely change installation requirements. Proper planning before installing FreeBSD makes installations much less painful. On the downside, you’ll get much less experience in reinstalling FreeBSD because you’ll do each install only once. If mastering the installation program through exhaustive repeated practice is your main goal, skip this boring “thinking ahead” stuff and read the next chapter.

I’m assuming that you want to run FreeBSD in the real world, doing real work, in a real environment. This environment might be your laptop—while you might argue that your laptop isn’t a production system, I challenge you to erase all the data on it without backing up and then tell me it’s not a production system. If you’re installing on a system intended for destructive testing, and you’re truly indifferent to its fate, I still recommend following best practices so that you develop good habits.

Consider what hardware you need or have. Then decide how best to use that hardware, what filesystem you should use, and how to arrange your disks. Only then should you proceed to downloading and installing FreeBSD.

Before you even start the install, though, let’s look at a couple concepts you’ll hit throughout your FreeBSD experience: default files and universal configuration language (UCL).

First, however, you must understand FreeBSD’s default configuration filesystem.

Default Files

FreeBSD separates configuration files into default files and customization files. The default files contain variable assignments and aren’t intended to be edited; instead, they’re designed to be overridden by another file of the same name.

Default configurations are kept in a directory called default. For example, the boot loader configuration file is /boot/loader.conf, and the default configuration file is /boot/defaults/loader.conf. If you want to see a comprehensive list of loader variables, check the default configuration file.

During upgrades, the installer replaces the default configuration files but doesn’t touch your local configuration files. This separation ensures that your local changes remain intact while still allowing new values to be added to the system. FreeBSD adds features with every release, and its developers go to great lengths to ensure that changes to these files are backward compatible. This means that you won’t have to go through the upgraded configuration and manually merge in your changes; at most, you’ll have to check out the new defaults file for nifty configuration opportunities and new system features.

The loader configuration file is a good example of these files. The /boot/defaults/loader.conf file contains dozens of entries much like this:

verbose_loading="NO"            # Set to YES for verbose loader output

The variable verbose_loading defaults to NO. To change this setting, do not edit /boot/defaults/loader.conf—instead, add the line to /boot/loader.conf and change it there. Your /boot/loader.conf entries override the default setting, and your local configuration contains only your local changes. A sysadmin can easily see what changes have been made and how this system differs from the out-of-the-box configuration.

I encourage you to keep your configuration files in a version control system. If you have a global configuration management system like Ansible, that’s grand. Without such a system, a centralized repository using svn(1) or the loved-or-loathed git(1) will do. Even local revision control systems like rcs(1) can one day save your hide.

The default configuration mechanism appears throughout FreeBSD, especially in the core system configuration.

Configuration with UCL

The universal configuration language, or UCL, is a common library for managing Unix-style configuration files. FreeBSD uses UCL for core functions, such as the packaging system.

Any file that is in UCL can appear in one of several formats, such as the traditional variable = setting format most Unix programs use, YAML, or JSON. If you’ve configured any Unix software before, UCL won’t be a problem.

We’ll see examples of UCL-style configuration throughout this book. You don’t need to know the details of UCL at this time, merely that UCL is a thing in FreeBSD.

FreeBSD Hardware

FreeBSD supports a whole bunch of hardware, including different architectures and devices designed for each architecture. One of the Project’s goals is to support the most widely available hardware, and that list of hardware includes far more than the “personal computer.” Today’s fully supported Tier 1 hardware includes 32-bit and 64-bit versions of the Intel-style processor.

Most modern hardware uses 64-bit extensions to Intel’s classic 32-bit architecture. These extensions were created by AMD, and so the platform is called amd64. Most hardware built in the last decade uses the amd64 standard. While amd64 hardware will boot both 32-bit and 64-bit versions of FreeBSD, the 32-bit version contains a bunch of workarounds to support the hardware’s features and expanded address space. Run 64-bit FreeBSD on 64-bit hardware.

The traditional 32-bit IBM-compatible PC dominated computing for decades. FreeBSD supports that hardware with the i386 platform.¹ Use the i386 version of FreeBSD only on pure 32-bit hardware. FreeBSD offers limited support for a few other hardware platforms, calling them Tier 2 architectures. Some of these are increasingly popular, such as ARM. FreeBSD supports both 32-bit and 64-bit ARM CPUs with the arm and arm64 platforms. Support for 64-bit ARM hardware is improving rapidly, and you can expect ARM64 to become a Tier 1 platform soon. Other hardware platforms are on their way out and have been demoted to Tier 2 before being removed from the source tree. Additionally, you can run FreeBSD on PowerPC (ppc) and 64-bit Sparc (sparc64) hardware, which never made it up to Tier 1. Temporary breakage of bleeding-edge FreeBSD is acceptable on Tier 2 platforms. Tier 2 platforms might or might not have packages available.

You’ll also find Tier 3 platforms, which are highly experimental. RISCV hardware is at Tier 3.

Tier 4 includes barely supported platforms. Some of them are long obsolete and on their way out. The code still exists and could theoretically be resurrected, but nobody cares enough to do the work. Others might be on their way in but are not yet fully developed. Every platform that reaches a higher tier passes through Tier 4 on its way up.

FreeBSD supports many network cards, hard drive controllers, and other peripherals for each architecture. As many of these architectures use similar interfaces and hardware, this isn’t as much of a challenge as you might think: SATA is SATA anywhere, and an Intel Ethernet card doesn’t magically transform when you put it in an arm64 machine.

While FreeBSD runs just fine on ancient hardware, that hardware must be in acceptable condition. If your Pentium IV crashes because it has bad RAM, installing FreeBSD won’t stop the crashes.

FreeBSD supports most RAID controllers and includes software to manage most of them. However, I would encourage folks running the UFS filesystem to use FreeBSD’s RAID options rather than a hardware RAID controller. RAID controllers were created when managing storage redundancy was so computing intensive that it monopolized the host’s processor. Today’s computing hardware manages RAID without breaking a sweat. Additionally, RAID controllers use custom formats on hard drives. Often, the only device that can read those disks is another RAID controller of the exact same model. The unexpected demise of a RAID controller can leave you trawling dubious internet auctions in search of old controllers. And if you think those controllers are expensive new, wait until they’re five years old and the only folks willing to buy them are those truly desperate for that exact model! FreeBSD has a few different options for software RAID, and those disks can be read with any similar hardware.

If you’re using ZFS, the warnings against RAID controllers become “just don’t.” ZFS expects to have direct access to the disks. Using a RAID controller disables much of ZFS’s self-healing and error-correction abilities. If you must use a RAID controller, disable RAID and have it serve as a storage controller. While many RAID cards claim they can act as a RAID controller, most actually serve up a bunch of one-drive RAID containers. Verify that your RAID controller can be shifted to just-a-bunch-of-disks (JBOD) or host-bus-adapter (HBA) mode before deploying ZFS on it.

This book uses amd64 as a reference platform. Everything should work on a 32-bit i386 host, but amd64 is the world’s standard these days, so we’ll use it. The test systems include a couple of iXsystems storage servers and a variety of virtual machines.²

Proprietary Hardware

Some hardware vendors believe that keeping their hardware interfaces secret prevents competitors from copying their designs and breaking into their market. This has repeatedly been demonstrated to be terrible strategy, especially as the flood of generic parts has largely drowned these secretive hardware manufacturers. A few vendors still cling to their secrecy, however. We call such devices proprietary hardware.

Developing device drivers for a piece of hardware without its interface specifications is quite difficult. Some hardware can be well supported without full documentation and is sufficiently common to make struggling through this lack of documentation worthwhile.

If a FreeBSD developer has a piece of hardware, documentation for that hardware, and interest in that hardware, he’ll probably implement support for it. If not, that hardware won’t work on FreeBSD. In most cases, unsupported proprietary hardware can be easily replaced with less expensive and more open options.

Some vendors provide closed-source binary drivers for their hardware in the form of kernel modules (see Chapter 6). Remember that while FreeBSD refers to the kernel as modular, that means that you can choose which parts to load and which to leave out. Once a kernel module is loaded, that module has complete access to the entire kernel. It’s entirely possible for a video driver kernel module to corrupt your filesystem. I strongly encourage you to avoid binary drivers whenever possible, and to avoid hardware that requires such drivers.

Hardware Requirements

Once upon a time, a host’s minimal hardware requirements were a big deal. FreeBSD 1.0 supported very specific hard drive controllers and Ethernet adapters, and needed several megabytes of RAM. Hardware that couldn’t run FreeBSD was still in common use back then.

Most hardware requirements are a thing of the past. Any amd64 system ever produced can run FreeBSD. Any server-grade i386 system built this millennium can run FreeBSD. Yes, a Pentium with a meager 18GB SCSI-2 disk and a paltry 128MB of RAM offers mediocre performance, but if you want good performance, try not using that hardware.

Just because a piece of hardware should work doesn’t mean it will work. “Inexpensive” is not the same as “cheap.” Supported lousy hardware is still lousy. Research your hardware before buying it.

FreeBSD runs fine on hypervisors, such as VMware, VirtualBox, Xen, and KVM. Legitimate cloud providers offer FreeBSD images and ISOs. FreeBSD runs just fine on the integrated bhyve(8) hypervisor and OpenBSD’s vmm(8). You can do a base install with 128MB of RAM and 1GB of disk, although you’ll probably want more than that for serious experimentation.

BIOS versus EFI

Back in the 1980s, IBM invented the basic input/output system (BIOS) to handle low-level hardware tasks, like finding the operating system. Generations of IT people have argued with the BIOS. BIOS had built-in limitations that keep it from working well on modern hardware, though. The modern BIOS-like thing is called the Extensible Firmware Interface (EFI). EFI is far more flexible and powerful than the BIOS. FreeBSD boots just fine from EFI, and using EFI permits FreeBSD to do some interesting things, like full-disk encryption.

If your hardware supports EFI, use it. Only fall back to BIOS mode if FreeBSD exposes a bug in your hardware’s EFI implementation, in which case I’d encourage you to file a bug (see Chapter 24). Note that the hardware setup utility might call BIOS mode “legacy boot” or “ancient crap” or some such thing.

Disks and Filesystems

Perhaps the most critical part of installing a system is how you allocate disk space and which filesystem you use. A base install of FreeBSD fits in about half a gigabyte of disk, but the filesystem beneath those files dictates much of how the system behaves.

FreeBSD Filesystems

FreeBSD supports two major filesystems, UFS and ZFS. Which should you use? That depends entirely on what you want to do with your system. To make a decision before booting your install media, you’ll need to understand the basics of each.

FreeBSD’s Unix File System (UFS) is a direct descendant of the filesystem shipped with 4.4 BSD and has been under continuous development for decades. One of UFS’s original authors still hangs around the FreeBSD community actively improving the filesystem, as well as offering support and guidance to newer generations of developers. UFS’s place as the primordial FreeBSD filesystem has let it extend fingers throughout the operating system. Many other FreeBSD filesystems attach to the kernel’s virtual memory system through infrastructure created for UFS. UFS is designed to handle the most common situations effectively while reliably supporting unusual configurations. FreeBSD ships with UFS configured to be as widely useful as possible on modern hardware, but you can choose to optimize a partition for trillions of tiny files or a handful of 1TB files if you desire.

ZFS (not an acronym) was introduced by Solaris in 2005 and integrated into FreeBSD in 2007. Its youth seems to be a disadvantage, but it combines technologies and concepts that have been used for much longer. ZFS computes a checksum of every block of data or metadata and can use it for error correction. Storage is pooled, meaning that you can dynamically add more disks to an existing ZFS filesystem without recreating the filesystem. ZFS has a whole bunch of cool features, such as highly effective built-in replication and the ability to create and remove datasets (partitions) on the fly.

While ZFS was written over a decade ago, it was written for future hardware. All of those cool features impose a performance cost, and ZFS can use a whole bunch of memory. While 32-bit systems can use ZFS, it’s not recommended. I resist running ZFS on hosts with less than 4GB of RAM and refuse to run it on less than 2GB of RAM. UFS serves small and embedded systems better than ZFS can.

ZFS makes a great storage system for a virtualization server, but it isn’t necessarily right for virtual machines that use disk images. Many virtual machines don’t get enough memory to effectively run ZFS. Additionally, I’ve seen more than one KVM-based virtualization system fail to migrate ZFS-based virtual machines. If you want to use ZFS on virtualized clients, be sure your virtualization system supports restoring and migrating ZFS disk images before installing a slew of hosts.

Some people insist that ZFS requires ECC RAM. ECC RAM is good, and you should get it if you can. ZFS without ECC is no worse than UFS with ECC, however. ECC provides a layer of integrity checks much like ZFS. If a host’s non-ECC memory gets hit by a cosmic ray, ZFS writes corrupt data to disk—just as if you used UFS.

Finally, ZFS assumes you’re doing things the ZFS way. ZFS is a combination filesystem and volume manager. It expects access to raw disks. Never, never, never use a RAID controller with ZFS; using RAID volumes as disks interferes with ZFS’s self-healing features. Many RAID controllers claim to offer raw disks, but what they really offer are one-disk RAID containers.³

UFS isn’t perfect either. A power failure or system crash can damage a UFS filesystem. Repairing that filesystem takes time and system memory. Roughly speaking, repairing each terabyte in a UFS filesystem requires 700MB of RAM. If you create a 7TB filesystem on a system with 6GB of RAM, FreeBSD can’t automatically repair it.

To boil this all down, on a modern amd64 laptop or a server, I recommend ZFS. Test ZFS with your virtualization system. If it works, use ZFS for 64-bit virtual machines with 4GB of RAM or greater. On i386 hardware or 64-bit hosts with less than 4GB of RAM, use UFS.

If you’re running a high-load, high-volume application and database, experiment with both UFS and ZFS on your production hardware to see which works better in your application before proceeding. Experiment with different arrangements of disks, ZFS pool types, and GEOM RAID methods. Some applications work better with UFS than ZFS. Netflix, for example, delivers all of its content from FreeBSD hosts with massive amounts of storage formatted with UFS. Before installing your massive storage server, review Chapter 12 for additional ZFS deployment considerations.

All this advice is secondary to an iron rule: choose the filesystem that best suits your environment.

Filesystem Encryption

Disk encryption has become a vital feature for many environments. A user that loses his laptop doesn’t want to lose his data. Certain organizations require that critical data be encrypted on resting, or inactive, disks. You can’t retroactively encrypt a disk on an installed system.

FreeBSD supports two disk encryption systems: GEOM-Based Disk Encryption (GBDE) and GELI. The gbde(8) encryption system is designed for use in situations where the mere existence of encrypted data can threaten the user’s life. It’s designed to protect a user who has a gun to their head. Thankfully, that use case is rare; this book doesn’t cover it.

The geli(8) encryption system protects against more common risks. If your laptop is stolen, GELI prevents the thief from reading the hard drive.⁴ If you store your company’s financial records on a GELI-encrypted partition, the service tech can’t read it during a service call. Chapter 23 covers GELI in more detail.

Many organizations require disks containing financial data or intellectual property to be rendered unreadable when decommissioned. You can send such disks to be shredded, but encrypting the disks at install time is equally effective. The disks become unreadable when you destroy the encryption key.

I recommend encrypting either the entire system or none of the system. Partially encrypted disks leave opportunities for skilled intruders to sabotage your system and subvert the encryption.

Decide whether or not you need encryption before proceeding.

Disk Partitioning Methods

Disk partitioning lets you divide a disk or disk array into logical units. Even hosts with average consumer-grade operating systems, such as the Windows laptop you’ll find at your local big-box store, ship with multiple partitions on the hard drive. A partitioning scheme is the system for organizing partitions on a disk.

Computing is always in transition between technologies, and right now we’re amidst a particularly annoying change in disk partitioning. Older and smaller hardware uses master boot record (MBR) partitioning and is always limited to disks of 2TB or smaller. Newer and larger hardware uses the more flexible and generally better GUID Partition Tables (GPT) scheme. FreeBSD manages both types of partition with gpart(8).

Which should you use in your install? Use GPT on any system that supports GPT, no matter the size of the disk. Use MBR if and only if the system can’t support GPT. (You can use gptboot(8) and gptzfsboot(8) to bludgeon GPT support onto MBR-only disks, but save that for your second or third install.)

I’ve encountered more than one system that supports GPT but has a hardware limitation that prevents it from using disks larger than 2TB. While MBR might seem sensible on such a system, remember that GPT is far more flexible. Even if you’re a sysadmin with decades of experience with MBR, learn and use GPT.

Partitioning with UFS

If you decide to use UFS for your host, you’ll need to consider filesystem partitioning. Thanks to the wide variety of disk sizes FreeBSD supports, the installer doesn’t attempt to predict how you’ll want to partition your system. Decide how to partition the disk before installing.

At a minimum, separate your operating system from your data. If this host is for user accounts, create a separate /home partition. If you’re running a database, create a partition for the database. Web servers should have a partition for web data and probably a second one for logs.

As an old Unix hand, I usually create separate /usr, /usr/local, /var, /var/log, and /home partitions, as well as a partition for root (/) and one for swap space, plus a separate partition for the server’s application data. I’m told that I’m a fuddy-duddy, though, and that my concerns about rogue processes and users filling up the hard drive are obsolete these days.⁵

A base install of modern FreeBSD fits in about half a gigabyte. That’s trivial next to today’s hard drives. On a modern disk running on real hardware, assigning 20GB for the operating system and related programs should be more than sufficient.

If you’re running FreeBSD on modern hardware, though, you probably want to use ZFS rather than UFS.

Multiple Operating Systems

Back in the Stone Age (roughly 2001), being able to install four operating systems on a single 6GB hard drive thrilled me. This was the only way to run multiple operating systems on a desktop without swapping hard drives.

It’s still possible to do multiboot installations, but virtualization is far better. You don’t have to shut down your main operating system to access one of the other operating systems. The bhyve(8) hypervisor lets you run other operating systems, including Microsoft Windows, on top of FreeBSD. Other operating systems have hypervisors that let you run FreeBSD on top of them.

Multiple Hard Drives

If you have multiple hard drives in your host, you should almost certainly use them to create some sort of storage redundancy. If you’re using ZFS, use a mirror or some sort of RAID-Z (see Chapter 12). If you use UFS, FreeBSD supports software RAID. When you have a whole bunch of hard drives, though, life gets a little more complicated.

The rule of thumb is still to separate your operating system from your application data. If you have 30 hard drives, mirror 2 of them for your operating system install and use the others for your data. Like all rules of thumb, this is debatable. But no sysadmin will tell you that this is an actively bad idea.

With many hard drives, consider which data passes through which disk controller. If a disk controller dies, what happens to your system? If both of your operating system disks are attached to a single controller and the controller dies, your host goes down. Putting each drive on a different controller offers redundancy. Ideally, attach your mirrored operating system disks to different drive controllers.

Also, remember that SATA disk controllers split all their data throughput among all the hard drives connected to them. If you have two disks on a SATA controller, each disk works, on average, about half as fast as it would work alone on the same channel. Port multipliers add disks but slash per-disk performance.

Swap Space

When FreeBSD (and any other modern operating system) uses up all the physical RAM, it can move information that’s been sitting idle from memory into swap. Now that even laptops ship with 32GB of RAM, it’s hard to imagine a host running out of memory, but never underestimate a program’s ability to devour RAM. Virtual systems might be allocated very tiny amounts of RAM.

So, how much swap space do you need? This is a matter of long debate between sysadmins. The short answer is, “It depends.” What does it depend on? Everything. Long-running wisdom claimed that a host should have twice as much swap as it has physical memory, but today that’s not only obsolete but dangerous. When a process starts catastrophically allocating memory—say, in a bug caused by an infinite loop—the kernel kills the process once the system runs out of virtual memory. A system with 32GB of RAM and 64GB of swap has 96GB of virtual memory. The i386 platform limits memory usage to 512MB per process, which means that the kernel stops such runaway processes pretty quickly. 64-bit systems, like amd64, have vast virtual memory spaces. A system thrashing gigabytes of memory between disk and RAM will be excruciatingly slow. A modern host should have only enough swap space to perform its task.

Multiple hard drives let you increase the efficiency of swap space by splitting it between disks on different drive controllers. Remember, though, that a crash dump must fit entirely within a single swap partition. FreeBSD compresses crash dumps so that they don’t take up as much room, but still, many small swap partitions can be counterproductive. If you have a large number of drives, don’t use the application drives for swap; restrain swap space to the operating system drives.

The main use for swap on modern systems is to have a place to store a memory dump should the system panic and crash. FreeBSD uses kernel minidumps, so they dump only the kernel memory. A minidump is much smaller than a full dump: a host with 8GB RAM has an average minidump size of about 250MB. Provisioning a gigabyte of swap per 10GB of RAM should be sufficient for most situations.

If you have a truly intractable problem, though, you might need to dump the entire contents of your RAM to swap. If I’m setting up an important production system, I always create an unused partition larger than the host’s greatest possible virtual memory space and tell the host to dump the kernel to that partition. If my laptop has such a problem, I’ll just plug in a flash drive and configure the system to dump on it instead.

Getting FreeBSD

Now that you’ve made all your decisions, you need a copy of FreeBSD. If this is your first time installing FreeBSD, go to https://www.FreeBSD.org/ and look for the Get FreeBSD section at the top. Right by that, you’ll see a list of supported releases, including (probably) two releases recommended for production. Sometimes there’s one. Sometimes there’s three, but usually two.

FreeBSD Versions

Two production releases? What madness is this?

FreeBSD development occurs in multiple tracks, as I will discuss in Chapter 18. A few tracks coexist, in various states of support. Each track receives bugfixes and incremental improvements. Newer tracks get new features.

As I write this, FreeBSD.org lists two production releases, numbered 11.0 and 10.4. Version 11.0 is the most recently released version, but it’s also a .0 release. It’s the first release on this track. It will have the newest features, but it has the greatest likelihood of including unknown bugs. Version 10.4 is slightly older and lacks some features in version 11.0, but it’s the fourth release along that track. It’s not guaranteed to be bug free, but many people have run it in production for months or years. Any screamingly obvious problems have been fixed.

Every FreeBSD release eventually reaches End of Life (EoL) and loses support. The security team stops producing patches and new packages are no longer available. The older release will reach EoL before the newer version. If you install FreeBSD 10.4 today, you’ll need to upgrade to 11 at some point—but by then, you’ll be upgrading to something that’s not a .0 release.

FreeBSD averages two production releases at a time. This isn’t an inviolate rule, only observed behavior. Sometime around when the 12.0 release escapes, the 10 branch will reach EoL.

I personally will run FreeBSD .0 releases, but having been burned with other operating systems before, I sympathize with the folks who categorically reject .0 versions. If you’ve never used FreeBSD before, I recommend installing the most recent production release. It has the latest device drivers and newest features.

Follow the download link and grab your chosen version.

Choosing Installation Images

You can choose between several different formats of FreeBSD installation media. All installation media is available both compressed with xz(1) and uncompressed. If you can conveniently extract .xz files, download the compressed versions. This saves the donated bandwidth and reduces download time. Any modern operating system can either handle .xz files natively or has add-on software for the task.

FreeBSD offers two styles of installation media. The first contains only enough to boot the FreeBSD installer and bring up the network. The installer then downloads the operating system files from a FreeBSD mirror site. If you’re going to do multiple installs of the same FreeBSD version, though, you’re better off downloading an installer that includes the operating system files.

The installer comes in both optical disk (.iso) and flash (.img) formats. Choose the format that fits your system. If you’re installing a virtual machine, an ISO is probably simplest.

Each installer image starts with the word FreeBSD, the release, and the platform. If you’re downloading FreeBSD 12.0 for amd64 hardware, the installer images will all have names that start with FreeBSD-12.0-RELEASE-amd64. Right after that, the file identifies the installation type.

File endings are a tool to help you easily find what you need:

• Files ending in bootonly.iso are ISO images that boot the FreeBSD installer. Using them means downloading FreeBSD over the network.
• Files ending in disc1.iso are ISO images that contain the full FreeBSD installer. This image contains the operating system files.
• Files that end in mini-memstick.img are for flash drives. They boot the FreeBSD installer but download the operating system files over the network.
• Files that end in memstick.img are flash drive images that contain a complete FreeBSD install.

FreeBSD also provides much larger DVD images. These contain all of FreeBSD and a whole bunch of packages. They’re meant for people who want to use FreeBSD without internet access. Please remember that all of the FreeBSD Project’s bandwidth is donated; don’t download a massive DVD image unless you actually need it.

Once you have an installation image, you need to get it on actual boot media. Use your operating system’s built-in tools to burn the image to a physical disk. While Windows now includes CD burning as a built-in feature, it doesn’t include flash disk imaging. The FreeBSD Project recommends Image Writer for Windows (https://sourceforge.net/projects/win32diskimager/), a perfectly fine option. Bring up the program, select your flash drive and the image, and click Start.

Network Installs

If your installation media only boots the installer and you need to grab the FreeBSD distribution files over the network, you’ll need to configure the network while the installer is running. If your network runs DHCP, the installer should just pick up your network configuration. If not, your FreeBSD host will need a valid network configuration. Before starting the installer, gather:

• A valid IP address and netmask
• The default gateway for your network
• The nameserver IP addresses

If you must use a proxy server to reach the internet, you’ll need its configuration as well.

Armed with this information, you can install FreeBSD.