amd64 is the term FreeBSD uses for 64-bit compatible x86 architectures (also known as "x86-64" or "x64"). Most modern computers should use amd64. Older hardware should use i386. If you are installing on a non-x86-compatible architecture select the platform which best matches the architecture you are using.
On the Getting FreeBSD page select [iso] next to the architecture you want to use.
Any of the following can be used:
|disc1.iso||Contains enough to install FreeBSD and a minimal set of packages.|
|dvd1.iso||Similar to disc1.iso but with additional packages.|
|memstick.img||A bootable image sufficient for writing to a USB stick.|
|bootonly.iso||A minimal image that requires network access during installation to completely install FreeBSD.|
pc98 users require these floppy images: floppies/boot.flp, floppies/kern1.flp, floppies/kern2.flp, and floppies/mfsroot1.flp. These images need to be written onto floppies by tools like dd(1).
Full instructions on this procedure and a little bit more about installation issues in general can be found in the Handbook entry on installing FreeBSD.
Common mistakes when preparing the boot media are:
Not downloading the image in binary mode when using FTP.
Some FTP clients default their transfer mode to ascii and attempt to change any end-of-line characters received to match the conventions used by the client's system. This will almost invariably corrupt the boot image. Check the SHA-256 of the downloaded boot image: if it is not exactly that on the server, then the download process is suspect.
To workaround: type binary at the FTP command prompt after getting connected to the server and before starting the download of the image.
Using the DOS copy command (or equivalent GUI tool) to transfer the boot image to floppy.
Programs like copy will not work as the boot image has been created to be booted into directly. The image has the complete content of the floppy, track for track, and is not meant to be placed on the floppy as a regular file. You have to transfer it to the floppy “raw”, using the low-level tools (e.g., fdimage or rawrite) described in the installation guide to FreeBSD.
For FreeBSD you will need a 486 or better PC, with 64 MB or more of RAM and at least 1 GB of hard disk space.
See also Chapter 4.
Customized FreeBSD installation media can be created by building a custom release. Follow the instructions in the Release Engineering article.
If Windows is installed first, then yes. FreeBSD's boot manager will then manage to boot Windows and FreeBSD. If you install Windows second, it will boorishly overwrite your boot manager without even asking. If that happens, see the next section.
This depends on what boot manager you have installed. The FreeBSD boot selection menu (likely what you are using if you end up in this situation) can be reinstalled using boot0cfg(8). For example, to restore the boot menu onto the disk ada0:
# boot0cfg -B ada0
The non-interactive MBR bootloader can be installed using gpart(8):
# gpart bootcode -b /boot/mbr ada0
For more complex situations, including GPT disks, see gpart(8).
The usual cause of this problem is a mis-configured CD-ROM drive. Many PCs now ship with the CD-ROM as the slave device on the secondary IDE controller, with no master device on that controller. This is illegal according to the ATAPI specification, but Windows plays fast and loose with the specification, and the BIOS ignores it when booting. This is why the BIOS was able to see the CD-ROM to boot from it, but why FreeBSD cannot see it to complete the install.
Reconfigure your system so that the CD-ROM is either the master device on the IDE controller it is attached to, or make sure that it is the slave on an IDE controller that also has a master device.
In general, no. There is nothing in the base system which requires the presence of the source to operate. Some ports, like sysutils/lsof, will not build unless the source is installed. In particular, if the port builds a kernel module or directly operates on kernel structures, the source must be installed.
Usually not. The supplied GENERIC kernel contains the drivers an ordinary computer will need. freebsd-update(8), the FreeBSD binary upgrade tool, cannot upgrade custom kernels, another reason to stick with the GENERIC kernel when possible. For computers with very limited RAM, such as embedded systems, it may be worthwhile to build a smaller custom kernel containing just the required drivers.
FreeBSD 7 and 8 use MD5 password hashing by default. Recent versions of FreeBSD use SHA512 by default. These are believed to be more secure than the traditional UNIX® password format, which used a scheme based on the DES algorithm. DES passwords are still available if you need to share your password file with legacy operating systems which still use the less secure password format. FreeBSD also allows you to use the Blowfish and MD5 password formats. Which password format to use for new passwords is controlled by the passwd_format login capability in /etc/login.conf, which takes values of des, blf (if these are available) or md5. See the login.conf(5) manual page for more information about login capabilities.
Memory limits depend on the platform used. On a standard i386™ install, the limit is 4 GB but more memory can be supported through pae(4). See instructions for using 4 GB or more memory on i386.
FreeBSD/pc98 has a limit of 4 GB memory, and PAE can not be used with it. Other architectures supported by FreeBSD have much higher theoretical limits on maximum memory (many terabytes).
For FFS file systems, the maximum theoretical limit is 8 TB (2 G blocks), or 16 TB for the default block size of 8 KB. In practice, there is a soft limit of 1 TB, but with modifications file systems with 4 TB are possible (and exist).
The maximum size of a single FFS file is approximately 1 G blocks, or 4 TB with a block size of 4 KB.
Table 3-1. Maximum File Sizes
|FS Block Size||Works||Should Work|
|4 KB||> 4 GB||4 TB - 1|
|8 KB||> 32 GB||32 TB - 1|
|16 KB||> 128 GB||32 TB - 1|
|32 KB||> 512 GB||64 TB - 1|
|64 KB||> 2048 GB||128 TB - 1|
When the FS block size is 4 KB, triple indirect blocks work and everything should be limited by the maximum FS block number that can be represented using triple indirect blocks (approx. 10243 + 10242 + 1024), but everything is limited by a (wrong) limit of 1 G - 1 on FS block numbers. The limit on FS block numbers should be 2 G - 1. There are some bugs for FS block numbers near 2 G - 1, but such block numbers are unreachable when the FS block size is 4 KB.
For block sizes of 8 KB and larger, everything should be limited by the 2 G - 1 limit on FS block numbers, but is actually limited by the 1 G - 1 limit on FS block numbers. Using the correct limit of 2 G - 1 blocks does cause problems.
Because your world and kernel are out of sync. This is not supported. Be sure you use make buildworld and make buildkernel to update your kernel.
You can boot by specifying the kernel directly at the second stage, pressing any key when the | shows up before loader is started.
HEAD users can set
WITH_BSDCONFIG in /etc/src.conf.
Users of 9.X and higher may also install