Synopsis #
The best FreeBSD resource depends on the question. An installed manual page describes the interface on the system in front of the administrator. The official Handbook explains supported concepts and procedures. Release notes and errata record version-specific changes. Community channels help investigate unclear behavior, while a reproducible defect belongs in the bug tracker.
This page provides a routing decision. It does not replace the official documentation, community rules, or a maintainer’s reporting instructions.
Start with the smallest authoritative source #
Use the narrowest source that owns the behavior:
| Question | Start here |
|---|---|
| What does this command, file, driver, or kernel interface do? | The manual pages installed with the system or package |
| How is a supported FreeBSD feature installed or administered? | The official FreeBSD documentation |
| What changed in one release or security patch? | Release notes, errata notices, and security advisories |
| Which operational approach fits a particular constraint? | A focused guide in this handbook, followed by its primary references |
| Is this behavior understood by other administrators? | The FreeBSD Forums or the appropriate mailing list |
| Can a repeatable defect be fixed in FreeBSD? | The FreeBSD bug tracker |
| Does a port or package fail independently of the base system? | The port maintainer and Ports reporting path |
| Is hardware or a commercial product supported? | The manufacturer or vendor |
Moving directly to a broad discussion forum often produces slower answers. First identify the release, component, and exact operation.
Prefer installed manual pages for interfaces #
Manual pages shipped with the running release describe its commands, configuration formats, system calls, and drivers. Search by name or subject:
$ man freebsd-version
$ man 5 rc.conf
$ man 8 service
$ apropos wireless
Section numbers remove ambiguity. For example, section 4 covers device drivers, section 5 covers file formats, and section 8 covers system administration commands. A web search can lead to a manual page from another FreeBSD release, so compare it with the installed copy before relying on an option or default.
Package manual pages and sample files are normally installed beneath /usr/local. Identify the owning package when the boundary is unclear:
$ pkg which /usr/local/sbin/example
$ pkg info -D package-name
Use the FreeBSD manual-page service when the machine is unavailable or when two releases must be compared deliberately.
Use official documentation for supported procedures #
The official FreeBSD documentation is authoritative for installation, administration, architecture, and project procedures. Read its Handbook chapter together with the installed manual pages: the chapter supplies context, while the manual page defines the interface.
This independent handbook is useful when a task needs a smaller decision, an evidence-first diagnostic path, or an integration across several FreeBSD facilities. Its pages link back to primary sources and state the releases to which they apply. Begin with FreeBSD basics when the base-system, package, service, and configuration boundaries are unfamiliar.
Do not treat either handbook as a record of a recent release change. Consult the FreeBSD release information , published errata, and security advisories for that purpose. The supported-release guide explains why the installed patch level and support status matter before troubleshooting.
Choose a community channel by audience #
The FreeBSD support page links the maintained community and project channels. Choose one audience and read its rules before posting:
- The FreeBSD Forums suit searchable, threaded administrator discussions.
- A focused mailing list suits a question whose subject matches that list’s technical audience.
- Developer-oriented channels are appropriate only after the problem has been narrowed to the component they maintain.
Mailing-list messages are publicly archived. Forum posts are also public. Remove passwords, private keys, tokens, internal hostnames, customer data, and unrelated log content. Replace sensitive values consistently rather than deleting the evidence needed to understand the problem.
Avoid sending the same question to several lists or forums at once. If another discussion is already in progress, link to it and explain what remains unresolved.
Prepare an evidence packet #
A useful request permits another person to distinguish configuration, hardware, release, and software defects. Include:
- The expected result and the result actually observed.
- The smallest sequence that reproduces the problem.
- The installed and running FreeBSD versions.
- The relevant architecture, hardware, driver, package version, or jail and virtual-machine boundary.
- Exact command output and error messages as text.
- The configuration lines that affect the behavior.
- Tests already performed and what each test established.
- The first known working and failing versions, when known.
Collect the release boundary explicitly:
$ freebsd-version -kru
$ uname -m
$ pkg -vv
Only include pkg -vv when package repository state is relevant. Large command dumps obscure the failing path. Prefer a short transcript with the command, its complete error, and enough surrounding state to interpret it.
File a bug when the defect is reproducible #
Use the FreeBSD bug tracker for an actionable defect or enhancement in FreeBSD, not as a general support forum. Search for an existing report first. The official problem-report guidance explains component selection, useful evidence, patches, and follow-up.
Separate the owner before filing:
- A base-system command, kernel, driver, or official documentation defect belongs to the corresponding FreeBSD component.
- A port or package defect normally belongs to the Ports component and should identify the port origin, package version, and maintainer.
- An upstream application defect may need to be reported to the upstream project when it is not caused by the FreeBSD port.
- A firmware, cloud-platform, or commercial-support question may require the vendor rather than the FreeBSD project.
A community discussion can help reduce an uncertain symptom to a reportable defect. It is not necessary when the reproduction and affected component are already clear.
Distinguish project reports from site reports #
The Report a bug link on this independent site contacts this handbook’s maintainers. Use it for an error, broken link, complaint, or other concern about this site. It does not file a FreeBSD problem report and does not contact the FreeBSD Project.
When reporting a page error, include the page URL, the disputed statement, the installed FreeBSD release, and a primary source or reproducible result when available.
Use books and older material as background #
Books, conference papers, mailing-list archives, and older Handbook revisions can explain design and history well. Their commands and defaults may no longer describe a supported release. Check every operational claim against a current manual page, release document, or maintained project page.
The official FreeBSD bibliography remains a useful reading list. It is a starting point for deeper study, not evidence that an old procedure is current.