Index: head/en_US.ISO8859-1/books/handbook/bsdinstall/chapter.xml =================================================================== --- head/en_US.ISO8859-1/books/handbook/bsdinstall/chapter.xml (revision 50962) +++ head/en_US.ISO8859-1/books/handbook/bsdinstall/chapter.xml (revision 50963) @@ -1,2746 +1,2746 @@ Installing &os; Jim Mock Restructured, reorganized, and parts rewritten by Gavin Atkinson Updated for bsdinstall by Warren Block Allan Jude Updated for root-on-ZFS by Synopsis installation Beginning with &os; 9.0-RELEASE, &os; provides an easy to use, text-based installation program named bsdinstall. This chapter describes how to install &os; using bsdinstall. In general, the installation instructions in this chapter are written for the &i386; and AMD64 architectures. Where applicable, instructions specific to other platforms will be listed. There may be minor differences between the installer and what is shown here, so use this chapter as a general guide rather than as a set of literal instructions. Users who prefer to install &os; using a graphical installer may be interested in pc-sysinstall, the installer used by the TrueOS Project. It can be used to install either a graphical desktop (TrueOS) or a command line version of &os;. Refer to the TrueOS Users Handbook for details (https://www.trueos.org/handbook/trueos.html). After reading this chapter, you will know: The minimum hardware requirements and &os; supported architectures. How to create the &os; installation media. How to start bsdinstall. The questions bsdinstall will ask, what they mean, and how to answer them. How to troubleshoot a failed installation. How to access a live version of &os; before committing to an installation. Before reading this chapter, you should: Read the supported hardware list that shipped with the version of &os; to be installed and verify that the system's hardware is supported. Minimum Hardware Requirements The hardware requirements to install &os; vary by architecture. Hardware architectures and devices supported by a &os; release are listed on the &os; Release Information page. The &os; download page also has recommendations for choosing the correct image for different architectures. A &os; installation requires a minimum of 96 MB of RAM and 1.5 GB of free hard drive space. However, such small amounts of memory and disk space are really only suitable for custom applications like embedded appliances. General-purpose desktop systems need more resources. 2-4 GB RAM and at least 8 GB hard drive space is a good starting point. These are the processor requirements for each architecture: &arch.amd64; This is the most common desktop and laptop processor type, used in most modern systems. &intel; calls it Intel64. Other manufacturers sometimes call it x86-64. Examples of &arch.amd64; compatible processors include: &amd.athlon;64, &amd.opteron;, multi-core &intel; &xeon;, and &intel; &core; 2 and later processors. &arch.i386; Older desktops and laptops often use this 32-bit, x86 architecture. Almost all i386-compatible processors with a floating point unit are supported. All &intel; processors 486 or higher are supported. &os; will take advantage of Physical Address Extensions (PAE) support on CPUs with this feature. A kernel with the PAE feature enabled will detect memory above 4 GB and allow it to be used by the system. However, using PAE places constraints on device drivers and other features of &os;. Refer to &man.pae.4; for details. ia64 Currently supported processors are the &itanium; and the &itanium; 2. Supported chipsets include the HP zx1, &intel; 460GX, and &intel; E8870. Both Uniprocessor (UP) and Symmetric Multi-processor (SMP) configurations are supported. pc98 NEC PC-9801/9821 series with almost all i386-compatible processors, including 80486, &pentium;, &pentium; Pro, and &pentium; II, are all supported. All i386-compatible processors by AMD, Cyrix, IBM, and IDT are also supported. EPSON PC-386/486/586 series, which are compatible with NEC PC-9801 series, are supported. The NEC FC-9801/9821 and NEC SV-98 series should be supported. High-resolution mode is not supported. NEC PC-98XA/XL/RL/XL^2, and NEC PC-H98 series are supported in normal (PC-9801 compatible) mode only. The SMP-related features of &os; are not supported. The New Extend Standard Architecture (NESA) bus used in the PC-H98, SV-H98, and FC-H98 series, is not supported. &arch.powerpc; All New World ROM &apple; &mac; systems with built-in USB are supported. SMP is supported on machines with multiple CPUs. A 32-bit kernel can only use the first 2 GB of RAM. &arch.sparc64; Systems supported by &os;/&arch.sparc64; are listed at the FreeBSD/sparc64 Project. SMP is supported on all systems with more than 1 processor. A dedicated disk is required as it is not possible to share a disk with another operating system at this time. Pre-Installation Tasks Once it has been determined that the system meets the minimum hardware requirements for installing &os;, the installation file should be downloaded and the installation media prepared. Before doing this, check that the system is ready for an installation by verifying the items in this checklist: Back Up Important Data Before installing any operating system, always backup all important data first. Do not store the backup on the system being installed. Instead, save the data to a removable disk such as a USB drive, another system on the network, or an online backup service. Test the backup before starting the installation to make sure it contains all of the needed files. Once the installer formats the system's disk, all data stored on that disk will be lost. Decide Where to Install &os; If &os; will be the only operating system installed, this step can be skipped. But if &os; will share the disk with another operating system, decide which disk or partition will be used for &os;. In the &arch.i386; and &arch.amd64; architectures, disks can be divided into multiple partitions using one of two partitioning schemes. A traditional Master Boot Record (MBR) holds a partition table defining up to four primary partitions. For historical reasons, &os; calls these primary partition slices. One of these primary partitions can be made into an extended partition containing multiple logical partitions. The GUID Partition Table (GPT) is a newer and simpler method of partitioning a disk. Common GPT implementations allow up to 128 partitions per disk, eliminating the need for logical partitions. Some older operating systems, like &windows; XP, are not compatible with the GPT partition scheme. If &os; will be sharing a disk with such an operating system, MBR partitioning is required. The &os; boot loader requires either a primary or GPT partition. If all of the primary or GPT partitions are already in use, one must be freed for &os;. To create a partition without deleting existing data, use a partition resizing tool to shrink an existing partition and create a new partition using the freed space. A variety of free and commercial partition resizing tools are listed at http://en.wikipedia.org/wiki/List_of_disk_partitioning_software. GParted Live (http://gparted.sourceforge.net/livecd.php) is a free live CD which includes the GParted partition editor. GParted is also included with many other Linux live CD distributions. When used properly, disk shrinking utilities can safely create space for creating a new partition. Since the possibility of selecting the wrong partition exists, always backup any important data and verify the integrity of the backup before modifying disk partitions. Disk partitions containing different operating systems make it possible to install multiple operating systems on one computer. An alternative is to use virtualization () which allows multiple operating systems to run at the same time without modifying any disk partitions. Collect Network Information Some &os; installation methods require a network connection in order to download the installation files. After any installation, the installer will offer to setup the system's network interfaces. If the network has a DHCP server, it can be used to provide automatic network configuration. If DHCP is not available, the following network information for the system must be obtained from the local network administrator or Internet service provider: Required Network Information IP address Subnet mask IP address of default gateway Domain name of the network IP addresses of the network's DNS servers Check for &os; Errata Although the &os; Project strives to ensure that each release of &os; is as stable as possible, bugs occasionally creep into the process. On very rare occasions those bugs affect the installation process. As these problems are discovered and fixed, they are noted in the &os; Errata (http://www.freebsd.org/releases/&rel.current;R/errata.html) + xlink:href="&url.base;/releases/&rel.current;R/errata.html">https://www.freebsd.org/releases/&rel.current;R/errata.html) on the &os; web site. Check the errata before installing to make sure that there are no problems that might affect the installation. Information and errata for all the releases can be found on the release information section of the &os; web site (http://www.freebsd.org/releases/index.html). + xlink:href="&url.base;/releases/index.html">https://www.freebsd.org/releases/index.html). Prepare the Installation Media The &os; installer is not an application that can be run from within another operating system. Instead, download a &os; 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. &os; installation files are available at www.freebsd.org/where.html#download. Each installation file's name includes the release version of &os;, the architecture, and the type of file. For example, to install &os; 10.2 on an &arch.amd64; system from a DVD, download FreeBSD-10.2-RELEASE-amd64-dvd1.iso, burn this file to a DVD, and boot the system with the DVD inserted. Installation files are available in several formats. The formats vary depending on computer architecture and media type. Additional installation files are included for computers that boot with UEFI (Unified Extensible Firmware Interface). The names of these files include the string uefi. File types: -bootonly.iso: This is the smallest installation file as it only contains the installer. A working Internet connection is required during installation as the installer will download the files it needs to complete the &os; installation. This file should be burned to a CD using a CD burning application. -disc1.iso: This file contains all of the files needed to install &os;, its source, and the Ports Collection. It should be burned to a CD using a CD burning application. -dvd1.iso: This file contains all of the files needed to install &os;, its source, and the Ports Collection. It also contains a set of popular binary packages for installing a window manager and some applications so that a complete system can be installed from media without requiring a connection to the Internet. This file should be burned to a DVD using a DVD burning application. -memstick.img: This file contains all of the files needed to install &os;, its source, and the Ports Collection. It should be burned to a USB stick using the instructions below. -mini-memstick.img: Like -bootonly.iso, does not include installation files, but downloads them as needed. A working internet connection is required during installation. Write this file to a USB stick as shown in . After downloading the image file, download CHECKSUM.SHA256 from the same directory. Calculate a checksum for the image file. &os; provides &man.sha256.1; for this, used as sha256 imagefilename. Other operating systems have similar programs. Compare the calculated checksum with the one shown in CHECKSUM.SHA256. The checksums must match exactly. If the checksums do not match, the image file is corrupt and must be downloaded again. Writing an Image File to <acronym>USB</acronym> The *.img file is an image of the complete contents of a memory stick. It cannot be copied to the target device as a file. Several applications are available for writing the *.img to a USB stick. This section describes two of these utilities. Before proceeding, back up any important data on the USB stick. This procedure will erase the existing data on the stick. Using <command>dd</command> to Write the Image This example uses /dev/da0 as the target device where the image will be written. Be very careful that the correct device is used as this command will destroy the existing data on the specified target device. The &man.dd.1; command-line utility is available on BSD, &linux;, and &macos; systems. To burn the image using dd, insert the USB stick and determine its device name. Then, specify the name of the downloaded installation file and the device name for the USB stick. This example burns the &arch.amd64; installation image to the first USB device on an existing &os; system. &prompt.root; dd if=FreeBSD-10.2-RELEASE-amd64-memstick.img of=/dev/da0 bs=1M conv=sync If this command fails, verify that the USB stick is not mounted and that the device name is for the disk, not a partition. Some operating systems might require this command to be run with &man.sudo.8;. Systems like &linux; might buffer writes. To force all writes to complete, use &man.sync.8;. Using &windows; to Write the Image Be sure to give the correct drive letter as the existing data on the specified drive will be overwritten and destroyed. Obtaining <application>Image Writer for &windows;</application> Image Writer for &windows; is a free application that can correctly write an image file to a memory stick. Download it from https://sourceforge.net/projects/win32diskimager/ and extract it into a folder. Writing the Image with Image Writer Double-click the Win32DiskImager icon to start the program. Verify that the drive letter shown under Device is the drive with the memory stick. Click the folder icon and select the image to be written to the memory stick. Click [ Save ] to accept the image file name. Verify that everything is correct, and that no folders on the memory stick are open in other windows. When everything is ready, click [ Write ] to write the image file to the memory stick. You are now ready to start installing &os;. Starting the Installation By default, the installation will not make any changes to the disk(s) before the following message: Your changes will now be written to disk. If you have chosen to overwrite existing data, it will be PERMANENTLY ERASED. Are you sure you want to commit your changes? The install can be exited at any time prior to this warning. If there is a concern that something is incorrectly configured, just turn the computer off before this point and no changes will be made to the system's disks. This section describes how to boot the system from the installation media which was prepared using the instructions in . When using a bootable USB stick, plug in the USB stick before turning on the computer. When booting from CD or DVD, turn on the computer and insert the media at the first opportunity. How to configure the system to boot from the inserted media depends upon the architecture. Booting on &i386; and &arch.amd64; These architectures provide a BIOS menu for selecting the boot device. Depending upon the installation media being used, select the CD/DVD or USB device as the first boot device. Most systems also provide a key for selecting the boot device during startup without having to enter the BIOS. Typically, the key is either F10, F11, F12, or Escape. If the computer loads the existing operating system instead of the &os; installer, then either: The installation media was not inserted early enough in the boot process. Leave the media inserted and try restarting the computer. The BIOS changes were incorrect or not saved. Double-check that the right boot device is selected as the first boot device. This system is too old to support booting from the chosen media. In this case, the Plop Boot Manager () can be used to boot the system from the selected media. Booting on &powerpc; On most machines, holding C on the keyboard during boot will boot from the CD. Otherwise, hold Command Option O F , or Windows Alt O F on non-&apple; keyboards. At the 0 > prompt, enter boot cd:,\ppc\loader cd:0 Booting on &sparc64; Most &sparc64; systems are set up to boot automatically from disk. To install &os; from a CD requires a break into the PROM. To do this, reboot the system and wait until the boot message appears. The message depends on the model, but should look something like this: Sun Blade 100 (UltraSPARC-IIe), Keyboard Present Copyright 1998-2001 Sun Microsystems, Inc. All rights reserved. OpenBoot 4.2, 128 MB memory installed, Serial #51090132. Ethernet address 0:3:ba:b:92:d4, Host ID: 830b92d4. If the system proceeds to boot from disk at this point, press L1A or StopA on the keyboard, or send a BREAK over the serial console. When using tip or cu, ~# will issue a BREAK. The PROM prompt will be ok on systems with one CPU and ok {0} on SMP systems, where the digit indicates the number of the active CPU. At this point, place the CD into the drive and type boot cdrom from the PROM prompt. &os; Boot Menu Once the system boots from the installation media, a menu similar to the following will be displayed:
&os; Boot Loader Menu
By default, the menu will wait ten seconds for user input before booting into the &os; installer or, if &os; is already installed, before booting into &os;. 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. Boot Multi User: This will continue the &os; boot process. If the boot timer has been paused, press 1, upper- or lower-case B, or Enter. Boot Single User: This mode can be used to fix an existing &os; installation as described in . Press 2 or the upper- or lower-case S to enter this mode. Escape to loader prompt: This will boot the system into a repair prompt that contains a limited number of low-level commands. This prompt is described in . Press 3 or Esc to boot into this prompt. Reboot: Reboots the system. Configure Boot Options: Opens the menu shown in, and described under, .
&os; Boot Options Menu
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: ACPI Support: If the system hangs during boot, try toggling this option to Off. Safe Mode: If the system still hangs during boot even with ACPI Support set to Off, try setting this option to On. Single User: Toggle this option to On to fix an existing &os; installation as described in . Once the problem is fixed, set it back to Off. Verbose: Toggle this option to On to see more detailed messages during the boot process. This can be useful when troubleshooting a piece of hardware. After making the needed selections, press 1 or Backspace to return to the main boot menu, then press Enter to continue booting into &os;. A series of boot messages will appear as &os; carries out its hardware device probes and loads the installation program. Once the boot is complete, the welcome menu shown in will be displayed.
Welcome Menu
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 &os; shell in order to use command line utilities to prepare the disks before installation. The [ Live CD ] option can be used to try out &os; before installing it. The live version is described in . To review the boot messages, including the hardware device probe, press the upper- or lower-case S and then Enter to access a shell. At the shell prompt, type more /var/run/dmesg.boot and use the space bar to scroll through the messages. When finished, type exit to return to the welcome menu. Using <application>bsdinstall</application> This section shows the order of the bsdinstall menus and the type of information that will be asked before the system is installed. Use the arrow keys to highlight a menu option, then Space to select or deselect that menu item. When finished, press Enter to save the selection and move onto the next screen. Selecting the Keymap Menu Depending on the system console being used, bsdinstall may initially display the menu shown in .
Keymap Selection
To configure the keyboard layout, press Enter with [ YES ] selected, which will display the menu shown in . To instead use the default layout, use the arrow key to select [ NO ] and press Enter to skip this menu screen.
Selecting Keyboard Menu
When configuring the keyboard layout, 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. Pressing Esc will exit this menu and use the default keymap. If the choice of keymap is not clear, United States of America ISO-8859-1 is also a safe option. In &os; 10.0-RELEASE and later, this menu has been enhanced. The full selection of keymaps is shown, with the default preselected. In addition, when selecting a different keymap, a dialog is displayed that allows the user to try the keymap and ensure it is correct before proceeding.
Enhanced Keymap Menu
Setting the Hostname The next bsdinstall menu is used to set the hostname for the newly installed system.
Setting the Hostname
Type in a hostname that is unique for the network. It should be a fully-qualified hostname, such as machine3.example.com. Selecting Components to Install Next, bsdinstall will prompt to select optional components to install.
Selecting 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 &os; kernel and userland, collectively known as the base system, are always installed. Depending on the architecture, some of these components may not appear: doc - Additional documentation, mostly of historical interest, to install into /usr/share/doc. The documentation provided by the FreeBSD Documentation Project may be installed later using the instructions in . games - Several traditional BSD games, including fortune, rot13, and others. lib32 - Compatibility libraries for running 32-bit applications on a 64-bit version of &os;. ports - The &os; Ports Collection is a collection of files which automates the downloading, compiling and installation of third-party software packages. discusses how to use the Ports Collection. The installation program does not check for adequate disk space. Select this option only if sufficient hard disk space is available. The &os; Ports Collection takes up about &ports.size; of disk space. src - The complete &os; source code for both the kernel and the userland. Although not required for the majority of applications, it may be required to build device drivers, kernel modules, or some applications from the Ports Collection. It is also used for developing &os; itself. The full source tree requires 1 GB of disk space and recompiling the entire &os; system requires an additional 5 GB of space. Installing from the Network The menu shown in only appears when installing from a -bootonly.iso CD 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 first configured.
Installing from the Network
To configure the network connection, press Enter and follow the instructions in . Once the interface is configured, select a mirror site that is located in the same region of the world as the computer on which &os; is being installed. Files can be retrieved more quickly when the mirror is close to the target computer, reducing installation time.
Choosing a Mirror
Installation will then continue as if the installation files were located on the local installation media. Allocating Disk Space The next menu is used to determine the method for allocating disk space. The options available in the menu depend upon the version of &os; being installed.
Partitioning Choices on &os; 9.x
Partitioning Choices on &os; 10.x and Higher
Guided partitioning automatically sets up the disk partitions, Manual partitioning allows advanced users to create customized partitions from menu options, and Shell opens a shell prompt where advanced users can create customized partitions using command-line utilities like &man.gpart.8;, &man.fdisk.8;, and &man.bsdlabel.8;. ZFS partitioning, only available in &os; 10 and later, creates an optionally encrypted root-on-ZFS system with support for boot environments. This section describes what to consider when laying out the disk partitions. It then demonstrates how to use the different partitioning methods. Designing the Partition Layout partition layout /etc /var /usr 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. Sometimes, a lot of disk space is required in /var/tmp. When new software is installed, the packaging tools extract a temporary copy of the packages under /var/tmp. Large software packages, like Firefox, Apache OpenOffice or LibreOffice may be tricky to install if there is not enough disk space under /var/tmp. The /usr partition holds many of the files which support the system, including the &os; Ports Collection and system source code. At least 2 gigabytes of space is recommended for this partition. 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. swap sizing swap partition As a rule of thumb, the swap partition should be about double the size of physical memory (RAM). Systems with minimal RAM 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 are fine, even if swap is not used much. 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. Guided Partitioning When this method is selected, a menu will display the available disk(s). If multiple disks are connected, choose the one where &os; is to be installed.
Selecting from Multiple Disks
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.
Selecting Entire Disk or Partition
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 and pressing [ Auto ] will recreate the automatic &os; partitions. Partitions can also be manually created, modified, or deleted. When the partitioning is correct, select [ Finish ] to continue with the installation.
Review Created Partitions
Manual Partitioning Selecting this method opens the partition editor:
Manually Create Partitions
Highlight the installation drive (ada0 in this example) and select [ Create ] to display a menu of available partition schemes:
Manually Create Partitions
GPT is usually the most appropriate choice for &arch.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. Partitioning Schemes Abbreviation Description APM Apple Partition Map, used by &powerpc;. BSD BSD label without an MBR, sometimes called dangerously dedicated mode as non-BSD disk utilities may not recognize it. GPT GUID Partition Table (http://en.wikipedia.org/wiki/GUID_Partition_Table). MBR Master Boot Record (http://en.wikipedia.org/wiki/Master_boot_record). PC98 MBR variant used by NEC PC-98 computers (http://en.wikipedia.org/wiki/Pc9801). VTOC8 Volume Table Of Contents used by Sun SPARC64 and UltraSPARC computers.
After the partitioning scheme has been selected and created, select [ Create ] again to create the partitions.
Manually Create Partitions
A standard &os; GPT installation uses at least three partitions: freebsd-boot - Holds the &os; boot code. freebsd-ufs - A &os; UFS file system. freebsd-swap - &os; swap space. Another partition type worth noting is freebsd-zfs, used for partitions that will contain a &os; ZFS file system (). Refer to &man.gpart.8; for descriptions of the available GPT partition types. Multiple file system partitions can be created and some people prefer a traditional layout with separate partitions for /, /var, /tmp, and /usr. See for an example. The Size may be entered with common abbreviations: K for kilobytes, M for megabytes, or G for gigabytes. Proper sector alignment provides the best performance, and making partition sizes even multiples of 4K bytes helps to ensure alignment on drives with either 512-byte or 4K-byte sectors. Generally, using partition sizes that are even multiples of 1M or 1G is the easiest way to make sure every partition starts at an even multiple of 4K. There is one exception: the freebsd-boot partition should be no larger than 512K due to current boot code limitations. 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/. Use a unique label on every partition to avoid conflicts from identical labels. A few letters from the computer's name, use, or location can be added to the label. For instance, use labroot or rootfslab for the UFS root partition on the computer named lab. Creating Traditional Split File System Partitions For a traditional partition layout where the /, /var, /tmp, and /usr directories are separate file systems on their own partitions, create a GPT partitioning scheme, then create the partitions as shown. Partition sizes shown are typical for a 20G target disk. If more space is available on the target disk, larger swap or /var partitions may be useful. Labels shown here are prefixed with ex for example, but readers should use other unique label values as described above. By default, &os;'s gptboot expects the first UFS partition to be the / partition. Partition Type Size Mountpoint Label freebsd-boot 512K freebsd-ufs 2G / exrootfs freebsd-swap 4G exswap freebsd-ufs 2G /var exvarfs freebsd-ufs 1G /tmp extmpfs freebsd-ufs accept the default (remainder of the disk) /usr exusrfs After the custom partitions have been created, select [ Finish ] to continue with the installation. Root-on-ZFS Automatic Partitioning Support for automatic creation of root-on-ZFS installations was added in &os; 10.0-RELEASE. This partitioning mode only works with whole disks and will erase the contents of the entire disk. The installer will automatically create partitions aligned to 4k boundaries and force ZFS to use 4k sectors. This is safe even with 512 byte sector disks, and has the added benefit of ensuring that pools created on 512 byte disks will be able to have 4k sector disks added in the future, either as additional storage space or as replacements for failed disks. The installer can also optionally employ GELI disk encryption as described in . If encryption is enabled, a 2 GB unencrypted boot pool containing the /boot directory is created. It holds the kernel and other files necessary to boot the system. A swap partition of a user selectable size is also created, and all remaining space is used for the ZFS pool. The main ZFS configuration menu offers a number of options to control the creation of the pool.
<acronym>ZFS</acronym> Partitioning Menu
Select T to configure the Pool Type and the disk(s) that will constitute the pool. The automatic ZFS installer currently only supports the creation of a single top level vdev, except in stripe mode. To create more complex pools, use the instructions in to create the pool. The installer supports the creation of various pool types, including stripe (not recommended, no redundancy), mirror (best performance, least usable space), and RAID-Z 1, 2, and 3 (with the capability to withstand the concurrent failure of 1, 2, and 3 disks, respectively). While selecting the pool type, a tooltip is displayed across the bottom of the screen with advice about the number of required disks, and in the case of RAID-Z, the optimal number of disks for each configuration.
<acronym>ZFS</acronym> Pool Type
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 enough disks are selected. If not, select <Change Selection> to return to the list of disks, or <Cancel> to change the pool type.
Disk Selection
Invalid Selection
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.
Analyzing a Disk
The main ZFS configuration menu also allows the user to enter a pool name, disable forcing 4k sectors, enable or disable encryption, switch between GPT (recommended) and MBR partition table types, and select the amount of swap space. Once all options have been set to the desired values, select the >>> Install option at the top of the menu. If GELI disk encryption was enabled, the installer will prompt twice for the passphrase to be used to encrypt the disks.
Disk Encryption Password
The installer then offers a last chance to cancel before the contents of the selected drives are destroyed to create the ZFS pool.
Last Chance
The installation then proceeds normally. Shell Mode Partitioning 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. Committing to the Installation Once the disks are configured, the next menu provides the last chance to make changes before the selected hard drive(s) are formatted. If changes need to be made, select [ Back ] to return to the main partitioning menu. [ Revert & Exit ] will exit the installer without making any changes to the hard drive.
Final Confirmation
To instead start the actual installation, select [ Commit ] and press Enter. Installation time will vary depending on the distributions chosen, installation media, and speed of the computer. A series of messages will indicate the progress. First, the installer formats the selected disk(s) and initializes the partitions. Next, in the case of a bootonly media, it downloads the selected components:
Fetching Distribution Files
Next, the integrity of the distribution files is verified to ensure they have not been corrupted during download or misread from the installation media:
Verifying Distribution Files
Finally, the verified distribution files are extracted to the disk:
Extracting Distribution Files
Once all requested distribution files have been extracted, bsdinstall displays the first post-installation configuration screen. The available post-configuration options are described in the next section. Post-Installation Once &os; is installed, bsdinstall will prompt to configure several options before booting into the newly installed system. This section describes these configuration options. Once the system has booted, bsdconfig provides a menu-driven method for configuring the system using these and additional options. Setting the <systemitem class="username">root</systemitem> Password First, the root password must be set. While entering the password, the characters being typed are not displayed on the screen. After the password has been entered, it must be entered again. This helps prevent typing errors.
Setting the <systemitem class="username">root</systemitem> Password
Configuring Network Interfaces Next, a list of the network interfaces found on the computer is shown. Select the interface to configure. The network configuration menus will be skipped if the network was previously configured as part of a bootonly installation.
Choose a Network Interface
If an Ethernet interface is selected, the installer will skip ahead to the menu shown in . If a wireless network interface is chosen, the system will instead scan for wireless access points:
Scanning 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.
Choosing a Wireless Network
Next, enter the encryption information for connecting to the selected wireless network. WPA2 encryption is strongly recommended as older encryption types, like WEP, 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.
WPA2 Setup
Next, choose whether or not an IPv4 address should be configured on the Ethernet or wireless interface:
Choose <acronym>IPv4</acronym> Networking
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. Do not enter random network information as it will not work. If a DHCP server is not available, obtain the information listed in from the network administrator or Internet service provider. 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.
Choose <acronym>IPv4</acronym> <acronym>DHCP</acronym> Configuration
If a DHCP server is not available, select [ No ] and input the following addressing information in this menu:
<acronym>IPv4</acronym> Static Configuration
IP Address - The IPv4 address assigned to this computer. The address must be unique and not already in use by another piece of equipment on the local network. Subnet Mask - The subnet mask for the network. Default Router - The IP address of the network's default gateway. The next screen will ask if the interface should be configured for IPv6. If IPv6 is available and desired, choose [ Yes ] to select it.
Choose IPv6 Networking
IPv6 also has two methods of configuration. StateLess Address AutoConfiguration (SLAAC) will automatically request the correct configuration information from a local router. Refer to http://tools.ietf.org/html/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.
Choose IPv6 SLAAC Configuration
If an IPv6 router is not available, select [ No ] and input the following addressing information in this menu:
IPv6 Static Configuration
IPv6 Address - The IPv6 address assigned to this computer. The address must be unique and not already in use by another piece of equipment on the local network. Default Router - The IPv6 address of the network's default gateway. 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.
DNS Configuration
Setting the Time Zone The next menu asks if the system clock uses UTC or local time. When in doubt, select [ No ] to choose the more commonly-used local time.
Select Local or UTC Clock
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 Eastern time zone of the United States. The selections will vary according to the geographical location.
Select a Region
The appropriate region is selected using the arrow keys and then pressing Enter.
Select a Country
Select the appropriate country using the arrow keys and press Enter.
Select a Time Zone
The appropriate time zone is selected using the arrow keys and pressing Enter.
Confirm Time Zone
Confirm the abbreviation for the time zone is correct. If it is, press Enter to continue with the post-installation configuration. Enabling Services 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.
Selecting Additional Services to Enable
Here is a summary of the services which can be enabled in this menu: sshd - The Secure Shell (SSH) daemon is used to remotely access a system over an encrypted connection. Only enable this service if the system should be available for remote logins. moused - Enable this service if the mouse will be used from the command-line system console. ntpd - The Network Time Protocol (NTP) daemon for automatic clock synchronization. Enable this service if there is a &windows;, Kerberos, or LDAP server on the network. powerd - System power control utility for power control and energy saving. Enabling Crash Dumps The next menu is used to configure whether or not crash dumps should be enabled. Enabling crash dumps can be useful in debugging issues with the system, so users are encouraged to enable crash dumps.
Enabling Crash Dumps
Add Users The next menu prompts to create at least one user account. It is recommended to login to 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.
Add User Accounts
Follow the prompts and input the requested information for the user account. The example shown in creates the asample user account.
Enter User Information
Here is a summary of the information to input: Username - The name the user will enter to log in. A common convention is to use the first letter of the first name combined with the last name, as long as each username is unique for the system. The username is case sensitive and should not contain any spaces. Full name - The user's full name. This can contain spaces and is used as a description for the user account. Uid - User ID. Typically, this is left blank so the system will assign a value. Login group - The user's group. Typically this is left blank to accept the default. Invite user into other groups? - Additional groups to which the user will be added as a member. If the user needs administrative access, type wheel here. Login class - Typically left blank for the default. Shell - Type in one of the listed values to set the interactive shell for the user. Refer to for more information about shells. Home directory - The user's home directory. The default is usually correct. Home directory permissions - Permissions on the user's home directory. The default is usually correct. Use password-based authentication? - Typically yes so that the user is prompted to input their password at login. Use an empty password? - Typically no as it is insecure to have a blank password. Use a random password? - Typically no so that the user can set their own password in the next prompt. Enter password - The password for this user. Characters typed will not show on the screen. Enter password again - The password must be typed again for verification. Lock out the account after creation? - Typically no so that the user can login. After entering everything, a summary is shown for review. If a mistake was made, enter no and try again. If everything is correct, enter yes to create the new user.
Exit User and Group Management
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 . Final Configuration After everything has been installed and configured, a final chance is provided to modify settings.
Final Configuration
Use this menu to make any changes or do any additional configuration before completing the installation. Add User - Described in . Root Password - Described in . Hostname - Described in . Network - Described in . Services - Described in . Time Zone - Described in . Handbook - Download and install the &os; Handbook. After any final configuration is complete, select Exit.
Manual Configuration
bsdinstall will prompt if there are 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.
Complete 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 &os; system. Do not forget to remove the &os; install media or the computer may boot from it again. As &os; 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 for instructions on how to become the superuser when administrative access is needed. The messages that appeared 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 , the first boot may be a bit slower as the system will generate the RSA and DSA keys. Subsequent boots will be faster. The fingerprints of the keys will be displayed, as seen in this example: Generating public/private rsa1 key pair. Your identification has been saved in /etc/ssh/ssh_host_key. Your public key has been saved in /etc/ssh/ssh_host_key.pub. The key fingerprint is: 10:a0:f5:af:93:ae:a3:1a:b2:bb:3c:35:d9:5a:b3:f3 root@machine3.example.com The key's randomart image is: +--[RSA1 1024]----+ | o.. | | o . . | | . o | | o | | o S | | + + o | |o . + * | |o+ ..+ . | |==o..o+E | +-----------------+ Generating public/private dsa key pair. Your identification has been saved in /etc/ssh/ssh_host_dsa_key. Your public key has been saved in /etc/ssh/ssh_host_dsa_key.pub. The key fingerprint is: 7e:1c:ce:dc:8a:3a:18:13:5b:34:b5:cf:d9:d1:47:b2 root@machine3.example.com The key's randomart image is: +--[ DSA 1024]----+ | .. . .| | o . . + | | . .. . E .| | . . o o . . | | + S = . | | + . = o | | + . * . | | . . o . | | .o. . | +-----------------+ Starting sshd. Refer to for more information about fingerprints and SSH. &os; does not install a graphical environment by default. Refer to for more information about installing and configuring a graphical window manager. Proper shutdown of a &os; 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. Troubleshooting installation troubleshooting This section covers basic installation troubleshooting, such as common problems people have reported. Check the Hardware Notes (http://www.freebsd.org/releases/index.html) + xlink:href="&url.base;/releases/index.html">https://www.freebsd.org/releases/index.html) document for the version of &os; to make sure the hardware is supported. If the hardware is supported and lock-ups or other problems occur, build a custom kernel using the instructions in to add support for devices which are not present in the GENERIC kernel. The default kernel assumes that most hardware devices are in their factory default configuration in terms of IRQs, I/O addresses, and DMA channels. If the hardware has been reconfigured, a custom kernel configuration file can tell &os; where to find things. Some installation problems can be avoided or alleviated by updating the firmware on various hardware components, most notably the motherboard. Motherboard firmware is usually referred to as the BIOS. Most motherboard and computer manufacturers have a website for upgrades and upgrade information. Manufacturers generally advise against upgrading the motherboard BIOS unless there is a good reason for doing so, like a critical update. The upgrade process can go wrong, leaving the BIOS incomplete and the computer inoperative. If the system hangs while probing hardware during boot, or it behaves strangely during install, ACPI may be the culprit. &os; makes extensive use of the system ACPI service on the &arch.i386;, &arch.amd64;, and ia64 platforms to aid in system configuration if it is detected during boot. Unfortunately, some bugs still exist in both the ACPI driver and within system motherboards and BIOS firmware. ACPI can be disabled by setting the hint.acpi.0.disabled hint in the third stage boot loader: set hint.acpi.0.disabled="1" This is reset each time the system is booted, so it is necessary to add hint.acpi.0.disabled="1" to the file /boot/loader.conf. More information about the boot loader can be found in . Using the Live <acronym>CD</acronym> The welcome menu of bsdinstall, shown in , provides a [ Live CD ] option. This is useful for those who are still wondering whether &os; is the right operating system for them and want to test some of the features before installing. The following points should be noted before using the [ Live CD ]: To gain access to the system, authentication is required. The username is root and the password is blank. As the system runs directly from the installation media, performance will be significantly slower than that of a system installed on a hard disk. This option only provides a command prompt and not a graphical interface. Index: head/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.xml =================================================================== --- head/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.xml (revision 50962) +++ head/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.xml (revision 50963) @@ -1,1604 +1,1604 @@ Updating and Upgrading &os; Jim Mock Restructured, reorganized, and parts updated by Jordan Hubbard Original work by Poul-Henning Kamp John Polstra Nik Clayton Synopsis &os; is under constant development between releases. Some people prefer to use the officially released versions, while others prefer to keep in sync with the latest developments. However, even official releases are often updated with security and other critical fixes. Regardless of the version used, &os; provides all the necessary tools to keep the system updated, and allows for easy upgrades between versions. This chapter describes how to track the development system and the basic tools for keeping a &os; system up-to-date. After reading this chapter, you will know: How to keep a &os; system up-to-date with freebsd-update or Subversion. How to compare the state of an installed system against a known pristine copy. How to keep the installed documentation up-to-date with Subversion or documentation ports. The difference between the two development branches: &os.stable; and &os.current;. How to rebuild and reinstall the entire base system. Before reading this chapter, you should: Properly set up the network connection (). Know how to install additional third-party software (). Throughout this chapter, svn is used to obtain and update &os; sources. To use it, first install the devel/subversion port or package. &os; Update Tom Rhodes Written by Colin Percival Based on notes provided by Updating and Upgrading freebsd-update updating-upgrading Applying security patches in a timely manner and upgrading to a newer release of an operating system are important aspects of ongoing system administration. &os; includes a utility called freebsd-update which can be used to perform both these tasks. This utility supports binary security and errata updates to &os;, without the need to manually compile and install the patch or a new kernel. Binary updates are available for all architectures and releases currently supported by the security team. The list of supported releases and their estimated end-of-life dates are listed at http://www.FreeBSD.org/security/. + xlink:href="https://www.FreeBSD.org/security/">https://www.FreeBSD.org/security/. This utility also supports operating system upgrades to minor point releases as well as upgrades to another release branch. Before upgrading to a new release, review its release announcement as it contains important information pertinent to the release. Release announcements are available from http://www.FreeBSD.org/releases/. + xlink:href="https://www.FreeBSD.org/releases/">https://www.FreeBSD.org/releases/. If a crontab utilizing the features of &man.freebsd-update.8; exists, it must be disabled before upgrading the operating system. This section describes the configuration file used by freebsd-update, demonstrates how to apply a security patch and how to upgrade to a minor or major operating system release, and discusses some of the considerations when upgrading the operating system. The Configuration File The default configuration file for freebsd-update works as-is. Some users may wish to tweak the default configuration in /etc/freebsd-update.conf, allowing better control of the process. The comments in this file explain the available options, but the following may require a bit more explanation: # Components of the base system which should be kept updated. Components world kernel This parameter controls which parts of &os; will be kept up-to-date. The default is to update the entire base system and the kernel. Individual components can instead be specified, such as src/base or src/sys. However, the best option is to leave this at the default as changing it to include specific items requires every needed item to be listed. Over time, this could have disastrous consequences as source code and binaries may become out of sync. # Paths which start with anything matching an entry in an IgnorePaths # statement will be ignored. IgnorePaths /boot/kernel/linker.hints To leave specified directories, such as /bin or /sbin, untouched during the update process, add their paths to this statement. This option may be used to prevent freebsd-update from overwriting local modifications. # Paths which start with anything matching an entry in an UpdateIfUnmodified # statement will only be updated if the contents of the file have not been # modified by the user (unless changes are merged; see below). UpdateIfUnmodified /etc/ /var/ /root/ /.cshrc /.profile This option will only update unmodified configuration files in the specified directories. Any changes made by the user will prevent the automatic updating of these files. There is another option, KeepModifiedMetadata, which will instruct freebsd-update to save the changes during the merge. # When upgrading to a new &os; release, files which match MergeChanges # will have any local changes merged into the version from the new release. MergeChanges /etc/ /var/named/etc/ /boot/device.hints List of directories with configuration files that freebsd-update should attempt to merge. The file merge process is a series of &man.diff.1; patches similar to &man.mergemaster.8;, but with fewer options. Merges are either accepted, open an editor, or cause freebsd-update to abort. When in doubt, backup /etc and just accept the merges. See &man.mergemaster.8; for more information about mergemaster. # Directory in which to store downloaded updates and temporary # files used by &os; Update. # WorkDir /var/db/freebsd-update This directory is where all patches and temporary files are placed. In cases where the user is doing a version upgrade, this location should have at least a gigabyte of disk space available. # When upgrading between releases, should the list of Components be # read strictly (StrictComponents yes) or merely as a list of components # which *might* be installed of which &os; Update should figure out # which actually are installed and upgrade those (StrictComponents no)? # StrictComponents no When this option is set to yes, freebsd-update will assume that the Components list is complete and will not attempt to make changes outside of the list. Effectively, freebsd-update will attempt to update every file which belongs to the Components list. Applying Security Patches The process of applying &os; security patches has been simplified, allowing an administrator to keep a system fully patched using freebsd-update. More information about &os; security advisories can be found in . &os; security patches may be downloaded and installed using the following commands. The first command will determine if any outstanding patches are available, and if so, will list the files that will be modifed if the patches are applied. The second command will apply the patches. &prompt.root; freebsd-update fetch &prompt.root; freebsd-update install If the update applies any kernel patches, the system will need a reboot in order to boot into the patched kernel. If the patch was applied to any running binaries, the affected applications should be restarted so that the patched version of the binary is used. The system can be configured to automatically check for updates once every day by adding this entry to /etc/crontab: @daily root freebsd-update cron If patches exist, they will automatically be downloaded but will not be applied. The root user will be sent an email so that the patches may be reviewed and manually installed with freebsd-update install. If anything goes wrong, freebsd-update has the ability to roll back the last set of changes with the following command: &prompt.root; freebsd-update rollback Uninstalling updates... done. Again, the system should be restarted if the kernel or any kernel modules were modified and any affected binaries should be restarted. Only the GENERIC kernel can be automatically updated by freebsd-update. If a custom kernel is installed, it will have to be rebuilt and reinstalled after freebsd-update finishes installing the updates. However, freebsd-update will detect and update the GENERIC kernel if /boot/GENERIC exists, even if it is not the current running kernel of the system. Always keep a copy of the GENERIC kernel in /boot/GENERIC. It will be helpful in diagnosing a variety of problems and in performing version upgrades. Refer to for instructions on how to get a copy of the GENERIC kernel. Unless the default configuration in /etc/freebsd-update.conf has been changed, freebsd-update will install the updated kernel sources along with the rest of the updates. Rebuilding and reinstalling a new custom kernel can then be performed in the usual way. The updates distributed by freebsd-update do not always involve the kernel. It is not necessary to rebuild a custom kernel if the kernel sources have not been modified by freebsd-update install. However, freebsd-update will always update /usr/src/sys/conf/newvers.sh. The current patch level, as indicated by the -p number reported by uname -r, is obtained from this file. Rebuilding a custom kernel, even if nothing else changed, allows uname to accurately report the current patch level of the system. This is particularly helpful when maintaining multiple systems, as it allows for a quick assessment of the updates installed in each one. Performing Major and Minor Version Upgrades Upgrades from one minor version of &os; to another, like from &os; 9.0 to &os; 9.1, are called minor version upgrades. Major version upgrades occur when &os; is upgraded from one major version to another, like from &os; 9.X to &os; 10.X. Both types of upgrades can be performed by providing freebsd-update with a release version target. If the system is running a custom kernel, make sure that a copy of the GENERIC kernel exists in /boot/GENERIC before starting the upgrade. Refer to for instructions on how to get a copy of the GENERIC kernel. The following command, when run on a &os; 9.0 system, will upgrade it to &os; 9.1: &prompt.root; freebsd-update -r 9.1-RELEASE upgrade After the command has been received, freebsd-update will evaluate the configuration file and current system in an attempt to gather the information necessary to perform the upgrade. A screen listing will display which components have and have not been detected. For example: Looking up update.FreeBSD.org mirrors... 1 mirrors found. Fetching metadata signature for 9.0-RELEASE from update1.FreeBSD.org... done. Fetching metadata index... done. Inspecting system... done. The following components of FreeBSD seem to be installed: kernel/smp src/base src/bin src/contrib src/crypto src/etc src/games src/gnu src/include src/krb5 src/lib src/libexec src/release src/rescue src/sbin src/secure src/share src/sys src/tools src/ubin src/usbin world/base world/info world/lib32 world/manpages The following components of FreeBSD do not seem to be installed: kernel/generic world/catpages world/dict world/doc world/games world/proflibs Does this look reasonable (y/n)? y At this point, freebsd-update will attempt to download all files required for the upgrade. In some cases, the user may be prompted with questions regarding what to install or how to proceed. When using a custom kernel, the above step will produce a warning similar to the following: WARNING: This system is running a "MYKERNEL" kernel, which is not a kernel configuration distributed as part of FreeBSD 9.0-RELEASE. This kernel will not be updated: you MUST update the kernel manually before running "/usr/sbin/freebsd-update install" This warning may be safely ignored at this point. The updated GENERIC kernel will be used as an intermediate step in the upgrade process. Once all the patches have been downloaded to the local system, they will be applied. This process may take a while, depending on the speed and workload of the machine. Configuration files will then be merged. The merging process requires some user intervention as a file may be merged or an editor may appear on screen for a manual merge. The results of every successful merge will be shown to the user as the process continues. A failed or ignored merge will cause the process to abort. Users may wish to make a backup of /etc and manually merge important files, such as master.passwd or group at a later time. The system is not being altered yet as all patching and merging is happening in another directory. Once all patches have been applied successfully, all configuration files have been merged and it seems the process will go smoothly, the changes can be committed to disk by the user using the following command: &prompt.root; freebsd-update install The kernel and kernel modules will be patched first. If the system is running with a custom kernel, use &man.nextboot.8; to set the kernel for the next boot to the updated /boot/GENERIC: &prompt.root; nextboot -k GENERIC Before rebooting with the GENERIC kernel, make sure it contains all the drivers required for the system to boot properly and connect to the network, if the machine being updated is accessed remotely. In particular, if the running custom kernel contains built-in functionality usually provided by kernel modules, make sure to temporarily load these modules into the GENERIC kernel using the /boot/loader.conf facility. It is recommended to disable non-essential services as well as any disk and network mounts until the upgrade process is complete. The machine should now be restarted with the updated kernel: &prompt.root; shutdown -r now Once the system has come back online, restart freebsd-update using the following command. Since the state of the process has been saved, freebsd-update will not start from the beginning, but will instead move on to the next phase and remove all old shared libraries and object files. &prompt.root; freebsd-update install Depending upon whether any library version numbers were bumped, there may only be two install phases instead of three. The upgrade is now complete. If this was a major version upgrade, reinstall all ports and packages as described in . Custom Kernels with &os; 9.X and Later Before using freebsd-update, ensure that a copy of the GENERIC kernel exists in /boot/GENERIC. If a custom kernel has only been built once, the kernel in /boot/kernel.old is the GENERIC kernel. Simply rename this directory to /boot/kernel. If a custom kernel has been built more than once or if it is unknown how many times the custom kernel has been built, obtain a copy of the GENERIC kernel that matches the current version of the operating system. If physical access to the system is available, a copy of the GENERIC kernel can be installed from the installation media: &prompt.root; mount /cdrom &prompt.root; cd /cdrom/usr/freebsd-dist &prompt.root; tar -C/ -xvf kernel.txz boot/kernel/kernel Alternately, the GENERIC kernel may be rebuilt and installed from source: &prompt.root; cd /usr/src &prompt.root; make kernel __MAKE_CONF=/dev/null SRCCONF=/dev/null For this kernel to be identified as the GENERIC kernel by freebsd-update, the GENERIC configuration file must not have been modified in any way. It is also suggested that the kernel is built without any other special options. Rebooting into the GENERIC kernel is not required as freebsd-update only needs /boot/GENERIC to exist. Upgrading Packages After a Major Version Upgrade Generally, installed applications will continue to work without problems after minor version upgrades. Major versions use different Application Binary Interfaces (ABIs), which will break most third-party applications. After a major version upgrade, all installed packages and ports need to be upgraded. Packages can be upgraded using pkg upgrade. To upgrade installed ports, use a utility such as ports-mgmt/portmaster. A forced upgrade of all installed packages will replace the packages with fresh versions from the repository even if the version number has not increased. This is required because of the ABI version change when upgrading between major versions of &os;. The forced upgrade can be accomplished by performing: &prompt.root; pkg-static upgrade -f A rebuild of all installed applications can be accomplished with this command: &prompt.root; portmaster -af This command will display the configuration screens for each application that has configurable options and wait for the user to interact with those screens. To prevent this behavior, and use only the default options, include in the above command. Once the software upgrades are complete, finish the upgrade process with a final call to freebsd-update in order to tie up all the loose ends in the upgrade process: &prompt.root; freebsd-update install If the GENERIC kernel was temporarily used, this is the time to build and install a new custom kernel using the instructions in . Reboot the machine into the new &os; version. The upgrade process is now complete. System State Comparison The state of the installed &os; version against a known good copy can be tested using freebsd-update IDS. This command evaluates the current version of system utilities, libraries, and configuration files and can be used as a built-in Intrusion Detection System (IDS). This command is not a replacement for a real IDS such as security/snort. As freebsd-update stores data on disk, the possibility of tampering is evident. While this possibility may be reduced using kern.securelevel and by storing the freebsd-update data on a read-only file system when not in use, a better solution would be to compare the system against a secure disk, such as a DVD or securely stored external USB disk device. An alternative method for providing IDS functionality using a built-in utility is described in To begin the comparison, specify the output file to save the results to: &prompt.root; freebsd-update IDS >> outfile.ids The system will now be inspected and a lengthy listing of files, along with the SHA256 hash values for both the known value in the release and the current installation, will be sent to the specified output file. The entries in the listing are extremely long, but the output format may be easily parsed. For instance, to obtain a list of all files which differ from those in the release, issue the following command: &prompt.root; cat outfile.ids | awk '{ print $1 }' | more /etc/master.passwd /etc/motd /etc/passwd /etc/pf.conf This sample output has been truncated as many more files exist. Some files have natural modifications. For example, /etc/passwd will be modified if users have been added to the system. Kernel modules may differ as freebsd-update may have updated them. To exclude specific files or directories, add them to the IDSIgnorePaths option in /etc/freebsd-update.conf. Updating the Documentation Set Updating and Upgrading Documentation Updating and Upgrading Documentation is an integral part of the &os; operating system. While an up-to-date version of the &os; documentation is always available on the &os; web site (http://www.freebsd.org/doc/), + xlink:href="&url.base;/doc/">https://www.freebsd.org/doc/), it can be handy to have an up-to-date, local copy of the &os; website, handbooks, FAQ, and articles. This section describes how to use either source or the &os; Ports Collection to keep a local copy of the &os; documentation up-to-date. For information on editing and submitting corrections to the documentation, refer to the &os; Documentation Project Primer for New Contributors (http://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/). + xlink:href="&url.books.fdp-primer;">https://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/). Updating Documentation from Source Rebuilding the &os; documentation from source requires a collection of tools which are not part of the &os; base system. The required tools, including svn, can be installed from the textproc/docproj package or port developed by the &os; Documentation Project. Once installed, use svn to fetch a clean copy of the documentation source: &prompt.root; svn checkout https://svn.FreeBSD.org/doc/head /usr/doc The initial download of the documentation sources may take a while. Let it run until it completes. Future updates of the documentation sources may be fetched by running: &prompt.root; svn update /usr/doc Once an up-to-date snapshot of the documentation sources has been fetched to /usr/doc, everything is ready for an update of the installed documentation. A full update of all available languages may be performed by typing: &prompt.root; cd /usr/doc &prompt.root; make install clean If an update of only a specific language is desired, make can be invoked in a language-specific subdirectory of /usr/doc: &prompt.root; cd /usr/doc/en_US.ISO8859-1 &prompt.root; make install clean An alternative way of updating the documentation is to run this command from /usr/doc or the desired language-specific subdirectory: &prompt.root; make update The output formats that will be installed may be specified by setting FORMATS: &prompt.root; cd /usr/doc &prompt.root; make FORMATS='html html-split' install clean Several options are available to ease the process of updating only parts of the documentation, or the build of specific translations. These options can be set either as system-wide options in /etc/make.conf, or as command-line options passed to make. The options include: DOC_LANG The list of languages and encodings to build and install, such as en_US.ISO8859-1 for English documentation. FORMATS A single format or a list of output formats to be built. Currently, html, html-split, txt, ps, and pdf are supported. DOCDIR Where to install the documentation. It defaults to /usr/share/doc. For more make variables supported as system-wide options in &os;, refer to &man.make.conf.5;. Updating Documentation from Ports Marc Fonvieille Based on the work of Updating and Upgrading documentation package Updating and Upgrading The previous section presented a method for updating the &os; documentation from sources. This section describes an alternative method which uses the Ports Collection and makes it possible to: Install pre-built packages of the documentation, without having to locally build anything or install the documentation toolchain. Build the documentation sources through the ports framework, making the checkout and build steps a bit easier. This method of updating the &os; documentation is supported by a set of documentation ports and packages which are updated by the &a.doceng; on a monthly basis. These are listed in the &os; Ports Collection, under the docs category (http://www.freshports.org/docs/). Organization of the documentation ports is as follows: The misc/freebsd-doc-en package or port installs all of the English documentation. The misc/freebsd-doc-all meta-package or port installs all documentation in all available languages. There is a package and port for each translation, such as misc/freebsd-doc-hu for the Hungarian documentation. When binary packages are used, the &os; documentation will be installed in all available formats for the given language. For example, the following command will install the latest package of the Hungarian documentation: &prompt.root; pkg install hu-freebsd-doc Packages use a format that differs from the corresponding port's name: lang-freebsd-doc, where lang is the short format of the language code, such as hu for Hungarian, or zh_cn for Simplified Chinese. To specify the format of the documentation, build the port instead of installing the package. For example, to build and install the English documentation: &prompt.root; cd /usr/ports/misc/freebsd-doc-en &prompt.root; make install clean The port provides a configuration menu where the format to build and install can be specified. By default, split HTML, similar to the format used on http://www.FreeBSD.org, and PDF are selected. Alternately, several make options can be specified when building a documentation port, including: WITH_HTML Builds the HTML format with a single HTML file per document. The formatted documentation is saved to a file called article.html, or book.html. WITH_PDF The formatted documentation is saved to a file called article.pdf or book.pdf. DOCBASE Specifies where to install the documentation. It defaults to /usr/local/share/doc/freebsd. This example uses variables to install the Hungarian documentation as a PDF in the specified directory: &prompt.root; cd /usr/ports/misc/freebsd-doc-hu &prompt.root; make -DWITH_PDF DOCBASE=share/doc/freebsd/hu install clean Documentation packages or ports can be updated using the instructions in . For example, the following command updates the installed Hungarian documentation using ports-mgmt/portmaster by using packages only: &prompt.root; portmaster -PP hu-freebsd-doc Tracking a Development Branch -CURRENT -STABLE &os; has two development branches: &os.current; and &os.stable;. This section provides an explanation of each branch and its intended audience, as well as how to keep a system up-to-date with each respective branch. Using &os.current; &os.current; is the bleeding edge of &os; development and &os.current; users are expected to have a high degree of technical skill. Less technical users who wish to track a development branch should track &os.stable; instead. &os.current; is the very latest source code for &os; and includes works in progress, experimental changes, and transitional mechanisms that might or might not be present in the next official release. While many &os; developers compile the &os.current; source code daily, there are short periods of time when the source may not be buildable. These problems are resolved as quickly as possible, but whether or not &os.current; brings disaster or new functionality can be a matter of when the source code was synced. &os.current; is made available for three primary interest groups: Members of the &os; community who are actively working on some part of the source tree. Members of the &os; community who are active testers. They are willing to spend time solving problems, making topical suggestions on changes and the general direction of &os;, and submitting patches. Users who wish to keep an eye on things, use the current source for reference purposes, or make the occasional comment or code contribution. &os.current; should not be considered a fast-track to getting new features before the next release as pre-release features are not yet fully tested and most likely contain bugs. It is not a quick way of getting bug fixes as any given commit is just as likely to introduce new bugs as to fix existing ones. &os.current; is not in any way officially supported. -CURRENT using To track &os.current;: Join the &a.current.name; and the &a.svn-src-head.name; lists. This is essential in order to see the comments that people are making about the current state of the system and to receive important bulletins about the current state of &os.current;. The &a.svn-src-head.name; list records the commit log entry for each change as it is made, along with any pertinent information on possible side effects. To join these lists, go to &a.mailman.lists.link;, click on the list to subscribe to, and follow the instructions. In order to track changes to the whole source tree, not just the changes to &os.current;, subscribe to the &a.svn-src-all.name; list. Synchronize with the &os.current; sources. Typically, svn is used to check out the -CURRENT code from the head branch of one of the Subversion mirror sites listed in . Due to the size of the repository, some users choose to only synchronize the sections of source that interest them or which they are contributing patches to. However, users that plan to compile the operating system from source must download all of &os.current;, not just selected portions. Before compiling &os.current; -CURRENT compiling , read /usr/src/Makefile very carefully and follow the instructions in . Read the &a.current; and /usr/src/UPDATING to stay up-to-date on other bootstrapping procedures that sometimes become necessary on the road to the next release. Be active! &os.current; users are encouraged to submit their suggestions for enhancements or bug fixes. Suggestions with accompanying code are always welcome. Updating &os; from Source Updating &os; by compiling from source offers several advantages over binary updates. Code can be built with options to take advantage of specific hardware. Parts of the base system can be built with non-default settings, or left out entirely where they are not needed or desired. The build process takes longer to update a system than just installing binary updates, but allows complete customization to produce a tailored version of &os;. Quick Start This is a quick reference for the typical steps used to update &os; by building from source. Later sections describe the process in more detail. Update and Build &prompt.root; svn update /usr/src check /usr/src/UPDATING &prompt.root; cd /usr/src &prompt.root; make -j4 buildworld &prompt.root; make -j4 kernel &prompt.root; shutdown -r now &prompt.root; cd /usr/src &prompt.root; make installworld &prompt.root; mergemaster -Ui &prompt.root; shutdown -r now Get the latest version of the source. See for more information on obtaining and updating source. Check /usr/src/UPDATING for any manual steps required before or after building from source. Go to the source directory. Compile the world, everything except the kernel. Compile and install the kernel. This is equivalent to make buildkernel installkernel. Reboot the system to the new kernel. Go to the source directory. Install the world. Update and merge configuration files in /etc/. Restart the system to use the newly-built world and kernel. Preparing for a Source Update Read /usr/src/UPDATING. Any manual steps that must be performed before or after an update are described in this file. Updating the Source &os; source code is located in /usr/src/. The preferred method of updating this source is through the Subversion version control system. Verify that the source code is under version control: &prompt.root; svn info /usr/src Path: /usr/src Working Copy Root Path: /usr/src ... This indicates that /usr/src/ is under version control and can be updated with &man.svn.1;: &prompt.root; svn update /usr/src The update process can take some time if the directory has not been updated recently. After it finishes, the source code is up to date and the build process described in the next section can begin. Obtaining the Source If the output says '/usr/src' is not a working copy, the files there are missing or were installed with a different method. A new checkout of the source is required. &os; Versions and Repository Paths uname -r Output Repository Path Description X.Y-RELEASE base/releng/X.Y The Release version plus only critical security and bug fix patches. This branch is recommended for most users. X.Y-STABLE base/stable/X The Release version plus all additional development on that branch. STABLE refers to the Applications Binary Interface (ABI) not changing, so software compiled for earlier versions still runs. For example, software compiled to run on &os; 10.1 will still run on &os; 10-STABLE compiled later. STABLE branches occasionally have bugs or incompatibilities which might affect users, although these are typically fixed quickly. X-CURRENT base/head/ The latest unreleased development version of &os;. The CURRENT branch can have major bugs or incompatibilities and is recommended only for advanced users.
Determine which version of &os; is being used with &man.uname.1;: &prompt.root; uname -r 10.3-RELEASE Based on , the source used to update 10.3-RELEASE has a repository path of base/releng/10.3. That path is used when checking out the source: &prompt.root; mv /usr/src /usr/src.bak &prompt.root; svn checkout https://svn.freebsd.org/base/releng/10.3 /usr/src Move the old directory out of the way. If there are no local modifications in this directory, it can be deleted. The path from is added to the repository URL. The third parameter is the destination directory for the source code on the local system. Building from Source The world, or all of the operating system except the kernel, is compiled. This is done first to provide up-to-date tools to build the kernel. Then the kernel itself is built: &prompt.root; cd /usr/src &prompt.root; make buildworld &prompt.root; make buildkernel The compiled code is written to /usr/obj. These are the basic steps. Additional options to control the build are described below. Performing a Clean Build Some versions of the &os; build system leave previously-compiled code in the temporary object directory, /usr/obj. This can speed up later builds by avoiding recompiling code that has not changed. To force a clean rebuild of everything, use cleanworld before starting a build: &prompt.root; make cleanworld Setting the Number of Jobs Increasing the number of build jobs on multi-core processors can improve build speed. Determine the number of cores with sysctl hw.ncpu. Processors vary, as do the build systems used with different versions of &os;, so testing is the only sure method to tell how a different number of jobs affects the build speed. For a starting point, consider values between half and double the number of cores. The number of jobs is specified with . Increasing the Number of Build Jobs Building the world and kernel with four jobs: &prompt.root; make -j4 buildworld buildkernel Building Only the Kernel A buildworld must be completed if the source code has changed. After that, a buildkernel to build a kernel can be run at any time. To build just the kernel: &prompt.root; cd /usr/src &prompt.root; make buildkernel Building a Custom Kernel The standard &os; kernel is based on a kernel config file called GENERIC. The GENERIC kernel includes the most commonly-needed device drivers and options. Sometimes it is useful or necessary to build a custom kernel, adding or removing device drivers or options to fit a specific need. For example, someone developing a small embedded computer with severely limited RAM could remove unneeded device drivers or options to make the kernel slightly smaller. Kernel config files are located in /usr/src/sys/arch/conf/, where arch is the output from uname -m. On most computers, that is amd64, giving a config file directory of /usr/src/sys/amd64/conf/. /usr/src can be deleted or recreated, so it is preferable to keep custom kernel config files in a separate directory, like /root. Link the kernel config file into the conf directory. If that directory is deleted or overwritten, the kernel config can be re-linked into the new one. A custom config file can be created by copying the GENERIC config file. In this example, the new custom kernel is for a storage server, so is named STORAGESERVER: &prompt.root; cp /usr/src/sys/amd64/conf/GENERIC /root/STORAGESERVER &prompt.root; cd /usr/src/sys/amd64/conf &prompt.root; ln -s /root/STORAGESERVER . /root/STORAGESERVER is then edited, adding or removing devices or options as shown in &man.config.5;. The custom kernel is built by setting KERNCONF to the kernel config file on the command line: &prompt.root; make buildkernel KERNCONF=STORAGESERVER Installing the Compiled Code After the buildworld and buildkernel steps have been completed, the new kernel and world are installed: &prompt.root; cd /usr/src &prompt.root; make installkernel &prompt.root; shutdown -r now &prompt.root; cd /usr/src &prompt.root; make installworld &prompt.root; shutdown -r now If a custom kernel was built, KERNCONF must also be set to use the new custom kernel: &prompt.root; cd /usr/src &prompt.root; make installkernel KERNCONF=STORAGESERVER &prompt.root; shutdown -r now &prompt.root; cd /usr/src &prompt.root; make installworld &prompt.root; shutdown -r now Completing the Update A few final tasks complete the update. Any modified configuration files are merged with the new versions, outdated libraries are located and removed, then the system is restarted. Merging Configuration Files with &man.mergemaster.8; &man.mergemaster.8; provides an easy way to merge changes that have been made to system configuration files with new versions of those files. With , &man.mergemaster.8; automatically updates files that have not been user-modified and installs new files that are not already present: &prompt.root; mergemaster -Ui If a file must be manually merged, an interactive display allows the user to choose which portions of the files are kept. See &man.mergemaster.8; for more information. Checking for Outdated Files and Libraries Some obsolete files or directories can remain after an update. These files can be located: &prompt.root; make check-old and deleted: &prompt.root; make delete-old Some obsolete libraries can also remain. These can be detected with: &prompt.root; make check-old-libs and deleted with &prompt.root; make delete-old-libs Programs which were still using those old libraries will stop working when the library has been deleted. These programs must be rebuilt or replaced after deleting the old libraries. When all the old files or directories are known to be safe to delete, pressing y and Enter to delete each file can be avoided by setting BATCH_DELETE_OLD_FILES in the command. For example: &prompt.root; make BATCH_DELETE_OLD_FILES=yes delete-old-libs Restarting After the Update The last step after updating is to restart the computer so all the changes take effect: &prompt.root; shutdown -r now Tracking for Multiple Machines Mike Meyer Contributed by NFS installing multiple machines When multiple machines need to track the same source tree, it is a waste of disk space, network bandwidth, and CPU cycles to have each system download the sources and rebuild everything. The solution is to have one machine do most of the work, while the rest of the machines mount that work via NFS. This section outlines a method of doing so. For more information about using NFS, refer to . First, identify a set of machines which will run the same set of binaries, known as a build set. Each machine can have a custom kernel, but will run the same userland binaries. From that set, choose a machine to be the build machine that the world and kernel are built on. Ideally, this is a fast machine that has sufficient spare CPU to run make buildworld and make buildkernel. Select a machine to be the test machine, which will test software updates before they are put into production. This must be a machine that can afford to be down for an extended period of time. It can be the build machine, but need not be. All the machines in this build set need to mount /usr/obj and /usr/src from the build machine via NFS. For multiple build sets, /usr/src should be on one build machine, and NFS mounted on the rest. Ensure that /etc/make.conf and /etc/src.conf on all the machines in the build set agree with the build machine. That means that the build machine must build all the parts of the base system that any machine in the build set is going to install. Also, each build machine should have its kernel name set with KERNCONF in /etc/make.conf, and the build machine should list them all in its KERNCONF, listing its own kernel first. The build machine must have the kernel configuration files for each machine in its /usr/src/sys/arch/conf. On the build machine, build the kernel and world as described in , but do not install anything on the build machine. Instead, install the built kernel on the test machine. On the test machine, mount /usr/src and /usr/obj via NFS. Then, run shutdown now to go to single-user mode in order to install the new kernel and world and run mergemaster as usual. When done, reboot to return to normal multi-user operations. After verifying that everything on the test machine is working properly, use the same procedure to install the new software on each of the other machines in the build set. The same methodology can be used for the ports tree. The first step is to share /usr/ports via NFS to all the machines in the build set. To configure /etc/make.conf to share distfiles, set DISTDIR to a common shared directory that is writable by whichever user root is mapped to by the NFS mount. Each machine should set WRKDIRPREFIX to a local build directory, if ports are to be built locally. Alternately, if the build system is to build and distribute packages to the machines in the build set, set PACKAGES on the build system to a directory similar to DISTDIR. Index: head/en_US.ISO8859-1/books/handbook/eresources/chapter.xml =================================================================== --- head/en_US.ISO8859-1/books/handbook/eresources/chapter.xml (revision 50962) +++ head/en_US.ISO8859-1/books/handbook/eresources/chapter.xml (revision 50963) @@ -1,2448 +1,2448 @@ Resources on the Internet The rapid pace of &os; progress makes print media impractical as a means of following the latest developments. Electronic resources are the best, if not often the only, way to stay informed of the latest advances. Since &os; is a volunteer effort, the user community itself also generally serves as a technical support department of sorts, with electronic mail, web forums, and USENET news being the most effective way of reaching that community. The most important points of contact with the &os; user community are outlined below. Please send other resources not mentioned here to the &a.doc; so that they may also be included. Websites The &os; Forums provide a web based discussion forum for &os; questions and technical discussion. Planet &os; offers an aggregation feed of dozens of blogs written by &os; developers. Many developers use this to post quick notes about what they are working on, new patches, and other works in progress. The BSDConferences YouTube Channel provides a collection of high quality videos from BSD conferences around the world. This is a great way to watch key developers give presentations about new work in &os;. Mailing Lists The mailing lists are the most direct way of addressing questions or opening a technical discussion to a concentrated &os; audience. There are a wide variety of lists on a number of different &os; topics. Sending questions to the most appropriate mailing list will invariably assure a faster and more accurate response. The charters for the various lists are given at the bottom of this document. Please read the charter before joining or sending mail to any list. Most list subscribers receive many hundreds of &os; related messages every day, and the charters and rules for use are meant to keep the signal-to-noise ratio of the lists high. To do less would see the mailing lists ultimately fail as an effective communications medium for the Project. To test the ability to send email to &os; lists, send a test message to &a.test.name;. Please do not send test messages to any other list. When in doubt about what list to post a question to, see How to get best results from the FreeBSD-questions mailing list. Before posting to any list, please learn about how to best use the mailing lists, such as how to help avoid frequently-repeated discussions, by reading the Mailing List Frequently Asked Questions (FAQ) document. Archives are kept for all of the mailing lists and can be searched using the &os; World Wide Web server. The keyword searchable archive offers an excellent way of finding answers to frequently asked questions and should be consulted before posting a question. Note that this also means that messages sent to &os; mailing lists are archived in perpetuity. When protecting privacy is a concern, consider using a disposable secondary email address and posting only public information. List Summary General lists: The following are general lists which anyone is free (and encouraged) to join: List Purpose &a.advocacy.name; &os; Evangelism &a.announce.name; Important events and Project milestones (moderated) &a.arch.name; Architecture and design discussions &a.bugbusters.name; Discussions pertaining to the maintenance of the &os; problem report database and related tools &a.bugs.name; Bug reports &a.chat.name; Non-technical items related to the &os; community &a.chromium.name; &os;-specific Chromium issues &a.current.name; Discussion concerning the use of &os.current; &a.isp.name; Issues for Internet Service Providers using &os; &a.jobs.name; &os; employment and consulting opportunities &a.questions.name; User questions and technical support &a.security-notifications.name; Security notifications (moderated) &a.stable.name; Discussion concerning the use of &os.stable; &a.test.name; Where to send test messages instead of to one of the actual lists Technical lists: The following lists are for technical discussion. Read the charter for each list carefully before joining or sending mail to one as there are firm guidelines for their use and content. List Purpose &a.acpi.name; ACPI and power management development &a.afs.name; Porting AFS to &os; &a.amd64.name; Porting &os; to AMD64 systems (moderated) &a.apache.name; Discussion about Apache related ports &a.arm.name; Porting &os; to &arm; processors &a.atm.name; Using ATM networking with &os; &a.bluetooth.name; Using &bluetooth; technology in &os; &a.cloud.name; &os; on cloud platforms (EC2, GCE, Azure, etc.) &a.cluster.name; Using &os; in a clustered environment &a.database.name; Discussing database use and development under &os; &a.desktop.name; Using and improving &os; on the desktop &a.doc.name; Creating &os; related documents &a.drivers.name; Writing device drivers for &os; &a.dtrace.name; Using and working on DTrace in &os; &a.eclipse.name; &os; users of Eclipse IDE, tools, rich client applications and ports. &a.embedded.name; Using &os; in embedded applications &a.eol.name; Peer support of &os;-related software that is no longer supported by the &os; Project. &a.emulation.name; Emulation of other systems such as Linux/&ms-dos;/&windows; &a.enlightenment.name; Porting Enlightenment and Enlightenment applications &a.firewire.name; &os; &firewire; (iLink, IEEE 1394) technical discussion &a.fortran.name; Fortran on &os; &a.fs.name; File systems &a.games.name; Support for Games on &os; &a.gecko.name; Gecko Rendering Engine issues &a.geom.name; GEOM-specific discussions and implementations &a.git.name; Discussion of git use in the &os; project &a.gnome.name; Porting GNOME and GNOME applications &a.hackers.name; General technical discussion &a.hardware.name; General discussion of hardware for running &os; &a.i18n.name; &os; Internationalization &a.ia32.name; &os; on the IA-32 (&intel; x86) platform &a.ia64.name; Porting &os; to &intel;'s upcoming IA64 systems &a.infiniband.name; Infiniband on &os; &a.ipfw.name; Technical discussion concerning the redesign of the IP firewall code &a.isdn.name; ISDN developers &a.jail.name; Discussion about the &man.jail.8; facility &a.java.name; &java; developers and people porting &jdk;s to &os; &a.lfs.name; Porting LFS to &os; &a.mips.name; Porting &os; to &mips; &a.mobile.name; Discussions about mobile computing &a.mono.name; Mono and C# applications on &os; &a.multimedia.name; Multimedia applications &a.newbus.name; Technical discussions about bus architecture &a.net.name; Networking discussion and TCP/IP source code &a.numerics.name; Discussions of high quality implementation of libm functions &a.office.name; Office applications on &os; &a.performance.name; Performance tuning questions for high performance/load installations &a.perl.name; Maintenance of a number of Perl-related ports &a.pf.name; Discussion and questions about the packet filter firewall system &a.pkg.name; Binary package management and package tools discussion &a.pkg-fallout.name; Fallout logs from package building &a.pkgbase.name; Packaging the &os; base system &a.platforms.name; Concerning ports to non &intel; architecture platforms &a.ports.name; Discussion of the Ports Collection &a.ports-announce.name; Important news and instructions about the Ports Collection (moderated) &a.ports-bugs.name; Discussion of the ports bugs/PRs &a.ppc.name; Porting &os; to the &powerpc; &a.proliant.name; Technical discussion of &os; on HP ProLiant server platforms &a.python.name; &os;-specific Python issues &a.rc.name; Discussion related to the rc.d system and its development &a.realtime.name; Development of realtime extensions to &os; &a.ruby.name; &os;-specific Ruby discussions &a.scsi.name; The SCSI subsystem &a.security.name; Security issues affecting &os; &a.small.name; Using &os; in embedded applications (obsolete; use &a.embedded.name; instead) &a.snapshots.name; &os; Development Snapshot Announcements &a.sparc.name; Porting &os; to &sparc; based systems &a.standards.name; &os;'s conformance to the C99 and the &posix; standards &a.sysinstall.name; &man.sysinstall.8; development &a.tcltk.name; &os;-specific Tcl/Tk discussions &a.testing.name; Testing on &os; &a.tex.name; Porting TeX and its applications to &os; &a.threads.name; Threading in &os; &a.tilera.name; Porting &os; to the Tilera family of CPUs &a.tokenring.name; Support Token Ring in &os; &a.toolchain.name; Maintenance of &os;'s integrated toolchain &a.translators.name; Translating &os; documents and programs &a.transport.name; Discussions of transport level network protocols in &os; &a.usb.name; Discussing &os; support for USB &a.virtualization.name; Discussion of various virtualization techniques supported by &os; &a.vuxml.name; Discussion on VuXML infrastructure &a.x11.name; Maintenance and support of X11 on &os; &a.xen.name; Discussion of the &os; port to &xen; — implementation and usage &a.xfce.name; XFCE for &os; — porting and maintaining &a.zope.name; Zope for &os; — porting and maintaining Limited lists: The following lists are for more specialized (and demanding) audiences and are probably not of interest to the general public. It is also a good idea to establish a presence in the technical lists before joining one of these limited lists in order to understand the communications etiquette involved. List Purpose &a.hubs.name; People running mirror sites (infrastructural support) &a.usergroups.name; User group coordination &a.wip-status.name; &os; Work-In-Progress Status &a.wireless.name; Discussions of 802.11 stack, tools, device driver development Digest lists: All of the above lists are available in a digest format. Once subscribed to a list, the digest options can be changed in the account options section. SVN lists: The following lists are for people interested in seeing the log messages for changes to various areas of the source tree. They are Read-Only lists and should not have mail sent to them. List Source area Area Description (source for) &a.svn-doc-all.name; /usr/doc All changes to the doc Subversion repository (except for user, projects and translations) &a.svn-doc-head.name; /usr/doc All changes to the head branch of the doc Subversion repository &a.svn-doc-projects.name; /usr/doc/projects All changes to the projects area of the doc Subversion repository &a.svn-doc-svnadmin.name; /usr/doc All changes to the administrative scripts, hooks, and other configuration data of the doc Subversion repository &a.svn-ports-all.name; /usr/ports All changes to the ports Subversion repository &a.svn-ports-head.name; /usr/ports All changes to the head branch of the ports Subversion repository &a.svn-ports-svnadmin.name; /usr/ports All changes to the administrative scripts, hooks, and other configuration data of the ports Subversion repository &a.svn-src-all.name; /usr/src All changes to the src Subversion repository (except for user and projects) &a.svn-src-head.name; /usr/src All changes to the head branch of the src Subversion repository (the &os;-CURRENT branch) &a.svn-src-projects.name; /usr/projects All changes to the projects area of the src Subversion repository &a.svn-src-release.name; /usr/src All changes to the releases area of the src Subversion repository &a.svn-src-releng.name; /usr/src All changes to the releng branches of the src Subversion repository (the security / release engineering branches) &a.svn-src-stable.name; /usr/src All changes to the all stable branches of the src Subversion repository &a.svn-src-stable-6.name; /usr/src All changes to the stable/6 branch of the src Subversion repository &a.svn-src-stable-7.name; /usr/src All changes to the stable/7 branch of the src Subversion repository &a.svn-src-stable-8.name; /usr/src All changes to the stable/8 branch of the src Subversion repository &a.svn-src-stable-9.name; /usr/src All changes to the stable/9 branch of the src Subversion repository &a.svn-src-stable-10.name; /usr/src All changes to the stable/10 branch of the src Subversion repository &a.svn-src-stable-11.name; /usr/src All changes to the stable/11 branch of the src Subversion repository &a.svn-src-stable-other.name; /usr/src All changes to the older stable branches of the src Subversion repository &a.svn-src-svnadmin.name; /usr/src All changes to the administrative scripts, hooks, and other configuration data of the src Subversion repository &a.svn-src-user.name; /usr/src All changes to the experimental user area of the src Subversion repository &a.svn-src-vendor.name; /usr/src All changes to the vendor work area of the src Subversion repository How to Subscribe To subscribe to a list, click the list name at &a.mailman.lists.link;. The page that is displayed should contain all of the necessary subscription instructions for that list. To actually post to a given list, send mail to listname@FreeBSD.org. It will then be redistributed to mailing list members world-wide. To unsubscribe from a list, click on the URL found at the bottom of every email received from the list. It is also possible to send an email to listname-unsubscribe@FreeBSD.org to unsubscribe. It is important to keep discussion in the technical mailing lists on a technical track. To only receive important announcements, instead join the &a.announce;, which is intended for infrequent traffic. List Charters All &os; mailing lists have certain basic rules which must be adhered to by anyone using them. Failure to comply with these guidelines will result in two (2) written warnings from the &os; Postmaster postmaster@FreeBSD.org, after which, on a third offense, the poster will removed from all &os; mailing lists and filtered from further posting to them. We regret that such rules and measures are necessary at all, but today's Internet is a pretty harsh environment, it would seem, and many fail to appreciate just how fragile some of its mechanisms are. Rules of the road: The topic of any posting should adhere to the basic charter of the list it is posted to. If the list is about technical issues, the posting should contain technical discussion. Ongoing irrelevant chatter or flaming only detracts from the value of the mailing list for everyone on it and will not be tolerated. For free-form discussion on no particular topic, the &a.chat; is freely available and should be used instead. No posting should be made to more than 2 mailing lists, and only to 2 when a clear and obvious need to post to both lists exists. For most lists, there is already a great deal of subscriber overlap and except for the most esoteric mixes (say -stable & -scsi), there really is no reason to post to more than one list at a time. If a message is received with multiple mailing lists on the Cc line, trim the Cc line before replying. The person who replies is still responsible for cross-posting, no matter who the originator might have been. Personal attacks and profanity (in the context of an argument) are not allowed, and that includes users and developers alike. Gross breaches of netiquette, like excerpting or reposting private mail when permission to do so was not and would not be forthcoming, are frowned upon but not specifically enforced. However, there are also very few cases where such content would fit within the charter of a list and it would therefore probably rate a warning (or ban) on that basis alone. Advertising of non-&os; related products or services is strictly prohibited and will result in an immediate ban if it is clear that the offender is advertising by spam. Individual list charters: &a.acpi.name; ACPI and power management development &a.afs.name; Andrew File System This list is for discussion on porting and using AFS from CMU/Transarc &a.announce.name; Important events / milestones This is the mailing list for people interested only in occasional announcements of significant &os; events. This includes announcements about snapshots and other releases. It contains announcements of new &os; capabilities. It may contain calls for volunteers etc. This is a low volume, strictly moderated mailing list. &a.arch.name; Architecture and design discussions This list is for discussion of the &os; architecture. Messages will mostly be kept strictly technical in nature. Examples of suitable topics are: How to re-vamp the build system to have several customized builds running at the same time. What needs to be fixed with VFS to make Heidemann layers work. How do we change the device driver interface to be able to use the same drivers cleanly on many buses and architectures. How to write a network driver. &a.bluetooth.name; &bluetooth; in &os; This is the forum where &os;'s &bluetooth; users congregate. Design issues, implementation details, patches, bug reports, status reports, feature requests, and all matters related to &bluetooth; are fair game. &a.bugbusters.name; Coordination of the Problem Report handling effort The purpose of this list is to serve as a coordination and discussion forum for the Bugmeister, his Bugbusters, and any other parties who have a genuine interest in the PR database. This list is not for discussions about specific bugs, patches or PRs. &a.bugs.name; Bug reports This is the mailing list for reporting bugs in &os;. Whenever possible, bugs should be submitted using the web interface to it. &a.chat.name; Non technical items related to the &os; community This list contains the overflow from the other lists about non-technical, social information. It includes discussion about whether Jordan looks like a toon ferret or not, whether or not to type in capitals, who is drinking too much coffee, where the best beer is brewed, who is brewing beer in their basement, and so on. Occasional announcements of important events (such as upcoming parties, weddings, births, new jobs, etc) can be made to the technical lists, but the follow ups should be directed to this -chat list. &a.chromium.name; &os;-specific Chromium issues This is a list for the discussion of Chromium support for &os;. This is a technical list to discuss development and installation of Chromium. &a.cloud.name; Running &os; on various cloud platforms This list discusses running &os; on Amazon EC2, Google Compute Engine, Microsoft Azure, and other cloud computing platforms. &a.core.name; &os; core team This is an internal mailing list for use by the core members. Messages can be sent to it when a serious &os;-related matter requires arbitration or high-level scrutiny. &a.current.name; Discussions about the use of &os.current; This is the mailing list for users of &os.current;. It includes warnings about new features coming out in -CURRENT that will affect the users, and instructions on steps that must be taken to remain -CURRENT. Anyone running CURRENT must subscribe to this list. This is a technical mailing list for which strictly technical content is expected. &a.desktop.name; Using and improving &os; on the desktop This is a forum for discussion of &os; on the desktop. It is primarily a place for desktop porters and users to discuss issues and improve &os;'s desktop support. &a.doc.name; Documentation Project This mailing list is for the discussion of issues and projects related to the creation of documentation for &os;. The members of this mailing list are collectively referred to as The &os; Documentation Project. It is an open list; feel free to join and contribute! &a.drivers.name; Writing device drivers for &os; This is a forum for technical discussions related to device drivers on &os;. It is primarily a place for device driver writers to ask questions about how to write device drivers using the APIs in the &os; kernel. &a.dtrace.name; Using and working on DTrace in &os; DTrace is an integrated component of &os; that provides a framework for understanding the kernel as well as user space programs at run time. The mailing list is an archived discussion for developers of the code as well as those using it. &a.eclipse.name; &os; users of Eclipse IDE, tools, rich client applications and ports. The intention of this list is to provide mutual support for everything to do with choosing, installing, using, developing and maintaining the Eclipse IDE, tools, rich client applications on the &os; platform and assisting with the porting of Eclipse IDE and plugins to the &os; environment. The intention is also to facilitate exchange of information between the Eclipse community and the &os; community to the mutual benefit of both. Although this list is focused primarily on the needs of Eclipse users it will also provide a forum for those who would like to develop &os; specific applications using the Eclipse framework. &a.embedded.name; Using &os; in embedded applications This list discusses topics related to using &os; in embedded systems. This is a technical mailing list for which strictly technical content is expected. For the purpose of this list, embedded systems are those computing devices which are not desktops and which usually serve a single purpose as opposed to being general computing environments. Examples include, but are not limited to, all kinds of phone handsets, network equipment such as routers, switches and PBXs, remote measuring equipment, PDAs, Point Of Sale systems, and so on. &a.emulation.name; Emulation of other systems such as Linux/&ms-dos;/&windows; This is a forum for technical discussions related to running programs written for other operating systems on &os;. &a.enlightenment.name; Enlightenment Discussions concerning the Enlightenment Desktop Environment for &os; systems. This is a technical mailing list for which strictly technical content is expected. &a.eol.name; Peer support of &os;-related software that is no longer supported by the &os; Project. This list is for those interested in providing or making use of peer support of &os;-related software for which the &os; Project no longer provides official support in the form of security advisories and patches. &a.firewire.name; &firewire; (iLink, IEEE 1394) This is a mailing list for discussion of the design and implementation of a &firewire; (aka IEEE 1394 aka iLink) subsystem for &os;. Relevant topics specifically include the standards, bus devices and their protocols, adapter boards/cards/chips sets, and the architecture and implementation of code for their proper support. &a.fortran.name; Fortran on &os; This is the mailing list for discussion of Fortran related ports on &os;: compilers, libraries, scientific and engineering applications from laptops to HPC clusters. &a.fs.name; File systems Discussions concerning &os; filesystems. This is a technical mailing list for which strictly technical content is expected. &a.games.name; Games on &os; This is a technical list for discussions related to bringing games to &os;. It is for individuals actively working on porting games to &os;, to bring up problems or discuss alternative solutions. Individuals interested in following the technical discussion are also welcome. &a.gecko.name; Gecko Rendering Engine This is a forum about Gecko applications using &os;. Discussion centers around Gecko Ports applications, their installation, their development and their support within &os;. &a.geom.name; GEOM Discussions specific to GEOM and related implementations. This is a technical mailing list for which strictly technical content is expected. &a.git.name; Use of git in the &os; project Discussions of how to use git in &os; infrastructure including the github mirror and other uses of git for project collaboration. Discussion area for people using git against the &os; github mirror. People wanting to get started with the mirror or git in general on &os; can ask here. &a.gnome.name; GNOME Discussions concerning The GNOME Desktop Environment for &os; systems. This is a technical mailing list for which strictly technical content is expected. &a.infiniband.name; Infiniband on &os; Technical mailing list discussing Infiniband, OFED, and OpenSM on &os;. &a.ipfw.name; IP Firewall This is the forum for technical discussions concerning the redesign of the IP firewall code in &os;. This is a technical mailing list for which strictly technical content is expected. &a.ia64.name; Porting &os; to IA64 This is a technical mailing list for individuals actively working on porting &os; to the IA-64 platform from &intel;, to bring up problems or discuss alternative solutions. Individuals interested in following the technical discussion are also welcome. &a.isdn.name; ISDN Communications This is the mailing list for people discussing the development of ISDN support for &os;. &a.java.name; &java; Development This is the mailing list for people discussing the development of significant &java; applications for &os; and the porting and maintenance of &jdk;s. &a.jobs.name; Jobs offered and sought This is a forum for posting employment notices specifically related to &os; and resumes from those seeking &os;-related employment. This is not a mailing list for general employment issues since adequate forums for that already exist elsewhere. Note that this list, like other FreeBSD.org mailing lists, is distributed worldwide. Be clear about the geographic location and the extent to which telecommuting or assistance with relocation is available. Email should use open formats only — preferably plain text, but basic Portable Document Format (PDF), HTML, and a few others are acceptable to many readers. Closed formats such as µsoft; Word (.doc) will be rejected by the mailing list server. &a.kde.name; KDE Discussions concerning KDE on &os; systems. This is a technical mailing list for which strictly technical content is expected. &a.hackers.name; Technical discussions This is a forum for technical discussions related to &os;. This is the primary technical mailing list. It is for individuals actively working on &os;, to bring up problems or discuss alternative solutions. Individuals interested in following the technical discussion are also welcome. This is a technical mailing list for which strictly technical content is expected. &a.hardware.name; General discussion of &os; hardware General discussion about the types of hardware that &os; runs on, various problems and suggestions concerning what to buy or avoid. &a.hubs.name; Mirror sites Announcements and discussion for people who run &os; mirror sites. &a.isp.name; Issues for Internet Service Providers This mailing list is for discussing topics relevant to Internet Service Providers (ISPs) using &os;. This is a technical mailing list for which strictly technical content is expected. &a.mono.name; Mono and C# applications on &os; This is a list for discussions related to the Mono development framework on &os;. This is a technical mailing list. It is for individuals actively working on porting Mono or C# applications to &os;, to bring up problems or discuss alternative solutions. Individuals interested in following the technical discussion are also welcome. &a.office.name; Office applications on &os; Discussion centers around office applications, their installation, their development and their support within &os;. &a.ops-announce.name; Project Infrastructure Announcements This is the mailing list for people interested in changes and issues related to the FreeBSD.org Project infrastructure. This moderated list is strictly for announcements: no replies, requests, discussions, or opinions. &a.performance.name; Discussions about tuning or speeding up &os; This mailing list exists to provide a place for hackers, administrators, and/or concerned parties to discuss performance related topics pertaining to &os;. Acceptable topics includes talking about &os; installations that are either under high load, are experiencing performance problems, or are pushing the limits of &os;. Concerned parties that are willing to work toward improving the performance of &os; are highly encouraged to subscribe to this list. This is a highly technical list ideally suited for experienced &os; users, hackers, or administrators interested in keeping &os; fast, robust, and scalable. This list is not a question-and-answer list that replaces reading through documentation, but it is a place to make contributions or inquire about unanswered performance related topics. &a.pf.name; Discussion and questions about the packet filter firewall system Discussion concerning the packet filter (pf) firewall system in terms of &os;. Technical discussion and user questions are both welcome. This list is also a place to discuss the ALTQ QoS framework. &a.pkg.name; Binary package management and package tools discussion Discussion of all aspects of managing &os; systems by using binary packages to install software, including binary package toolkits and formats, their development and support within &os;, package repository management, and third party packages. Note that discussion of ports which fail to generate packages correctly should generally be considered as ports problems, and so inappropriate for this list. &a.pkg-fallout.name; Fallout logs from package building All packages building failures logs from the package building clusters &a.pkgbase.name; Packaging the &os; base system. Discussions surrounding implementation and issues regarding packaging the &os; base system. &a.platforms.name; Porting to Non &intel; platforms Cross-platform &os; issues, general discussion and proposals for non &intel; &os; ports. This is a technical mailing list for which strictly technical content is expected. &a.ports.name; Discussion of ports Discussions concerning &os;'s ports collection (/usr/ports), ports infrastructure, and general ports coordination efforts. This is a technical mailing list for which strictly technical content is expected. &a.ports-announce.name; Important news and instructions about the &os; Ports Collection Important news for developers, porters, and users of the Ports Collection (/usr/ports), including architecture/infrastructure changes, new capabilities, critical upgrade instructions, and release engineering information. This is a low-volume mailing list, intended for announcements. &a.ports-bugs.name; Discussion of ports bugs Discussions concerning problem reports for &os;'s ports collection (/usr/ports), proposed ports, or modifications to ports. This is a technical mailing list for which strictly technical content is expected. &a.proliant.name; Technical discussion of &os; on HP ProLiant server platforms This mailing list is to be used for the technical discussion of the usage of &os; on HP ProLiant servers, including the discussion of ProLiant-specific drivers, management software, configuration tools, and BIOS updates. As such, this is the primary place to discuss the hpasmd, hpasmcli, and hpacucli modules. &a.python.name; Python on &os; This is a list for discussions related to improving Python-support on &os;. This is a technical mailing list. It is for individuals working on porting Python, its third party modules and Zope stuff to &os;. Individuals interested in following the technical discussion are also welcome. &a.questions.name; User questions This is the mailing list for questions about &os;. Do not send how to questions to the technical lists unless the question is quite technical. &a.ruby.name; &os;-specific Ruby discussions This is a list for discussions related to the Ruby support on &os;. This is a technical mailing list. It is for individuals working on Ruby ports, third party libraries and frameworks. Individuals interested in the technical discussion are also welcome. &a.scsi.name; SCSI subsystem This is the mailing list for people working on the SCSI subsystem for &os;. This is a technical mailing list for which strictly technical content is expected. &a.security.name; Security issues &os; computer security issues (DES, Kerberos, known security holes and fixes, etc). This is a technical mailing list for which strictly technical discussion is expected. Note that this is not a question-and-answer list, but that contributions (BOTH question AND answer) to the FAQ are welcome. &a.security-notifications.name; Security Notifications Notifications of &os; security problems and fixes. This is not a discussion list. The discussion list is FreeBSD-security. &a.small.name; Using &os; in embedded applications This list discusses topics related to unusually small and embedded &os; installations. This is a technical mailing list for which strictly technical content is expected. This list has been obsoleted by &a.embedded.name;. &a.snapshots.name; &os; Development Snapshot Announcements This list provides notifications about the availability of new &os; development snapshots for the head/ and stable/ branches. &a.stable.name; Discussions about the use of &os.stable; This is the mailing list for users of &os.stable;. STABLE is the branch where development continues after a RELEASE, including bug fixes and new features. The ABI is kept stable for binary compatibility. It includes warnings about new features coming out in -STABLE that will affect the users, and instructions on steps that must be taken to remain -STABLE. Anyone running STABLE should subscribe to this list. This is a technical mailing list for which strictly technical content is expected. &a.standards.name; C99 & POSIX Conformance This is a forum for technical discussions related to &os; Conformance to the C99 and the POSIX standards. &a.teaching.name; Teaching with &os; Non technical mailing list discussing teaching with &os;. &a.testing.name; Testing on &os; Technical mailing list discussing testing on &os;, including ATF/Kyua, test build infrastructure, port tests to &os; from other operating systems (NetBSD, ...), etc. &a.tex.name; Porting TeX and its applications to &os; This is a technical mailing list for discussions related to TeX and its applications on &os;. It is for individuals actively working on porting TeX to FreeBSD, to bring up problems or discuss alternative solutions. Individuals interested in following the technical discussion are also welcome. &a.toolchain.name; Maintenance of &os;'s integrated toolchain This is the mailing list for discussions related to the maintenance of the toolchain shipped with &os;. This could include the state of Clang and GCC, but also pieces of software such as assemblers, linkers and debuggers. &a.transport.name; Discussions of transport level network protocols in &os; The transport mailing list exists for the discussion of issues and designs around the transport level protocols in the &os; network stack, including TCP, SCTP and UDP. Other networking topics, including driver specific and network protocol issues should be discussed on the &a.net;. &a.translators.name; Translating &os; documents and programs A discussion list where translators of &os; documents from English into other languages can talk about translation methods and tools. New members are asked to introduce themselves and mention the languages they are interested in translating. &a.usb.name; Discussing &os; support for USB This is a mailing list for technical discussions related to &os; support for USB. &a.usergroups.name; User Group Coordination List This is the mailing list for the coordinators from each of the local area Users Groups to discuss matters with each other and a designated individual from the Core Team. This mail list should be limited to meeting synopsis and coordination of projects that span User Groups. &a.virtualization.name; Discussion of various virtualization techniques supported by &os; A list to discuss the various virtualization techniques supported by &os;. On one hand the focus will be on the implementation of the basic functionality as well as adding new features. On the other hand users will have a forum to ask for help in case of problems or to discuss their use cases. &a.wip-status.name; &os; Work-In-Progress Status This mailing list can be used by developers to announce the creation and progress of &os; related work. Messages will be moderated. It is suggested to send the message "To:" a more topical &os; list and only "BCC:" this list. This way the WIP can also be discussed on the topical list, as no discussion is allowed on this list. Look inside the archives for examples of suitable messages. An editorial digest of the messages to this list might be posted to the &os; website every few months as part of the Status Reports http://www.freebsd.org/news/status/. + xlink:href="https://www.freebsd.org/news/status/">https://www.freebsd.org/news/status/. Past reports are archived. &a.wireless.name; Discussions of 802.11 stack, tools device driver development The FreeBSD-wireless list focuses on 802.11 stack (sys/net80211), device driver and tools development. This includes bugs, new features and maintenance. &a.xen.name; Discussion of the &os; port to &xen; — implementation and usage A list that focuses on the &os; &xen; port. The anticipated traffic level is small enough that it is intended as a forum for both technical discussions of the implementation and design details as well as administrative deployment issues. &a.xfce.name; XFCE This is a forum for discussions related to bring the XFCE environment to &os;. This is a technical mailing list. It is for individuals actively working on porting XFCE to &os;, to bring up problems or discuss alternative solutions. Individuals interested in following the technical discussion are also welcome. &a.zope.name; Zope This is a forum for discussions related to bring the Zope environment to &os;. This is a technical mailing list. It is for individuals actively working on porting Zope to &os;, to bring up problems or discuss alternative solutions. Individuals interested in following the technical discussion are also welcome. Filtering on the Mailing Lists The &os; mailing lists are filtered in multiple ways to avoid the distribution of spam, viruses, and other unwanted emails. The filtering actions described in this section do not include all those used to protect the mailing lists. Only certain types of attachments are allowed on the mailing lists. All attachments with a MIME content type not found in the list below will be stripped before an email is distributed on the mailing lists. application/octet-stream application/pdf application/pgp-signature application/x-pkcs7-signature message/rfc822 multipart/alternative multipart/related multipart/signed text/html text/plain text/x-diff text/x-patch Some of the mailing lists might allow attachments of other MIME content types, but the above list should be applicable for most of the mailing lists. If an email contains both an HTML and a plain text version, the HTML version will be removed. If an email contains only an HTML version, it will be converted to plain text. Usenet Newsgroups In addition to two &os; specific newsgroups, there are many others in which &os; is discussed or are otherwise relevant to &os; users. BSD Specific Newsgroups comp.unix.bsd.freebsd.announce comp.unix.bsd.freebsd.misc de.comp.os.unix.bsd (German) fr.comp.os.bsd (French) it.comp.os.freebsd (Italian) Other &unix; Newsgroups of Interest comp.unix comp.unix.questions comp.unix.admin comp.unix.programmer comp.unix.shell comp.unix.misc comp.unix.bsd X Window System comp.windows.x comp.windows.x.apps comp.windows.x.announce comp.emulators.ms-windows.wine Official Mirrors &chap.eresources.www.index.inc; &chap.mirrors.lastmod.inc; &chap.eresources.www.inc; Index: head/en_US.ISO8859-1/books/handbook/filesystems/chapter.xml =================================================================== --- head/en_US.ISO8859-1/books/handbook/filesystems/chapter.xml (revision 50962) +++ head/en_US.ISO8859-1/books/handbook/filesystems/chapter.xml (revision 50963) @@ -1,193 +1,193 @@ Other File Systems TomRhodesWritten by Synopsis File Systems File Systems Support File Systems File systems are an integral part of any operating system. They allow users to upload and store files, provide access to data, and make hard drives useful. Different operating systems differ in their native file system. Traditionally, the native &os; file system has been the Unix File System UFS which has been modernized as UFS2. Since &os; 7.0, the Z File System (ZFS) is also available as a native file system. See for more information. In addition to its native file systems, &os; supports a multitude of other file systems so that data from other operating systems can be accessed locally, such as data stored on locally attached USB storage devices, flash drives, and hard disks. This includes support for the &linux; Extended File System (EXT) and the Reiser file system. There are different levels of &os; support for the various file systems. Some require a kernel module to be loaded and others may require a toolset to be installed. Some non-native file system support is full read-write while others are read-only. After reading this chapter, you will know: The difference between native and supported file systems. Which file systems are supported by &os;. How to enable, configure, access, and make use of non-native file systems. Before reading this chapter, you should: Understand &unix; and &os; basics. Be familiar with the basics of kernel configuration and compilation. Feel comfortable installing software in &os;. Have some familiarity with disks, storage, and device names in &os;. &linux; File Systems &os; provides built-in support for several &linux; file systems. This section demonstrates how to load support for and how to mount the supported &linux; file systems. <acronym>ext2</acronym> Kernel support for ext2 file systems has been available since &os; 2.2. In &os; 8.x and earlier, the code is licensed under the GPL. Since &os; 9.0, the code has been rewritten and is now BSD licensed. The &man.ext2fs.5; driver allows the &os; kernel to both read and write to ext2 file systems. This driver can also be used to access ext3 and ext4 file systems. However, ext3 journaling and extended attributes are not supported. Support for ext4 is read-only. To access an ext file system, first load the kernel loadable module: &prompt.root; kldload ext2fs Then, mount the ext volume by specifying its &os; partition name and an existing mount point. This example mounts /dev/ad1s1 on /mnt: &prompt.root; mount -t ext2fs /dev/ad1s1 /mnt ReiserFS &os; provides read-only support for The Reiser file system, ReiserFS. To load the &man.reiserfs.5; driver: &prompt.root; kldload reiserfs Then, to mount a ReiserFS volume located on /dev/ad1s1: &prompt.root; mount -t reiserfs /dev/ad1s1 /mnt