Keys are shown in bold to stand out from other text. Key combinations that are meant to be typed simultaneously are shown with + between the keys, such as:

Ctrl+Alt+Del

Meaning the user should type the Ctrl, Alt, and Del keys at the same time.

Keys that are meant to be typed in sequence will be separated with commas, for example:

Ctrl+X, Ctrl+S

Would mean that the user is expected to type the Ctrl and X keys simultaneously and then to type the Ctrl and S keys simultaneously.

Examples starting with C:\> indicate a MS-DOS® command. Unless otherwise noted, these commands may be executed from a "Command Prompt" window in a modern Microsoft® Windows® environment.

Examples starting with # indicate a command that must be invoked as the superuser in FreeBSD. You can login as root to type the command, or login as your normal account and use su(1) to gain superuser privileges.

Examples starting with % indicate a command that should be invoked from a normal user account. Unless otherwise noted, C-shell syntax is used for setting environment variables and other shell commands.

The applications to which FreeBSD can be put are truly limited only by your own imagination. From software development to factory automation, inventory control to azimuth correction of remote satellite antenna; if it can be done with a commercial UNIX® product then it is more than likely that you can do it with FreeBSD too! FreeBSD also benefits significantly from literally thousands of high quality applications developed by research centers and universities around the world, often available at little to no cost.

Because the source code for FreeBSD itself is freely available, the system can also be customized to an almost unheard-of degree for special applications or projects, and in ways not generally possible with operating systems from most major commercial vendors. Here is just a sampling of some of the applications in which people are currently using FreeBSD:

FreeBSD is available to download free of charge, or can be obtained on either CD-ROM or DVD. Please see Obtaining FreeBSD for more information about obtaining FreeBSD.

FreeBSD has been known for its web serving capabilities. A list of testimonials from companies basing their products and services on FreeBSD can be found at the FreeBSD Foundation website. Wikipedia also maintains a list of products based on FreeBSD.

The FreeBSD Project had its genesis in the early part of 1993, partially as the brainchild of the Unofficial 386BSDPatchkit’s last 3 coordinators: Nate Williams, Rod Grimes and Jordan Hubbard.

The original goal was to produce an intermediate snapshot of 386BSD in order to fix a number of problems that the patchkit mechanism was just not capable of solving. The early working title for the project was 386BSD 0.5 or 386BSD Interim in reference to that fact.

386BSD was Bill Jolitz’s operating system, which had been up to that point suffering rather severely from almost a year’s worth of neglect. As the patchkit swelled ever more uncomfortably with each passing day, they decided to assist Bill by providing this interim "cleanup" snapshot. Those plans came to a rude halt when Bill Jolitz suddenly decided to withdraw his sanction from the project without any clear indication of what would be done instead.

The trio thought that the goal remained worthwhile, even without Bill’s support, and so they adopted the name "FreeBSD" coined by David Greenman. The initial objectives were set after consulting with the system’s current users and, once it became clear that the project was on the road to perhaps even becoming a reality, Jordan contacted Walnut Creek CDROM with an eye toward improving FreeBSD’s distribution channels for those many unfortunates without easy access to the Internet. Walnut Creek CDROM not only supported the idea of distributing FreeBSD on CD but also went so far as to provide the project with a machine to work on and a fast Internet connection. Without Walnut Creek CDROM’s almost unprecedented degree of faith in what was, at the time, a completely unknown project, it is quite unlikely that FreeBSD would have gotten as far, as fast, as it has today.

The first CD-ROM (and general net-wide) distribution was FreeBSD 1.0, released in December of 1993. This was based on the 4.3BSD-Lite ("Net/2") tape from U.C. Berkeley, with many components also provided by 386BSD and the Free Software Foundation. It was a fairly reasonable success for a first offering, and they followed it with the highly successful FreeBSD 1.1 release in May of 1994.

Around this time, some rather unexpected storm clouds formed on the horizon as Novell and U.C. Berkeley settled their long-running lawsuit over the legal status of the Berkeley Net/2 tape. A condition of that settlement was U.C. Berkeley’s concession that three files of Net/2 were "encumbered" code and had to be removed as they were the property of Novell, who had in turn acquired it from AT&T some time previously. What Berkeley got in return was Novell’s "blessing" that the 4.4BSD-Lite release, when it was finally released, would be declared unencumbered and all existing Net/2 users would be strongly encouraged to switch. This included FreeBSD, and the project was given until the end of July 1994 to stop shipping its own Net/2 based product. Under the terms of that agreement, the project was allowed one last release before the deadline, that release being FreeBSD 1.1.5.1.

FreeBSD then set about the arduous task of literally re-inventing itself from a completely new and rather incomplete set of 4.4BSD-Lite bits. Although only three files having to do with System V shared memory and semaphores were removed, many other changes and bug fixes had been made to the BSD distribution, so it was a huge task to merge all the FreeBSD developments into 4.4BSD-Lite. It took the project until November of 1994 to make this transition, and in December it released FreeBSD 2.0 to the world. Despite being still more than a little rough around the edges, the release was a significant success and was followed by the more robust and easier to install FreeBSD 2.0.5 release in June of 1995.

Since that time, FreeBSD has made a series of releases each time improving the stability, speed, and feature set of the previous version.

For now, long-term development projects continue to take place in the 14.0-CURRENT (main) branch, and snapshot releases of 14.0 are continually made available from the snapshot server as work progresses.

The goals of the FreeBSD Project are to provide software that may be used for any purpose and without strings attached. Many of us have a significant investment in the code (and project) and would certainly not mind a little financial compensation now and then, but we are definitely not prepared to insist on it. We believe that our first and foremost "mission" is to provide code to any and all comers, and for whatever purpose, so that the code gets the widest possible use and provides the widest possible benefit. This is, I believe, one of the most fundamental goals of Free Software and one that we enthusiastically support.

That code in our source tree which falls under the GNU General Public License (GPL) or Library General Public License (LGPL) comes with slightly more strings attached, though at least on the side of enforced access rather than the usual opposite. Due to the additional complexities that can evolve in the commercial use of GPL software we do, however, prefer software submitted under the more relaxed BSD license when it is a reasonable option to do so.

The development of FreeBSD is a very open and flexible process, being literally built from the contributions of thousands of people around the world, as can be seen from our list of contributors. FreeBSD’s development infrastructure allows these thousands of contributors to collaborate over the Internet. We are constantly on the lookout for new volunteers, and those interested in becoming more closely involved should consult the article on Contributing to FreeBSD.

Useful things to know about the FreeBSD Project and its development process, whether working independently or in close cooperation:

In summary, our development model is organized as a loose set of concentric circles. The centralized model is designed for the convenience of the users of FreeBSD, who are provided with an easy way of tracking one central code base, not to keep potential contributors out! Our desire is to present a stable operating system with a large set of coherent application programs that the users can easily install and use - this model works very well in accomplishing that.

All we ask of those who would join us as FreeBSD developers is some of the same dedication its current people have to its continued success!

In addition to the base distributions, FreeBSD offers a ported software collection with thousands of commonly sought-after programs. The list of ports ranges from HTTP servers to games, languages, editors, and almost everything in between. There are about 36000 ports; the entire Ports Collection requires approximately 3 GB. To compile a port, you simply change to the directory of the program you wish to install, type make install, and let the system do the rest. The full original distribution for each port you build is retrieved dynamically so you need only enough disk space to build the ports you want.

Almost every port is also provided as a pre-compiled "package", which can be installed with a simple command (pkg install) by those who do not wish to compile their own ports from source. More information on packages and ports can be found in Installing Applications: Packages and Ports.

All supported FreeBSD versions provide an option in the installer to install additional documentation under /usr/local/share/doc/freebsd during the initial system setup. Documentation may also be installed later using packages:

For localized versions replace the "en" with the language prefix of choice. Be aware that some of the localised versions might be out of date and might contain information that is no longer correct or relevant. You may view the locally installed manuals with a web browser using the following URLs:

You can always find up to date documentation at The Documentation Portal.

The FreeBSD installer is not an application that can be run from within another operating system. Instead, download a FreeBSD installation file, burn it to the media associated with its file type and size (CD, DVD, or USB), and boot the system to install from the inserted media.

FreeBSD installation files are available at the FreeBSD download page. Each installation file’s name includes the release version of FreeBSD, the architecture, and the type of file.

Installation files are available in several formats, compressed with xz(1) or uncompressed. The formats vary depending on computer architecture and media type.

Installation file types:

After downloading the image file, download at least one checksum file from the same directory. There are two checksum files available, named after the release number and the architecture name. For example: CHECKSUM.SHA256-FreeBSD-13.1-RELEASE-amd64 and CHECKSUM.SHA512-FreeBSD-13.1-RELEASE-amd64.

After downloading one of the files (or both), calculate the checksum for the image file and compare it with the one shown in the checksum file. Note that you need to compare the calculated checksum against the correct file, as they correspond to two different algorithms: SHA256 and SHA512. FreeBSD provides sha256(1) and sha512(1) that can be used for calculating the checksum. Other operating systems have similar programs.

Verifying the checksum in FreeBSD can be done automatically using sha256sum(1) (and sha512sum(1)) by executing:

The checksums must match exactly. If the checksums do not match, the image file is corrupt and must be downloaded again.

Once the system boots from the installation media, a menu similar to the following will be displayed:

By default, the menu will wait ten seconds for user input before booting into the FreeBSD installer or, if FreeBSD is already installed, before booting into FreeBSD. To pause the boot timer in order to review the selections, press Space. To select an option, press its highlighted number, character, or key. The following options are available.

The boot options menu is divided into two sections. The first section can be used to either return to the main boot menu or to reset any toggled options back to their defaults.

The next section is used to toggle the available options to On or Off by pressing the option’s highlighted number or character. The system will always boot using the settings for these options until they are modified. Several options can be toggled using this menu:

After making the needed selections, press 1 or Backspace to return to the main boot menu, then press Enter to continue booting into FreeBSD. A series of boot messages will appear as FreeBSD carries out its hardware device probes and loads the installation program. Once the boot is complete, the welcome menu shown in Welcome Menu will be displayed.

Press Enter to select the default of Install to enter the installer. The rest of this chapter describes how to use this installer. Otherwise, use the right or left arrows or the colorized letter to select the desired menu item. The Shell can be used to access a FreeBSD shell in order to use command line utilities to prepare the disks before installation. The Live CD option can be used to try out FreeBSD before installing it. The live version is described in Using the Live CD.

Before starting the process, bsdinstall will load the keymap files as shown in Keymap Loading.

After the keymaps have been loaded, bsdinstall displays the menu shown in Keymap Selection Menu. Use the up and down arrows to select the keymap that most closely represents the mapping of the keyboard attached to the system. Press Enter to save the selection.

In addition, when selecting a different keymap, the user can try the keymap and ensure it is correct before proceeding, as shown in Keymap Testing Menu.

The next bsdinstall menu is used to set the hostname for the newly installed system.

Type in a hostname that is unique for the network. It should be a fully-qualified hostname, such as machine3.example.com.

Next, bsdinstall will prompt to select optional components to install.

Deciding which components to install will depend largely on the intended use of the system and the amount of disk space available. The FreeBSD kernel and userland, collectively known as the base system, are always installed. Depending on the architecture, some of these components may not appear:

The menu shown in Installing from the Network only appears when installing from a -bootonly.iso or -mini-memstick.img, as this installation media does not hold copies of the installation files. Since the installation files must be retrieved over a network connection, this menu indicates that the network interface must be configured first. If this menu is shown in any step of the process, remember to follow the instructions in Configuring Network Interfaces.

The default partition layout for file systems includes one file system for the entire system. When using UFS it may be worth considering the use of multiple file systems if you have sufficient disk space or multiple disks. When laying out file systems, remember that hard drives transfer data faster from the outer tracks to the inner. Thus, smaller and heavier-accessed file systems should be closer to the outside of the drive, while larger partitions like /usr should be placed toward the inner parts of the disk. It is a good idea to create partitions in an order similar to: /, swap, /var, and /usr.

The size of the /var partition reflects the intended machine’s usage. This partition is used to hold mailboxes, log files, and printer spools. Mailboxes and log files can grow to unexpected sizes depending on the number of users and how long log files are kept. On average, most users rarely need more than about a gigabyte of free disk space in /var.

The /usr partition holds many of the files which support the system, including the FreeBSD Ports Collection and system source code. At least 2 gigabytes of space is recommended for this partition. Also, note that home directories for users are placed in /usr/home by default, but can be placed on another partition. By default, /home is a symbolic link to /usr/home.

When selecting partition sizes, keep the space requirements in mind. Running out of space in one partition while barely using another can be a hassle.

As a rule of thumb, the swap partition should be about double the size of physical memory (RAM). Systems with minimal RAM (less for larger-memory configurations) may perform better with more swap. Configuring too little swap can lead to inefficiencies in the VM page scanning code and might create issues later if more memory is added.

On larger systems with multiple SCSI disks or multiple IDE disks operating on different controllers, it is recommended that swap be configured on each drive, up to four drives. The swap partitions should be approximately the same size. The kernel can handle arbitrary sizes, but internal data structures scale to 4 times the largest swap partition. Keeping the swap partitions near the same size will allow the kernel to optimally stripe swap space across disks. Large swap sizes may elicit a kernel warning message about the total configured swap. The limit is raised by increasing the amount of memory allowed for keeping track of swap allocations, as instructed by the warning message. It might be easier to recover from a runaway program before being forced to reboot.

By properly partitioning a system, fragmentation introduced in the smaller write-heavy partitions will not bleed over into the mostly read partitions. Keeping the write-loaded partitions closer to the disk’s edge will increase I/O performance in the partitions where it occurs the most. While I/O performance in the larger partitions may be needed, shifting them more toward the edge of the disk will not lead to a significant performance improvement over moving /var to the edge.

When this method is selected, a menu will display the available disk(s). If multiple disks are connected, choose the one where FreeBSD is to be installed.

Once the disk is selected, the next menu prompts to install to either the entire disk or to create a partition using free space. If Entire Disk is chosen, a general partition layout filling the whole disk is automatically created. Selecting Partition creates a partition layout from the unused space on the disk.

After the Entire Disk option is chosen, bsdinstall displays a dialog indicating that the disk will be erased.

The next menu shows a list with the available partition scheme types. GPT is usually the most appropriate choice for amd64 computers. Older computers that are not compatible with GPT should use MBR. The other partition schemes are generally used for uncommon or older computers. More information is available in Partitioning Schemes.

After the partition layout has been created, review it to ensure it meets the needs of the installation. Selecting Revert will reset the partitions to their original values. Pressing Auto will recreate the automatic FreeBSD partitions. Partitions can also be manually created, modified, or deleted. When the partitioning is correct, select Finish to continue with the installation.

Once the disks are configured, the next menu provides the last chance to make changes before the selected drives are formatted. If changes need to be made, select Back to return to the main partitioning menu. Revert & Exit exits the installer without making any changes to the drive. Otherwise, select Commit to start the installation process.

To continue with the installation process, go to Fetching Distribution Files.

Selecting this method opens the partition editor:

Highlight the installation drive (ada0 in this example) and select Create to display a menu of available partition schemes:

GPT is usually the most appropriate choice for amd64 computers. Older computers that are not compatible with GPT should use MBR. The other partition schemes are generally used for uncommon or older computers.

After the partitioning scheme has been selected and created, select Create again to create the partitions. The Tab key is used to move the cursor between fields.

A standard FreeBSD GPT installation uses at least three partitions, including either UFS or ZFS:

Refer to gpart(8) for descriptions of the available GPT partition types.

Multiple file system partitions can be created. Some people prefer a traditional layout with separate partitions for /, /var, /tmp, and /usr.

See Creating Traditional Split File System Partitions for an example.

The Size may be entered with common abbreviations: K for kilobytes, M for megabytes, or G for gigabytes.

A Mountpoint is needed if the partition will contain a file system. If only a single UFS partition will be created, the mountpoint should be /.

The Label is a name by which the partition will be known. Drive names or numbers can change if the drive is connected to a different controller or port, but the partition label does not change. Referring to labels instead of drive names and partition numbers in files like /etc/fstab makes the system more tolerant to hardware changes. GPT labels appear in /dev/gpt/ when a disk is attached. Other partitioning schemes have different label capabilities and their labels appear in different directories in /dev/.

After the custom partitions have been created, select Finish to continue with the installation and go to Fetching Distribution Files.

This partitioning mode only works with whole disks and will erase the contents of the entire disk. The main ZFS configuration menu offers a number of options to control the creation of the pool.

Here is a summary of the options in this menu:

Select T to configure the Pool Type and the disk(s) that will constitute the pool.

Here is a summary of the Pool Type that can be selected in this menu:

Once a Pool Type has been selected, a list of available disks is displayed, and the user is prompted to select one or more disks to make up the pool. The configuration is then validated to ensure that enough disks are selected. If validation fails, select <Change Selection> to return to the list of disks or <Back> to change the Pool Type.

If one or more disks are missing from the list, or if disks were attached after the installer was started, select - Rescan Devices to repopulate the list of available disks.

To avoid accidentally erasing the wrong disk, the - Disk Info menu can be used to inspect each disk, including its partition table and various other information such as the device model number and serial number, if available.

Select N to configure the Pool Name. Enter the desired name, then select <OK> to establish it or <Cancel> to return to the main menu and leave the default name.

Select S to set the amount of swap. Enter the desired amount of swap, then select <OK> to establish it or <Cancel> to return to the main menu and let the default amount.

Once all options have been set to the desired values, select the >>> Install option at the top of the menu. The installer then offers a last chance to cancel before the contents of the selected drives are destroyed to create the ZFS pool.

If GELI disk encryption was enabled, the installer will prompt twice for the passphrase to be used to encrypt the disks. Initialization of the encryption then begins.

The installation then proceeds normally. To continue with the installation, go to Fetching Distribution Files.

When creating advanced installations, the bsdinstall partitioning menus may not provide the level of flexibility required. Advanced users can select the Shell option from the partitioning menu in order to manually partition the drives, create the file system(s), populate /tmp/bsdinstall_etc/fstab, and mount the file systems under /mnt. Once this is done, type exit to return to bsdinstall and continue the installation.

First, the root password must be set. While entering the password, the characters being typed are not displayed on the screen. The password must be entered twice to prevent typing errors.

Next, a list of the network interfaces found on the computer is shown. Select the interface to configure.

If an Ethernet interface is selected, the installer will skip ahead to the menu shown in Choose IPv4 Networking. If a wireless network interface is chosen, the system will instead scan for wireless access points:

Wireless networks are identified by a Service Set Identifier (SSID); a short, unique name given to each network. SSIDs found during the scan are listed, followed by a description of the encryption types available for that network. If the desired SSID does not appear in the list, select Rescan to scan again. If the desired network still does not appear, check for problems with antenna connections or try moving the computer closer to the access point. Rescan after each change is made.

Next, enter the encryption information for connecting to the selected wireless network. WPA2 encryption is strongly recommended over older encryption types such as WEP, which offer little security. If the network uses WPA2, input the password, also known as the Pre-Shared Key (PSK). For security reasons, the characters typed into the input box are displayed as asterisks.

Next, choose whether or not an IPv4 address should be configured on the Ethernet or wireless interface:

There are two methods of IPv4 configuration. DHCP will automatically configure the network interface correctly and should be used if the network provides a DHCP server. Otherwise, the addressing information needs to be input manually as a static configuration.

If a DHCP server is available, select Yes in the next menu to automatically configure the network interface. The installer will appear to pause for a minute or so as it finds the DHCP server and obtains the addressing information for the system.

If a DHCP server is not available, select No and input the following addressing information in this menu:

The next screen will ask if the interface should be configured for IPv6. If IPv6 is available and desired, choose Yes to select it.

IPv6 also has two methods of configuration. StateLess Address AutoConfiguration (SLAAC) will automatically request the correct configuration information from a local router. Refer to rfc4862 for more information. Static configuration requires manual entry of network information.

If an IPv6 router is available, select Yes in the next menu to automatically configure the network interface. The installer will appear to pause for a minute or so as it finds the router and obtains the addressing information for the system.

If an IPv6 router is not available, select No and input the following addressing information in this menu:

The last network configuration menu is used to configure the Domain Name System (DNS) resolver, which converts hostnames to and from network addresses. If DHCP or SLAAC was used to autoconfigure the network interface, the Resolver Configuration values may already be filled in. Otherwise, enter the local network’s domain name in the Search field. DNS #1 and DNS #2 are the IPv4 and/or IPv6 addresses of the DNS servers. At least one DNS server is required.

Once the interface is configured, select a mirror site that is located in the same region of the world as the computer on which FreeBSD is being installed. Files can be retrieved more quickly when the mirror is close to the target computer, reducing installation time.

The next series of menus are used to determine the correct local time by selecting the geographic region, country, and time zone. Setting the time zone allows the system to automatically correct for regional time changes, such as daylight savings time, and perform other time zone related functions properly.

The example shown here is for a machine located in the mainland time zone of Spain, Europe. The selections will vary according to the geographical location.

The appropriate region is selected using the arrow keys and then pressing Enter.

Select the appropriate country using the arrow keys and press Enter.

The appropriate time zone is selected using the arrow keys and pressing Enter.

Confirm the abbreviation for the time zone is correct.

The appropriate date is selected using the arrow keys and then pressing Set Date. Otherwise, the date selection can be skipped by pressing Skip.

The appropriate time is selected using the arrow keys and then pressing Set Time. Otherwise, the time selection can be skipped by pressing Skip.

The next menu is used to configure which system services will be started whenever the system boots. All of these services are optional. Only start the services that are needed for the system to function.

Here is a summary of the services that can be enabled in this menu:

The next menu is used to configure which security options will be enabled. All of these options are optional. But their use is encouraged.

Here is a summary of the options that can be enabled in this menu:

The next menu prompts to create at least one user account. It is recommended to log into the system using a user account rather than as root. When logged in as root, there are essentially no limits or protection on what can be done. Logging in as a normal user is safer and more secure.

Select Yes to add new users.

Follow the prompts and input the requested information for the user account. The example shown in Enter User Information creates the asample user account.

Here is a summary of the information to input:

After entering all the details, a summary is shown for review. If a mistake was made, enter no to correct it. Once everything is correct, enter yes to create the new user.

If there are more users to add, answer the Add another user? question with yes. Enter no to finish adding users and continue the installation.

For more information on adding users and user management, see Users and Basic Account Management.

After everything has been installed and configured, a final chance is provided to modify settings.

Use this menu to make any changes or to do any additional configuration before completing the installation.

Once configuration is complete, select Exit.

bsdinstall will prompt for any additional configuration that needs to be done before rebooting into the new system. Select Yes to exit to a shell within the new system or No to proceed to the last step of the installation.

If further configuration or special setup is needed, select Live CD to boot the install media into Live CD mode.

If the installation is complete, select Reboot to reboot the computer and start the new FreeBSD system. Do not forget to remove the FreeBSD install media or the computer might boot from it again.

As FreeBSD boots, informational messages are displayed. After the system finishes booting, a login prompt is displayed. At the login: prompt, enter the username added during the installation. Avoid logging in as root. Refer to The Superuser Account for instructions on how to become the superuser when administrative access is needed.

The messages that appear during boot can be reviewed by pressing Scroll-Lock to turn on the scroll-back buffer. The PgUp, PgDn, and arrow keys can be used to scroll back through the messages. When finished, press Scroll-Lock again to unlock the display and return to the console. To review these messages once the system has been up for some time, type less /var/run/dmesg.boot from a command prompt. Press q to return to the command line after viewing.

If sshd was enabled in Selecting Additional Services to Enable, the first boot might be a bit slower as the system generates SSH host keys. Subsequent boots will be faster. The fingerprints of the keys are then displayed as in the following example:

Refer to OpenSSH for more information about fingerprints and SSH.

FreeBSD does not install a graphical environment by default. Refer to The X Window System for more information about installing and configuring a graphical window manager.

Proper shutdown of a FreeBSD computer helps protect data and hardware from damage. Do not turn off the power before the system has been properly shut down! If the user is a member of the wheel group, become the superuser by typing su at the command line and entering the root password. Then, type shutdown -p now and the system will shut down cleanly, and, if the hardware supports it, turn itself off.

While the system console can be used to interact with the system, a user working from the command line at the keyboard of a FreeBSD system will typically instead log into a virtual console. This is because system messages are configured by default to display on the system console. These messages will appear over the command or file that the user is working on, making it difficult to concentrate on the work at hand.

By default, FreeBSD is configured to provide several virtual consoles for inputting commands. Each virtual console has its own login prompt and shell and it is easy to switch between virtual consoles. This essentially provides the command line equivalent of having several windows open at the same time in a graphical environment.

The key combinations Alt+F1 through Alt+F8 have been reserved by FreeBSD for switching between virtual consoles. Use Alt+F1 to switch to the system console (ttyv0), Alt+F2 to access the first virtual console (ttyv1), Alt+F3 to access the second virtual console (ttyv2), and so on. When using Xorg as a graphical console, the combination becomes Ctrl+Alt+F1 to return to a text-based virtual console.

When switching from one console to the next, FreeBSD manages the screen output. The result is an illusion of having multiple virtual screens and keyboards that can be used to type commands for FreeBSD to run. The programs that are launched in one virtual console do not stop running when the user switches to a different virtual console.

Refer to kbdcontrol(1), vidcontrol(1), atkbd(4), syscons(4), and vt(4) for a more technical description of the FreeBSD console and its keyboard drivers.

In FreeBSD, the number of available virtual consoles is configured in this section of /etc/ttys:

To disable a virtual console, put a comment symbol (#) at the beginning of the line representing that virtual console. For example, to reduce the number of available virtual consoles from eight to four, put a # in front of the last four lines representing virtual consoles ttyv5 through ttyv8. Do not comment out the line for the system console ttyv0. Note that the last virtual console (ttyv8) is used to access the graphical environment if Xorg has been installed and configured as described in The X Window System.

For a detailed description of every column in this file and the available options for the virtual consoles, refer to ttys(5).

The FreeBSD boot menu provides an option labelled as "Boot Single User". If this option is selected, the system will boot into a special mode known as "single user mode". This mode is typically used to repair a system that will not boot or to reset the root password when it is not known. While in single user mode, networking and other virtual consoles are not available. However, full root access to the system is available, and by default, the root password is not needed. For these reasons, physical access to the keyboard is needed to boot into this mode and determining who has physical access to the keyboard is something to consider when securing a FreeBSD system.

The settings which control single user mode are found in this section of /etc/ttys:

By default, the status is set to secure. This assumes that who has physical access to the keyboard is either not important or it is controlled by a physical security policy. If this setting is changed to insecure, the assumption is that the environment itself is insecure because anyone can access the keyboard. When this line is changed to insecure, FreeBSD will prompt for the root password when a user selects to boot into single user mode.

The FreeBSD console default video mode may be adjusted to 1024x768, 1280x1024, or any other size supported by the graphics chip and monitor. To use a different video mode load the VESA module:

To determine which video modes are supported by the hardware, use vidcontrol(1). To get a list of supported video modes issue the following:

The output of this command lists the video modes that are supported by the hardware. To select a new video mode, specify the mode using vidcontrol(1) as the root user:

If the new video mode is acceptable, it can be permanently set on boot by adding it to /etc/rc.conf:

Since all access to the FreeBSD system is achieved using accounts and all processes are run by users, user and account management is important.

There are three main types of accounts: system accounts, user accounts, and the superuser account.

FreeBSD provides a variety of different commands to manage user accounts. The most common commands are summarized in Utilities for Managing User Accounts, followed by some examples of their usage. See the manual page for each utility for more details and usage examples.

A group is a list of users. A group is identified by its group name and GID. In FreeBSD, the kernel uses the UID of a process, and the list of groups it belongs to, to determine what the process is allowed to do. Most of the time, the GID of a user or process usually means the first group in the list.

The group name to GID mapping is listed in /etc/group. This is a plain text file with four colon-delimited fields. The first field is the group name, the second is the encrypted password, the third the GID, and the fourth the comma-delimited list of members. For a more complete description of the syntax, refer to group(5).

The superuser can modify /etc/group using a text editor, although editing the group file using vigr(8) is preferred because it can catch some common mistakes. Alternatively, pw(8) can be used to add and edit groups. For example, to add a group called teamtwo and then confirm that it exists:

In this example, 1100 is the GID of teamtwo. Right now, teamtwo has no members. This command will add jru as a member of teamtwo.

The argument to -M is a comma-delimited list of users to be added to a new (empty) group or to replace the members of an existing group. To the user, this group membership is different from (and in addition to) the user’s primary group listed in the password file. This means that the user will not show up as a member when using groupshow with pw(8), but will show up when the information is queried via id(1) or a similar tool. When pw(8) is used to add a user to a group, it only manipulates /etc/group and does not attempt to read additional data from /etc/passwd.

In this example, the argument to -m is a comma-delimited list of users who are to be added to the group. Unlike the previous example, these users are appended to the group and do not replace existing users in the group.

In this example, jru is a member of the groups jru and teamtwo.

For more information about this command and the format of /etc/group, refer to pw(8) and group(5).

Symbolic permissions use characters instead of octal values to assign permissions to files or directories. Symbolic permissions use the syntax of (who) (action) (permissions), where the following values are available:

These values are used with chmod(1), but with letters instead of numbers. For example, the following command would block both members of the group associated with FILE and all other users from accessing FILE:

A comma separated list can be provided when more than one set of changes to a file must be made. For example, the following command removes the group and "world" write permission on FILE, and adds the execute permissions for everyone:

In addition to file permissions, FreeBSD supports the use of "file flags". These flags add an additional level of security and control over files, but not directories. With file flags, even root can be prevented from removing or altering files.

File flags are modified using chflags(1). For example, to enable the system undeletable flag on the file file1, issue the following command:

To disable the system undeletable flag, put a "no" in front of the sunlink:

To view the flags of a file, use -lo with ls(1):

Several file flags may only be added or removed by the root user. In other cases, the file owner may set its file flags. Refer to chflags(1) and chflags(2) for more information.

Other than the permissions already discussed, there are three other specific settings that all administrators should know about. They are the setuid, setgid, and sticky permissions.

These settings are important for some UNIX® operations as they provide functionality not normally granted to normal users. To understand them, the difference between the real user ID and effective user ID must be noted.

The real user ID is the UID who owns or starts the process. The effective UID is the user ID the process runs as. As an example, passwd(1) runs with the real user ID when a user changes their password. However, in order to update the password database, the command runs as the effective ID of the root user. This allows users to change their passwords without seeing a Permission Denied error.

The setuid permission may be added symbolically by adding the s permission for the user as in the following example:

The setuid permission may also be set by prefixing a permission set with the number four (4) as shown in the following example:

The permissions on suidexample.sh now look like the following:

Note that a s is now part of the permission set designated for the file owner, replacing the executable bit. This allows utilities which need elevated permissions, such as passwd(1).

To view this in real time, open two terminals. On one, type passwd as a normal user. While it waits for a new password, check the process table and look at the user information for passwd(1):

In terminal A:

In terminal B:

Although passwd(1) is run as a normal user, it is using the effective UID of root.

The setgid permission performs the same function as the setuid permission; except that it alters the group settings. When an application or utility executes with this setting, it will be granted the permissions based on the group that owns the file, not the user who started the process.

To set the setgid permission on a file symbolically, add the s permission for the group with chmod(1):

Alternatively, provide chmod(1) with a leading two (2):

In the following listing, notice that the s is now in the field designated for the group permission settings:

The setuid and setgid permission bits may lower system security, by allowing for elevated permissions. The third special permission, the sticky bit, can strengthen the security of a system.

When the sticky bit is set on a directory, it allows file deletion only by the file owner. This is useful to prevent file deletion in public directories, such as /tmp, by users who do not own the file. To utilize this permission, add the t mode to the file:

Alternatively, prefix the permission set with a one (1):

The sticky bit permission will display as a t at the very end of the permission set:

Directories and files are stored in a file system. Each file system contains exactly one directory at the very top level, called the root directory for that file system. This root directory can contain other directories. One file system is designated the root file system or /. Every other file system is mounted under the root file system. No matter how many disks are on the FreeBSD system, every directory appears to be part of the same disk.

Consider three file systems, called A, B, and C. Each file system has one root directory, which contains two other directories, called A1, A2 (and likewise B1, B2 and C1, C2).

Call A the root file system. If ls(1) is used to view the contents of this directory, it will show two subdirectories, A1 and A2. The directory tree looks like this:

A file system must be mounted on to a directory in another file system. When mounting file system B on to the directory A1, the root directory of B replaces A1, and the directories in B appear accordingly:

Any files that are in the B1 or B2 directories can be reached with the path /A1/B1 or /A1/B2 as necessary. Any files that were in /A1 have been temporarily hidden. They will reappear if B is unmounted from A.

If B had been mounted on A2 then the diagram would look like this:

and the paths would be /A2/B1 and /A2/B2 respectively.

File systems can be mounted on top of one another. Continuing the last example, the C file system could be mounted on top of the B1 directory in the B file system, leading to this arrangement:

Or C could be mounted directly on to the A file system, under the A1 directory:

It is entirely possible to have one large root file system, and not need to create any others. There are some drawbacks to this approach, and one advantage.

File systems are contained in partitions. Disks are divided into partitions using one of several partitioning schemes; see Manual Partitioning. The newer scheme is GPT; older BIOS-based computers use MBR. GPT supports division of a disk into partitions with a size, offset, and type. It supports a large number of partitions and partition types, and is recommended whenever its use is possible. GPT partitions use the disk name with a suffix, where the suffix is p1 for the first partition, p2 for the second, and so on. MBR, however, supports only a small number of partitions. The MBR partitions are known in FreeBSD as slices. Slices may be used for different operating systems. FreeBSD slices are subdivided into partitions using BSD labels (see bsdlabel(8)).

Slice numbers follow the device name, prefixed with an s, starting at 1. So "da0s1" is the first slice on the first SCSI drive. There can only be four physical slices on a disk, but there can be logical slices inside physical slices of the appropriate type. These extended slices are numbered starting at 5, so "ada0s5" is the first extended slice on the first SATA disk. These devices are used by file systems that expect to occupy a slice.

Each GPT or BSD partition can contain only one file system, which means that file systems are often described by either their typical mount point in the file system hierarchy, or the name of the partition they are contained in.

FreeBSD also uses disk space for swap space to provide virtual memory. This allows your computer to behave as though it has much more memory than it actually does. When FreeBSD runs out of memory, it moves some of the data that is not currently being used to the swap space, and moves it back in (moving something else out) when it needs it. This is called paging.

Some BSD partitions have certain conventions associated with them.

Slices and "dangerously dedicated" physical drives contain BSD partitions, which are represented as letters from a to h. This letter is appended to the device name, so "da0a" is the a partition on the first da drive, which is "dangerously dedicated". "ada1s3e" is the fifth partition in the third slice of the second SATA disk drive.

Finally, each disk on the system is identified. A disk name starts with a code that indicates the type of disk, and then a number, indicating which disk it is. Unlike partitions and slices, disk numbering starts at 0. Common codes are listed in Disk Device Names.

When referring to a partition in a slice, include the disk name, s, the slice number, and then the partition letter. Examples are shown in Sample Disk, Slice, and Partition Names. GPT partitions include the disk name, p, and then the partition number.

Conceptual Model of a Disk shows a conceptual model of a disk layout using MBR slices.

When installing FreeBSD, configure the disk slices if using MBR, and create partitions within the slice to be used for FreeBSD. If using GPT, configure partitions for each file system. In either case, create a file system or swap space in each partition, and decide where each file system will be mounted. See gpart(8) for information on manipulating partitions.

During the boot process (The FreeBSD Booting Process), file systems listed in /etc/fstab are automatically mounted except for the entries containing noauto. This file contains entries in the following format:

Refer to fstab(5) for more information on the format of /etc/fstab and its options.

File systems are mounted using mount(8). The most basic syntax is as follows:

A file system listed in /etc/fstab can also be mounted by providing just the mountpoint.

This command provides many options which are described in mount(8). The most commonly used options include:

The following options can be passed to -o as a comma-separated list:

To unmount a file system use umount(8). This command takes one parameter which can be a mountpoint, device name, -a or -A.

All forms take -f to force unmounting, and -v for verbosity. Be warned that -f is not generally a good idea as it might crash the computer or damage data on the file system.

To unmount all mounted file systems, or just the file system types listed after -t, use -a or -A. Note that -A does not attempt to unmount the root file system.

To see the processes running on the system, use ps(1) or top(1). To display a static list of the currently running processes, their PIDs, how much memory they are using, and the command they were started with, use ps(1). To display all the running processes and update the display every few seconds in order to interactively see what the computer is doing, use top(1).

By default, ps(1) only shows the commands that are running and owned by the user. For example:

The output from ps(1) is organized into a number of columns. The PID column displays the process ID. PIDs are assigned starting at 1, go up to 99999, then wrap around back to the beginning. However, a PID is not reassigned if it is already in use. The TT column shows the tty the program is running on and STAT shows the program’s state. TIME is the amount of time the program has been running on the CPU. This is usually not the elapsed time since the program was started, as most programs spend a lot of time waiting for things to happen before they need to spend time on the CPU. Finally, COMMAND is the command that was used to start the program.

A number of different options are available to change the information that is displayed. One of the most useful sets is auxww, where a displays information about all the running processes of all users, u displays the username and memory usage of the process' owner, x displays information about daemon processes, and ww causes ps(1) to display the full command line for each process, rather than truncating it once it gets too long to fit on the screen.

The output from top(1) is similar:

The output is split into two sections. The header (the first five or six lines) shows the PID of the last process to run, the system load averages (which are a measure of how busy the system is), the system uptime (time since the last reboot) and the current time. The other figures in the header relate to how many processes are running, how much memory and swap space has been used, and how much time the system is spending in different CPU states. If the ZFS file system module has been loaded, an ARC line indicates how much data was read from the memory cache instead of from disk.

Below the header is a series of columns containing similar information to the output from ps(1), such as the PID, username, amount of CPU time, and the command that started the process. By default, top(1) also displays the amount of memory space taken by the process. This is split into two columns: one for total size and one for resident size. Total size is how much memory the application has needed and the resident size is how much it is actually using now.

top(1) automatically updates the display every two seconds. A different interval can be specified with -s.

One way to communicate with any running process or daemon is to send a signal using kill(1). There are a number of different signals; some have a specific meaning while others are described in the application’s documentation. A user can only send a signal to a process they own and sending a signal to someone else’s process will result in a permission denied error. The exception is the root user, who can send signals to anyone’s processes.

The operating system can also send a signal to a process. If an application is badly written and tries to access memory that it is not supposed to, FreeBSD will send the process the "Segmentation Violation" signal (SIGSEGV). If an application has been written to use the alarm(3) system call to be alerted after a period of time has elapsed, it will be sent the "Alarm" signal (SIGALRM).

Two signals can be used to stop a process: SIGTERM and SIGKILL. SIGTERM is the polite way to kill a process as the process can read the signal, close any log files it may have open, and attempt to finish what it is doing before shutting down. In some cases, a process may ignore SIGTERM if it is in the middle of some task that cannot be interrupted.

SIGKILL cannot be ignored by a process. Sending a SIGKILL to a process will usually stop that process there and then. ^[1].

Other commonly used signals are SIGHUP, SIGUSR1, and SIGUSR2. Since these are general purpose signals, different applications will respond differently.

For example, after changing a web server’s configuration file, the web server needs to be told to re-read its configuration. Restarting httpd would result in a brief outage period on the web server. Instead, send the daemon the SIGHUP signal. Be aware that different daemons will have different behavior, so refer to the documentation for the daemon to determine if SIGHUP will achieve the desired results.

The easiest way to permanently change the default shell is to use chsh. Running this command will open the editor that is configured in the EDITOR environment variable, which by default is set to vi(1). Change the Shell: line to the full path of the new shell.

Alternately, use chsh -s which will set the specified shell without opening an editor. For example, to change the shell to bash:

Enter your password at the prompt and press Return to change your shell. Log off and log in again to start using the new shell.

The UNIX® shell is not just a command interpreter, it acts as a powerful tool which allows users to execute commands, redirect their output, redirect their input and chain commands together to improve the final command output. When this functionality is mixed with built in commands, the user is provided with an environment that can maximize efficiency.

Shell redirection is the action of sending the output or the input of a command into another command or into a file. To capture the output of the ls(1) command, for example, into a file, redirect the output:

The directory contents will now be listed in directory_listing.txt. Some commands can be used to read input, such as sort(1). To sort this listing, redirect the input:

The input will be sorted and placed on the screen. To redirect that input into another file, one could redirect the output of sort(1) by mixing the direction:

In all of the previous examples, the commands are performing redirection using file descriptors. Every UNIX® system has file descriptors, which include standard input (stdin), standard output (stdout), and standard error (stderr). Each one has a purpose, where input could be a keyboard or a mouse, something that provides input. Output could be a screen or paper in a printer. And error would be anything that is used for diagnostic or error messages. All three are considered I/O based file descriptors and sometimes considered streams.

Through the use of these descriptors, the shell allows output and input to be passed around through various commands and redirected to or from a file. Another method of redirection is the pipe operator.

The UNIX® pipe operator, "|" allows the output of one command to be directly passed or directed to another program. Basically, a pipe allows the standard output of a command to be passed as standard input to another command, for example:

In that example, the contents of directory_listing.txt will be sorted and the output passed to less(1). This allows the user to scroll through the output at their own pace and prevent it from scrolling off the screen.

FreeBSD includes several applications and utilities produced by the Free Software Foundation (FSF). In addition to manual pages, these programs may include hypertext documents called info files. These can be viewed using info(1) or, if editors/emacs is installed, the info mode of emacs.

To use info(1), type:

For a brief introduction, type h. For a quick command reference, type ?.

All supported versions of FreeBSD now contain /usr/sbin/pkg a.k.a pkg(7). This is a small placeholder that has just the minimum functionality required to install the real pkg(8).

Run pkg(8) command line:

The output should be similar to the following:

pkg(7) will intercept the command, and if you confirm that is your intention, download the pkg(8) tarball, install pkg(8) from it, bootstrap the local package database and then proceed to run the command you originally requested.

More recent versions of pkg(7) understand pkg -N as a test to see if pkg(8) is installed without triggering the installation, and conversely, pkg bootstrap[-f] to install pkg(8) (or force it to be reinstalled) without performing any other actions.

Usage information for pkg is available in the pkg(8) manual page or by running pkg without additional arguments. Additional pkg configuration options are described in pkg.conf(5).

Each pkg command argument is documented in a command-specific manual page.

To read the manual page for pkg install, for example, run this command:

The rest of this section demonstrates common binary package management tasks which can be performed using pkg(8). Each demonstrated command provides many switches to customize its use. Refer to a command’s help or man page for details and more examples.

The Quarterly branch provides users with a more predictable and stable experience for port and package installation and upgrades. This is done essentially by only allowing non-feature updates. Quarterly branches aim to receive security fixes (that may be version updates, or backports of commits), bug fixes and ports compliance or framework changes. The Quarterly branch is cut from HEAD at the beginning of every (yearly) quarter in January, April, July, and October. Branches are named according to the year (YYYY) and quarter (Q1-4) they are created in. For example, the quarterly branch created in January 2023, is named 2023Q1. And the Latest branch provides the latest versions of the packages to the users.

To switch pkg(8) from Quarterly to Latest run the following commands:

Then run this command to update the local package repositories catalogues for the Latest branch:

pkg.conf(5) is the system-wide configuration file used by the pkg(8) tools. The default location of this file is /usr/local/etc/pkg.conf.

Lines in the file beginning with a "#" are comments and are ignored.

The file is in UCL format. For more information on the syntax of libucl(3), please visit the official UCL website.

The following types of options are recognized - boolean, string and list options.

A boolean option is marked as enabled if one of the following values is specified in the configuration file - YES, TRUE and ON.

To search a package pkg-search(8) can be used:

The output should be similar to the following:

To install a binary package pkg-install(8) can be used. This command uses repository data to determine which version of the software to install and if it has any uninstalled dependencies. For example, to install curl:

The output should be similar to the following:

The new package and any additional packages that were installed as dependencies can be seen in the installed packages list:

The output should be similar to the following:

To fetch a package and install it later or in another place use pkg-fetch(8). For example, to download nginx-lite:

The output should be similar to the following:

To install the downloaded packages pkg-install(8) can be used as follows:

Information about the packages installed on a system can be viewed by running pkg-info(8) which, when run without any switches, will list the package version for either all installed packages or the specified package.

For example, to see which version of pkg is installed, run:

The output should be similar to the following:

Installed packages can be upgraded to their latest versions using pkg-upgrade(8):

This command will compare the installed versions with those available in the repository catalogue and upgrade them from the repository.

Software vulnerabilities are regularly discovered in third-party applications. To address this, pkg includes a built-in auditing mechanism. To determine if there are any known vulnerabilities for the software installed on the system, use pkg-audit(8):

The output should be similar to the following:

Packages that are no longer needed can be removed with pkg-delete(8).

For example:

The output should be similar to the following:

Removing a package may leave behind dependencies which are no longer required. Unneeded packages that were installed as dependencies (leaf packages) can be automatically detected and removed using pkg-autoremove(8):

The output should be similar to the following:

Packages installed as dependencies are called automatic packages. Non-automatic packages, i.e the packages that were explicity installed not as a dependency to another package, can be listed using:

The output should be similar to the following:

pkg prime-list is an alias command declared in /usr/local/etc/pkg.conf. There are many others that can be used to query the package database of the system. For instance, command pkg prime-origins can be used to get the origin port directory of the list mentioned above:

The output should be similar to the following:

This list can be used to rebuild all packages installed on a system using build tools such as ports-mgmt/poudriere or ports-mgmt/synth.

Marking an installed package as automatic can be done using:

Once a package is a leaf package and is marked as automatic, it gets selected by pkg autoremove.

Marking an installed package as not automatic can be done using:

Unlike the traditional package management system, pkg includes its own package database backup mechanism. This functionality is enabled by default.

To restore the contents of a previous package database backup, run the following command replacing /path/to/pkg.sql with the location of the backup:

To run a manual backup of the pkg database, run the following command, replacing /path/to/pkg.sql with a suitable file name and location:

By default, pkg stores binary packages in a cache directory defined by PKG_CACHEDIR in pkg.conf(5). Only copies of the latest installed packages are kept. Older versions of pkg kept all previous packages. To remove these outdated binary packages, run:

The entire cache may be cleared by running:

pkg-lock(8) is used to lock packages against reinstallation, modification or deletion. pkg-unlock(8) unlocks the named packages. Either variant only has an effect on currently installed packages. Consequently it is impossible to block installation of a new package by using this mechanism, unless such an installation implies updating a locked package.

For example, to lock nginx-lite:

And to unlock nginx-lite:

Software within the FreeBSD Ports Collection can undergo major version number changes. To address this, pkg has a built-in command to update package origins. This can be useful, for example, if lang/python3 is renamed to lang/python311 so that lang/python3 can now represent version 3.11.

To change the package origin for the above example, run:

As another example, to update lang/ruby31 to lang/ruby32, run:

Before an application can be compiled using a port, the Ports Collection must first be installed. If it was not installed during the installation of FreeBSD, use one of the following methods to install it:

This section provides basic instructions on using the Ports Collection to install or remove software. The detailed description of available make targets and environment variables is available in ports(7).

Using the Ports Collection assumes a working Internet connection. It also requires superuser privilege.

To compile and install the port, change to the directory of the port to be installed, then type make install at the prompt. Messages will indicate the progress:

Since lsof is a program that runs with increased privileges, a security warning is displayed as it is installed. Once the installation is complete, the prompt will be returned.

Some shells keep a cache of the commands that are available in the directories listed in the PATH environment variable, to speed up lookup operations for the executable file of these commands. Users of the tcsh shell should type rehash so that a newly installed command can be used without specifying its full path. Use hash -r instead for the sh shell. Refer to the documentation for the shell for more information.

During installation, a working subdirectory is created which contains all the temporary files used during compilation. Removing this directory saves disk space and minimizes the chance of problems later when upgrading to the newer version of the port:

Installed ports can be uninstalled using pkg delete. Examples for using this command can be found in the pkg-delete(8) manual page.

Alternately, make deinstall can be run in the port's directory:

It is recommended to read the messages as the port is uninstalled. If the port has any applications that depend upon it, this information will be displayed but the uninstallation will proceed. In such cases, it may be better to reinstall the application in order to prevent broken dependencies.

Over time, newer versions of software become available in the Ports Collection. This section describes how to determine which software can be upgraded and how to perform the upgrade.

To determine if newer versions of installed ports are available, ensure that the latest version of the ports tree is installed, using the updating command described in "Git Method". The following command will list the installed ports which are out of date:

Using the Ports Collection will use up disk space over time. After building and installing a port, running make clean within the ports skeleton will clean up the temporary work directory. If Portmaster is used to install a port, it will automatically remove this directory unless -K is specified. If Portupgrade is installed, this command will remove all work directories found within the local copy of the Ports Collection:

In addition, outdated source distribution files accumulate in /usr/ports/distfiles over time. To use Portupgrade to delete all the distfiles that are no longer referenced by any ports:

Portupgrade can remove all distfiles not referenced by any port currently installed on the system:

If Portmaster is installed, use:

By default, this command is interactive and prompts the user to confirm if a distfile should be deleted.

In addition to these commands, ports-mgmt/pkg_cutleaves automates the task of removing installed ports that are no longer needed.

After configuration, initialize poudriere so that it installs a jail with the required FreeBSD tree and a ports tree. Specify a name for the jail using -j and the FreeBSD version with -v. On systems running FreeBSD/amd64, the architecture can be set with -a to either i386 or amd64. The default is the architecture shown by uname.

On a single computer, poudriere can build ports with multiple configurations, in multiple jails, and from different port trees. Custom configurations for these combinations are called sets. See the CUSTOMIZATION section of poudriere(8) for details after ports-mgmt/poudriere or ports-mgmt/poudriere-devel is installed.

The basic configuration shown here puts a single jail-, port-, and set-specific make.conf in /usr/local/etc/poudriere.d. The filename in this example is created by combining the jail name, port name, and set name: 13amd64-local-workstation-make.conf. The system make.conf and this new file are combined at build time to create the make.conf used by the build jail.

Packages to be built are entered in 13amd64-local-workstation-pkglist:

Options and dependencies for the specified ports are configured:

Finally, packages are built and a package repository is created:

While running, pressing Ctrl+t displays the current state of the build. Poudriere also builds files in /poudriere/logs/bulk/jailname that can be used with a web server to display build information.

After completion, the new packages are now available for installation from the poudriere repository.

For more information on using poudriere, see poudriere(8) and the main web site, https://github.com/freebsd/poudriere/wiki.

While it is possible to use both a custom repository along side of the official repository, sometimes it is useful to disable the official repository. This is done by creating a configuration file that overrides and disables the official configuration file. Create /usr/local/etc/pkg/repos/FreeBSD.conf that contains the following:

Usually it is easiest to serve a poudriere repository to the client machines via HTTP. Set up a webserver to serve up the package directory, for instance: /usr/local/poudriere/data/packages/13amd64, where 13amd64 is the name of the build.

If the URL to the package repository is: http://pkg.example.com/13amd64, then the repository configuration file in /usr/local/etc/pkg/repos/custom.conf would look like:

Intel® Graphics refers to the class of graphics chips that are integrated on the same die as an Intel® CPU. Wikipedia offers a good overview of the variations and names used for generations of Intel HD Graphics.

The graphics/drm-kmod package indirectly provides a range of kernel modules for use with Intel® Graphics cards. The Intel® driver can be installed by executing the following command:

Then add the module to /etc/rc.conf file, executing the following command:

The graphics/drm-kmod package indirectly provides a range of kernel modules for use with AMD® Graphics cards. The modules amdgpu and radeonkms can be used depending the generation of the hardware. The FreeBSD project maintains an AMD graphics support matrix to determine which driver must be used.

AMD® driver can be installed by executing the following command:

For post-HD7000 or Tahiti graphic cards add the module to /etc/rc.conf file, executing the following command:

For older graphic cards (pre-HD7000 or pre-Tahiti) add the module to /etc/rc.conf file, executing the following command:

FreeBSD supports different versions of the proprietary NVIDIA® driver. Users of newer graphics cards should install the x11/nvidia-driver package. Those with older cards will have to check below which version supports them.

The latest NVIDIA® driver can be installed by running the following command:

Then add the module to /etc/rc.conf file, executing the following command:

Xorg looks in several directories for configuration files. /usr/local/etc/X11/ is the recommended directory for these files on FreeBSD. Using this directory helps keep application files separate from operating system files.

It is easier to use multiple files that each configure a specific setting than the traditional single xorg.conf. These files are stored in the /usr/local/etc/X11/xorg.conf.d/ subdirectory.

The driver for the graphics card can be specified in the /usr/local/etc/X11/xorg.conf.d/ directory.

To configure the Intel® driver in a configuration file:

To configure the AMD® driver in a configuration file:

To configure the NVIDIA® driver in a configuration file:

To configure the VESA driver in a configuration file:

To configure the SCFB driver in a configuration file:

To configure multiple video cards, the BusID can be added. A list of video card bus IDs can be displayed by executing:

The output should be similar to the following:

Almost all monitors support the Extended Display Identification Data standard (EDID). Xorg uses EDID to communicate with the monitor and detect the supported resolutions and refresh rates. Then it selects the most appropriate combination of settings to use with that monitor.

Other resolutions supported by the monitor can be chosen by setting the desired resolution in configuration files, or after the X server has been started with xrandr(1).

Xorg supports the vast majority of input devices via x11/libinput.

For example, to configure the keyboard layout:

The URW font collection (x11-fonts/urwfonts) includes high quality versions of standard type1 fonts (Times Roman™, Helvetica™, Palatino™ and others). The Freefonts collection (x11-fonts/freefonts) includes many more fonts, but most of them are intended for use in graphics software such as the Gimp, and are not complete enough to serve as screen fonts. In addition, Xorg can be configured to use TrueType® fonts with a minimum of effort. For more details on this, see the X(7) manual page or TrueType® Fonts.

To install the above Type1 font collections from binary packages, run the following commands:

And likewise with the freefont or other collections. To have the X server detect these fonts, add an appropriate line to the X server configuration file (/usr/local/etc/X11/xorg.conf.d/90-fonts.conf), which reads:

Alternatively, at the command line in the X session run:

This will work but will be lost when the X session is closed, unless it is added to the startup file (~/.xinitrc for a normal startx session, or ~/.xsession when logging in through a graphical login manager like XDM). A third way is to use the new /usr/local/etc/fonts/local.conf as demonstrated in Anti-Aliased Fonts.

Xorg has built in support for rendering TrueType® fonts. There are two different modules that can enable this functionality. The freetype module is used in this example because it is more consistent with the other font rendering back-ends. To enable the freetype module just add the following line to the "Module" section of /usr/local/etc/X11/xorg.conf.d/90-fonts.conf.

Now make a directory for the TrueType® fonts (for example, /usr/local/share/fonts/TrueType) and copy all of the TrueType® fonts into this directory. Keep in mind that TrueType® fonts cannot be directly taken from an Apple® Mac®; they must be in UNIX®/MS-DOS®/Windows® format for use by Xorg. Once the files have been copied into this directory, use mkfontscale to create a fonts.dir, so that the X font renderer knows that these new files have been installed. mkfontscale can be installed as a package:

Then create an index of X font files in a directory:

Now add the TrueType® directory to the font path. This is just the same as described in Type1 Fonts:

or add a FontPath line to xorg.conf.

Now Gimp, LibreOffice, and all of the other X applications should now recognize the installed TrueType® fonts. Extremely small fonts (as with text in a high resolution display on a web page) and extremely large fonts (within LibreOffice) will look much better now.

All fonts in Xorg that are found in /usr/local/share/fonts/ and ~/.fonts/ are automatically made available for anti-aliasing to Xft-aware applications. Most recent applications are Xft-aware, including KDE, GNOME, and Firefox.

To control which fonts are anti-aliased, or to configure anti-aliasing properties, create (or edit, if it already exists) the file /usr/local/etc/fonts/local.conf. Several advanced features of the Xft font system can be tuned using this file; this section describes only some simple possibilities. For more details, please see fonts-conf(5).

This file must be in XML format. Pay careful attention to case, and make sure all tags are properly closed. The file begins with the usual XML header followed by a DOCTYPE definition, and then the <fontconfig> tag:

As previously stated, all fonts in /usr/local/share/fonts/ as well as ~/.fonts/ are already made available to Xft-aware applications. To add another directory outside of these two directory trees, add a line like this to /usr/local/etc/fonts/local.conf:

After adding new fonts, and especially new font directories, rebuild the font caches:

Anti-aliasing makes borders slightly fuzzy, which makes very small text more readable and removes "staircases" from large text, but can cause eyestrain if applied to normal text. To exclude font sizes smaller than 14 point from anti-aliasing, include these lines:

Spacing for some monospaced fonts might also be inappropriate with anti-aliasing. This seems to be an issue with KDE, in particular. One possible fix is to force the spacing for such fonts to be 100. Add these lines:

(this aliases the other common names for fixed fonts as "mono"), and then add:

Certain fonts, such as Helvetica, may have a problem when anti-aliased. Usually this manifests itself as a font that seems cut in half vertically. At worst, it may cause applications to crash. To avoid this, consider adding the following to local.conf:

After editing local.conf, make certain to end the file with the </fontconfig> tag. Not doing this will cause changes to be ignored.

Users can add personalized settings by creating their own ~/.config/fontconfig/fonts.conf. This file uses the same XML format described above.

One last point: with an LCD screen, sub-pixel sampling may be desired. This basically treats the (horizontally separated) red, green and blue components separately to improve the horizontal resolution; the results can be dramatic. To enable this, add the line somewhere in local.conf:

For more information about how to install and configure fonts on FreeBSD, please read the article Fonts and FreeBSD.

KDE Plasma is an easy-to-use desktop environment. This desktop provides a suite of applications with a consistent look and feel, a standardized menu and toolbars, keybindings, color-schemes, internationalization, and a centralized, dialog-driven desktop configuration. More information on KDE can be found at the KDE homepage. For FreeBSD-specific information, consult the FreeBSD homepage at KDE.

GNOME is a user-friendly desktop environment. It includes a panel for starting applications and displaying status, a desktop, a set of tools and applications, and a set of conventions that make it easy for applications to cooperate and be consistent with each other.

XFCE is a desktop environment based on the GTK+, lightweight and provides a simple, efficient, easy-to-use desktop. It is fully configurable, has a main panel with menus, applets, and application launchers, provides a file manager and sound manager, and is themeable. Since it is fast, light, and efficient, it is ideal for older or slower machines with memory limitations.

The MATE Desktop Environment is the continuation of GNOME 2. It provides an intuitive and attractive desktop environment using traditional metaphors.

Cinnamon is a UNIX® desktop which provides advanced innovative features and a traditional user experience. The desktop layout is similar to Gnome 2. The underlying technology is forked from Gnome Shell. The emphasis is put on making users feel at home and providing them with an easy to use and comfortable desktop experience.

To install the Cinnamon package, execute:

LXQt is an advanced, easy-to-use, and fast desktop environment based on Qt technologies. It has been tailored for users who value simplicity, speed, and an intuitive interface. Unlike most desktop environments, LXQt also works fine with less powerful machines.