Briefly, FreeBSD is a UNIX® like operating system for AMD64 and Intel® EM64T, i386™ PC-98, IA-64, ARM®, PowerPC® and UltraSPARC® platforms based on U.C. Berkeley's “4.4BSD-Lite” release, with some “4.4BSD-Lite2” enhancements. It is also based indirectly on William Jolitz's port of U.C. Berkeley's “Net/2” to the i386, known as “386BSD”, though very little of the 386BSD code remains. A fuller description of what FreeBSD is and how it can work for you may be found on the FreeBSD home page.

FreeBSD is used by companies, Internet Service Providers, researchers, computer professionals, students and home users all over the world in their work, education and recreation.

For more detailed information on FreeBSD, please see the FreeBSD Handbook.

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

That code in our source tree which falls under the GNU General Public License (GPL) or GNU Library General Public License (LGPL) comes with slightly more strings attached, though at least on the side of enforced access rather than the usual opposite. Due to the additional complexities that can evolve in the commercial use of GPL software, we do, however, endeavor to replace such software with submissions under the more relaxed FreeBSD license whenever possible.

Yes. Those restrictions do not control how you use the code, merely how you treat the FreeBSD Project itself. If you have serious license concerns, read the actual license. For the simply curious, the license can be summarized like this.

• Do not claim that you wrote this.

• Do not sue us if it breaks.

For most people, yes. But this question is not quite that cut-and-dried.

Most people do not actually use an operating system. They use applications. The applications are what really use the operating system. FreeBSD is designed to provide a robust and full-featured environment for applications. It supports a wide variety of web browsers, office suites, email readers, graphics programs, programming environments, network servers, and just about everything else you might want. Most of these applications can be managed through the Ports Collection.

If you need to use an application that is only available on one operating system, you simply cannot replace that operating system. Chances are there is a very similar application on FreeBSD, however. If you want a solid office or Internet server, a reliable workstation, or just the ability to do your job without interruptions, FreeBSD will almost certainly do everything you need. Many computer users across the world, including both novices and experienced UNIX administrators, use FreeBSD as their only desktop operating system.

If you are migrating to FreeBSD from some other UNIX environment, you already know most of what you need to. If your background is in graphic-driven operating systems such as Windows® and older versions of Mac OS®, expect to invest additional time learning the UNIX way of doing things. This FAQ and the FreeBSD Handbook are excellent places to start.

• It may be used free of charge, even by commercial users.

• Full source for the operating system is freely available, and the minimum possible restrictions have been placed upon its use, distribution and incorporation into other work (commercial or non-commercial).

• Anyone who has an improvement or bug fix is free to submit their code and have it added to the source tree (subject to one or two obvious provisions).

• It is worth pointing out that the word “free” is being used in two ways here, one meaning “at no cost”, the other meaning “you can do whatever you like”. Apart from one or two things you cannot do with the FreeBSD code, for example pretending you wrote it, you can really do whatever you like with it.

James Howard wrote a good explanation of the history and differences between the various projects for DaemonNews, called The BSD Family Tree which goes a fair way to answering this question.

At this point in FreeBSD's development, there are two parallel development branches; releases are being made from both branches. The 6.X series of releases is being made from the 6-STABLE branch and the 7.X series of releases from 7-STABLE.

Up until the release of 7.0, the 6.X series was the one known as -STABLE. However, as of 7.0, the 6.X branch will be designated for an “extended support” status and receive only fixes for major problems, such as security-related fixes. There will be more releases made from the 6-STABLE branch, but it is considered a “legacy” branch and most current work will only become a part of 7-STABLE.

Version 8.2 is the latest release from the 7-STABLE branch; it was released in February 2011. Version 7.4 is the latest release from the 6-STABLE branch; it was released in February 2011.

Briefly, -STABLE is aimed at the ISP, corporate user, or any user who wants stability and a minimal number of changes compared to the new (and possibly unstable) features of the latest -CURRENT snapshot. Releases can come from either branch, but -CURRENT should only be used if you are prepared for its increased volatility (relative to -STABLE, that is).

Releases are made every few months. While many people stay more up-to-date with the FreeBSD sources (see the questions on FreeBSD-CURRENT and FreeBSD-STABLE) than that, doing so is more of a commitment, as the sources are a moving target.

More information on FreeBSD releases can be found on the Release Engineering page on the FreeBSD Web site.

FreeBSD-CURRENT is the development version of the operating system, which will in due course become the new FreeBSD-STABLE branch. As such, it is really only of interest to developers working on the system and die-hard hobbyists. See the relevant section in the Handbook for details on running -CURRENT.

If you are not familiar with the operating system or are not capable of identifying the difference between a real problem and a temporary problem, you should not use FreeBSD-CURRENT. This branch sometimes evolves quite quickly and can be un-buildable for a number of days at a time. People that use FreeBSD-CURRENT are expected to be able to analyze any problems and only report them if they are deemed to be mistakes rather than “glitches”. Questions such as “make world produces some error about groups” on the FreeBSD-CURRENT 邮件列表 may be treated with contempt.

Every month, snapshot releases are made based on the current state of the -CURRENT and -STABLE branches. The goals behind each snapshot release are:

• To test the latest version of the installation software.

• To give people who would like to run -CURRENT or -STABLE but who do not have the time or bandwidth to follow it on a day-to-day basis an easy way of bootstrapping it onto their systems.

• To preserve a fixed reference point for the code in question, just in case we break something really badly later. (Although CVS normally prevents anything horrible like this happening.)

• To ensure that all new features and fixes in need of testing have the greatest possible number of potential testers.

No claims are made that any -CURRENT snapshot can be considered “production quality” for any purpose. If you want to run a stable and fully tested system, you will have to stick to full releases, or use the -STABLE snapshots.

Snapshot releases are directly available from snapshot.

Official snapshots are generated each month on a regular basis for all actively developed branches. There are also daily snapshot builds of the popular i386 and amd64 branches, hosted on http://snapshots.us.freebsd.org/.

Back when FreeBSD 2.0.5 was released, FreeBSD development branched in two. One branch was named -STABLE, one -CURRENT. FreeBSD-STABLE is intended for Internet Service Providers and other commercial enterprises for whom sudden shifts or experimental features are quite undesirable. It receives only well-tested bug fixes and other small incremental enhancements. FreeBSD-CURRENT, on the other hand, has been one unbroken line since 2.0 was released, leading towards 8.2-RELEASE and beyond. For more detailed information on branches see “FreeBSD Release Engineering: Creating the Release Branch”, the status of the branches and the upcoming release schedule can be found on the Release Engineering Information page.

The 2.2-STABLE branch was retired with the release of 2.2.8. The 3-STABLE branch has ended with the release of 3.5.1, the final 3.X release. The 4-STABLE branch has ended with the release of 4.11, the final 4.X release. The only changes made to either of these branches will be, for the most part, security-related bug fixes. Support for the 5-STABLE branches has ended with the release of 5.5, the final 5.X release. Support for the 6-STABLE branches will continue for some time but focus primarily on security-related bug fixes and other serious issues.

8.2-STABLE is the actively developed -STABLE branch. The latest release on the 8.2-STABLE branch is 8.2-RELEASE, which was released in February 2011.

The 8-CURRENT branch is the actively developed -CURRENT branch toward the next generation of FreeBSD. See What is FreeBSD-CURRENT? for more information on this branch.

The Release Engineering 团队 <re@FreeBSD.org> releases a new major version of FreeBSD about every 18 months and a new minor version about every 8 months, on average. Release dates are announced well in advance, so that the people working on the system know when their projects need to be finished and tested. A testing period precedes each release, in order to ensure that the addition of new features does not compromise the stability of the release. Many users regard this caution as one of the best things about FreeBSD, even though waiting for all the latest goodies to reach -STABLE can be a little frustrating.

More information on the release engineering process (including a schedule of upcoming releases) can be found on the release engineering pages on the FreeBSD Web site.

For people who need or want a little more excitement, binary snapshots are made daily as discussed above.

The key decisions concerning the FreeBSD project, such as the overall direction of the project and who is allowed to add code to the source tree, are made by a core team of 9 people. There is a much larger team of more than 350 committers who are authorized to make changes directly to the FreeBSD source tree.

However, most non-trivial changes are discussed in advance in the mailing lists, and there are no restrictions on who may take part in the discussion.

Every significant release of FreeBSD is available via anonymous FTP from the FreeBSD FTP site:

• The latest 7-STABLE release, 8.2-RELEASE can be found in the 8.2-RELEASE directory.

• Snapshot releases are made monthly for the -CURRENT and -STABLE branch, these being of service purely to bleeding-edge testers and developers.

• The latest 6-STABLE release, 7.4-RELEASE can be found in the 7.4-RELEASE directory.

Information about obtaining FreeBSD on CD, DVD, and other media can be found in the Handbook.

The Problem Report database of all user change requests may be queried by using our web-based PR query interface.

The send-pr(1) command can be used to submit problem reports and change requests via electronic mail. Alternatively, the web-based problem report submission interface can be used to submit problem reports through a web browser.

Before submitting a problem report, please read Writing FreeBSD Problem Reports, an article on how to write good problem reports.

Please check the Documentation list on the main FreeBSD web site.

FreeBSD 工程产生了内容涉及范围很广的文档， 可以从这个链接上得到：http://www.FreeBSD.org/docs.html。 这些文档也可以以安装包的形式得到， 可以方便的安装到你的 FreeBSD 系统上。 关于文档安装包的更多细节可在随后几段中找到。

此外， 在这本 《问答集》 的结尾部分的 参考资料清单 以及 《使用手册》 中的对应部分 也列出了其他推荐书籍。

有。文档可以以不同的格式和压缩形式得到， 位于 FreeBSD 的 FTP 站点上，在 /pub/FreeBSD/doc/ 目录之中。

文档被以许多不同的方式分类。 这些方式包括：

• 文档名称，例如 faq (问答集)，或 handbook (手册)。

• 文档的语言和编码。 这是按照你可以在 FreeBSD 系统中的 /usr/share/locale 找到的本地化名称。 当前我们已经有的文档的语言和编码如下：

  名称	意义
  en_US.ISO8859-1	美国英文
  bn_BD.ISO10646-1	Bengali (or Bangla)
  da_DK.ISO8859-1	Danish (Denmark)
  de_DE.ISO8859-1	德文
  el_GR.ISO8859-7	Greek (Greece)
  es_ES.ISO8859-1	西班牙文
  fr_FR.ISO8859-1	法文
  hu_HU.ISO8859-2	Hungarian
  it_IT.ISO8859-15	意大利文
  ja_JP.eucJP	日文 (EUC 编码)
  mn_MN.UTF-8	Mongolian (UTF-8 encoding)
  nl_NL.ISO8859-1	Dutch (Netherlands)
  no_NO.ISO8859-1	Norwegian (Norway)
  pl_PL.ISO8859-2	Polish (Poland)
  pt_BR.ISO8859-1	Portuguese (Brazil)
  ru_RU.KOI8-R	俄文 (KOI8-R 编码)
  sr_YU.ISO8859-2	Serbian (Serbia)
  tr_TR.ISO8859-9	Turkish (Turkey)
  zh_CN.GB2312	简体中文 (GB2312 编码)
  zh_TW.Big5	繁体中文 (Big5 编码)

  注意: 有的文档不是可以通过任何语言得到的。

• 文档的格式。我们产生许多不同输出格式的文档。 每种格式都有各自的好处和缺点。 一些格式更适合在线阅读， 其它格式在纸张打印时因为美观而令人满意。 让文档可以以这些格式中的任意一种格式得到 是为了确保我们的读者能阅读他们感兴趣的部分， 既可以在显示器上，也可以打印在纸张上。 现在可得到的格式是：

  格式	意义
  html-split	一些小的有链接的 HTML 文件。
  html	一个大的 HTML 文件，包含整个文档
  pdb	Palm Pilot 数据库格式，使用于 iSilo 阅读器。
  pdf	Adobe 的 可移植文档格式 (Portable Document Format)
  ps	PostScript
  rtf	Microsoft 的 丰富样式文本格式 (Rich Text Format)[a]
  txt	纯文本
  表注: a. 在载入这种格式到 Word 时页码不会被自动更新。 在载入文档后按 CTRL+A, CTRL+END, F9 以更新页码。

• 压缩和包装方式。现在正在使用的有三种。

  1. 格式是 html-split时， 文件用 tar(1) 捆扎。 .tar 文件然后用下述的压缩方式压缩。

  2. 所有的其他格式均只生成一个名为 类型.格式 的文件 (例如 article.pdf、 book.html， 等等)。

     这些文件然后使用两种压缩方式压缩。

     方式	描述
     zip	Zip 格式。 如果你要在 FreeBSD 解压缩这种格式则需要首先安装 port archivers/unzip。
     bz2	BZip2 格式。不如 Zip 使用普遍，但是可以产生更小的文件。 安装 port archivers/bzip2 以解压缩这些文件。

     所以手册的 PostScript 版本， 使用 BZip2 压缩，将会存储为一个文件称为 book.ps.bz2，位于 handbook/ 目录。

在确定您希望下载的格式和压缩形式之后， 您需要自行下载这些压缩文件， 对其进行解压缩， 然后将文档复制到适当的位置。

例如，分页 HTML 版本的《问答集》， 使用 bzip2(1) 压缩，可以在文件 doc/en_US.ISO8859-1/books/faq/book.html-split.tar.bz2 中找到。为了下载和解压缩这个文件你应当这样做：

# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/en_US.ISO8859-1/books/faq/book.html-split.tar.bz2
# bzip2 -d book.html-split.tar.bz2
# tar xvf book.html-split.tar

你会留下一系列 .html 文件。其中主要的一个是 index.html，包含目录、 介绍性的材料，和指向文档其它部分的链接。 然后你可以复制和移动这些到需要的地方。

你可以在 使用手册 的信件列表部分 里找到全部信息。

你可以在 使用手册 的新闻组部分 里找到全部信息。

有，多数重要的 IRC 网络都承载 FreeBSD 聊天频道：

• 频道 #FreeBSD 位于 EFNet 是个 FreeBSD 论坛，但是不要到那里寻求技术支持 或尝试在那里找到朋友帮助你免去阅读联机手册的艰辛， 或是开展你自己的研究。 那是一个聊天频道，最先和首要的问题是， 那里的话题就好像包括性、运动和核武器 就是 FreeBSD 。你已经被警示了！ 可在服务器 irc.chat.org 访问。

• 频道 #FreeBSDhelp 位于 EFNet 致力于帮助 FreeBSD 用户。 对于解决问题他们要比 #FreeBSD 有心的多。

• Channel ##FreeBSD on Freenode is a general help channel with about 300 users at any time. The conversations have been known to run off-topic for a while, but priority is given to users with FreeBSD questions. We are good about helping you understand the basics, referring to the Handbook whenever possible, and directing you where to learn more about the topic you need help with. We are a primarily English speaking channel, though we have users from all over the world. If you would like to speak in your native language, try to ask the question in English and then relocate to another channel ##freebsd-lang as appropriate.

• 频道 #FreeBSD 位于 DALNET 可访问于美国的 irc.dal.net 和欧洲的 irc.eu.dal.net。

• 频道 #FreeBSDHelp 位于 DALNET 可访问于美国的 irc.dal.net 和欧洲的 irc.eu.dal.net。

• 频道 #FreeBSD 位于 UNDERNET 可访问于美国的 us.undernet.org 和欧洲的 eu.undernet.org。 由于那是一个帮助频道，应当准备去阅读向你提及的文档。

• 频道 #FreeBSD 位于 RUSNET 是一个面向俄语的频道， 致力于帮助 FreeBSD 用户。那也是个进行非技术性讨论的好地址。

• Channel #bsdchat on Freenode is a Traditional-Chinese (UTF-8 encoding) language oriented channel dedicated to helping FreeBSD users. This is also good place for non-technical discussions.

这些频道中每个都有特色， 彼此没有联系。它们的聊天风格也不相同， 所以你需要尝试其中的每一个以找到一个风格适应你的。 在所有类型的 IRC 通信中， 如果你很容易就被冒犯，无力应付许多油腔滑调的年轻人 (并且人数比一些较年长的人多)， 千万不要因此而感到烦恼。

DaemonNews 为 FreeBSD 提供商业性的培训和支持。 更多信息可在他们的 BSD 商场 (BSD Mall) 网站上找到。

FreeBSD 商场 (FreeBSD Mall) 提供商业性的 FreeBSD 支持。 你可以在他们的 网站 上得到更多信息。

任何提供培训和支持的其它组织应与 FreeBSD 工程联系以便将组织名称列在这里。

您需要三张软盘的镜像文件： floppies/boot.flp、 floppies/kern1.flp， 以及 floppies/kern2.flp。 您需要使用 fdimage 或 dd(1) 这样的工具把它的内容转存到软盘上。

如果你需要自己下载发行版 (比如，在 DOS 文件系统下安装)，下面是抓取发行版的建议：

• base/

• manpages/

• compat*/

• doc/

• src/ssys.*

这一步骤的完整介绍和更多常见的安装问题都可以在 使用手册的安装章节找到。

一张 3.5 英寸 (1.44 MB) 的软盘可以容纳 1474560 字节的数据， 而引导镜像文件的尺寸正是 1474560 字节。

准备创建引导软盘时常见的错误有：

• 使用 FTP 时没有用 binary 模式下载软盘镜像文件。

  有些 FTP 客户端程序的默认传输模式为 ascii，并且试图 转换接收到的所有行尾字符，以匹配客户端系统的转换模式。这不可避免的破坏了引导镜像文件。检查一下 下载的引导镜像文件：如果它的大小不 完全 等于服务器上文件大小的话，这个 下载过程就是可疑的。

  规避措施：在使用 FTP 连上服务器准备下载镜像文件时，在 FTP 命令提示符号处输入 binary。

• 使用 DOS copy 命令(或者等同的 GUI 工具)往软盘上传送引导镜像文件。

  直接使用类似 copy 这样的命令创建引导镜像文件是不可行的。镜像文件含有一个软 盘的全部内容，磁道对磁道，而不是像普通文件一样放在软盘上。您必须使用 “原始” 方式把文件传输 到软盘上，这需要比较低级的工具，(比如 fdimage 或者 rawrite)这 些工具在 使用手册的安装章节 有说明。

安装说明可以在使用手册的安装章节找到。

使用 FreeBSD 需要 486 或更高配置的 PC、 至少 24 MB 的 RAM 以及 150 MB 的磁盘空间。

FreeBSD 的所有版本都可以运行在低端的单色显示适配器 (MDA) 上， 但是要运行 Xorg，就需要 VGA 或者更好的显卡。

您还可以参考 第 4 章.

目前还没有办法仅仅创建一张安装软盘。你需要制作一个全新的发行版，这里包 含您的安装软盘。

要创建一个自定义的发行版，您可以参考 Release Engineering 中的说明。

请参考 multi-OS 文章.

先安装 Windows ，然后再安装 FreeBSD。FreeBSD 的引导管理器能够引导 Windows 和 FreeBSD。如 果您在 FreeBSD 之后安装 Windows ，Windows 会在自做主张的覆盖您的引导管理器。如果您 遇到这种情况，请参考下一部分的说明。

您可以使用下面三种方法中的一种来重新安装您的 FreeBSD 引导管理器：

• 运行 DOS，切换到 FreeBSD 发行版的 tools 目录下，寻找 bootinst.exe 文件。您可以这样运行这个程序：

  ...\TOOLS> bootinst.exe boot.bin
  

  这样，引导管理器就可以被重新安装上。

• 再次使用 FreeBSD 引导软盘来引导系统， 然后选择 Custom 菜单项进行定制安装。 选择 Partition。 选中您先前安装了启动管理器的驱动器 (通常会是第一个) 然后进入分区表编辑器， 并直接 (也就是不要做任何修改) 按 W。 系统会要求您确认操作， 选择 [ Yes ]， 然后在选择引导管理器 (Boot Manager) 时， 选择 FreeBSD Boot Manager。 这个操作会在磁盘上重写引导管理器。 接着退出安装菜单， 就可以从硬盘引导系统了。

• 引导 FreeBSD 引导软盘(或者 CDROM)并且选择 Fixit 菜单项。选择 Fixit 软盘或 者 CDROM #2 (“live”文件系统选项)进入 fixit shell。然后运行下面的命令：

  Fixit# fdisk -B -b /boot/boot0 引导设备
  

  把 bootdevice 替换成您实际的引导设备，比如 ad0(第一个IDE磁盘)，ad4(辅助控制器上的第一个 IDE 磁盘)，da0(第一个SCSI磁盘)，等等。

在 IBM 较早版本的 BIOS 中有个 bug，导致机器把 FreeBSD 分区错误地看成一个潜在的 FAT suspend-to-disk 分区。当 BIOS 试图解析 FreeBSD 分区时，BIOS 便挂起了。

根据 IBM[1]，下面 型号/BIOS 的版本数字 (release numbers) 含有对这个 bug 的修正。

根据报道，较晚的 IBM BIOS 版本可能又重新引入了这个 bug。 由 Jacques Vidrine 发到 FreeBSD 笔记本电脑邮件列表的 邮件 描述了一个或许可行的方法，如果您的新 IBM 笔记本电 脑不能正常的启动 FreeBSD，您可以升级或者降级您的 BIOS。

如果您使用较早版本的 BIOS，并且升级不可行时，一个规避措施是首先安装 FreeBSD，然后改变 FreeBSD 所使用的分区 ID，再安装新的能处理不同分区 ID 的引导块(boot blocks)。

首先，您需要把机器恢复到能够通过自检屏幕的状态。这一步需要在引导机器时，不让机器在主磁盘搜寻 到 FreeBSD 分区。一种方法是把硬盘摘下然后暂时移至较老版本的 ThinkPad(比如 ThinkPad 600)上或者一台 有合适转换线缆的桌面 PC 上。当您完成这一步时，您可以删除 FreeBSD 分区并且把硬盘移回。此时 ThinkPad 便可以再次引导了。

由于机器能够再次工作了，您可以使用下面描写的规避措施来安装一个可以运行的 FreeBSD。

在同一台笔记本电脑上安装双引导 OpenBSD 和 FreeBSD 这一工作留给读者作为练习。

您可以，但是这不是一个好主意。

如果您在某个现代 IDE 驱动器上发现了坏块，那么这个驱动器将很快报销。(这个驱动器内部重映射 (remapping) 功能已经不再足以修复坏块，这意味着这个磁盘已经被严重破坏了)；我们建议您购买一块新的硬盘。

如果您使用的 SCSI 驱动器有坏块，请参考这个答案。

如果您遇到这样的情况：机器慢慢停机或者当你从安装软盘引导机器时，机器不停地自动重启， 您可以问自己这样的三个问题：

1. 您使用的是一张新的，刚刚格式化的，没有错误的软盘吗？(最好是用一张刚从盒中取出的崭新软盘， 而不是一张在床下压了三年的杂志附赠磁盘)？

2. 您下载软盘镜像的时候使用的是二进制(或者镜像)模式吗？(不要觉得不好意思，即便是我们中间的 高手，也犯过使用 ASCII 模式下载二进制文件的错误！)

3. 如果您在使用 Windows 95 或者 Windows 98， 您是在纯 DOS 模式下使用 fdimage 或 rawrite 这两个工具吗？ 这些操作系统会干扰直接向硬件上写数据的程序， 比如磁盘创建程序； 甚至在 GUI 模式下的 DOS shell 运行这样的程序也会出现这样的问题。

还有报导说，Netscape® 在下载引导软盘时可能会出现错误，因此，如果可能的话，您最好使用一个不同的 FTP 客户端。

这个问题的一般原因是 CDROM 驱动器的配置有错误。很多 PC 现在把 CDROM 设置为第二 IDE 控制器上 的从盘，在这个控制器上没有主盘。根据 ATAPI 的规格，这是不标准的，但是 Windows 不严格的按照 ATAPI 规格进行处理，并且 BIOS 在引导系统的时候也忽略这一点。这就是为什么 BIOS 可以在引导系统时可以检测到 CDROM，但是 FreeBSD 却不能检测到 CDROM 以完成安装程序。

重新配置您的系统以把 CDROM 设置为 IDE 控制器上的主盘，或者，如果您只有一块 IDE 控制器的话， 那就把CDROM设置为从盘，但是此时 IDE 控制器上需要有主盘。

可以。使用标准的 Laplink 线缆。如果有必要，您可以参考 使用手册中的PLIP部分以获取并行端口网络的详细资 料。

注意: 一块磁盘的 “geometry”，是指这块磁盘的柱面(cylinder)数，磁头(head)数和 扇区/磁道(sectors/track)数，为了行文的方便，我们用 C/H/S 来指称一块硬盘的几何布局(geometry)。

这一点对系统管理员新手常常会导致混淆。首先，SCSI 驱动器的物理几何布局 (geometry) 跟 FreeBSD 上的磁盘区块(disk blocks)是完全不相关的。事实上，就磁盘上磁道密度的变化而言， 并没有“所谓 ”physical geometry 这种东西。硬盘制造商所说的 “physical geometry” 通常是指硬盘上使用最小空间来存放数据的几何布局(geometry)。以 IDE 磁盘而言， FreeBSD 用以存取硬盘设定的方式是 C/H/S ，然而，现代硬盘驱动器在内部运作时，早就自动转换为 block 方式 了。

关键在于 logicalgeometry。这是 BIOS 检测硬盘的几何布局 (geometry)时所得到的设定，并且用来决定硬盘存取方式。由于 FreeBSD 在引导时采用 BIOS 检测设定值， 所以如何来让 BIOS 检测到正确的设定值，是十分重要的。尤其是在同一块硬盘上有多个操作系统的情况下， 它们都必须采用一致的硬盘几何布局(geometry)。否则，您就会面严重的系统检测问题！

对 SCSI 硬盘而言， 磁盘的几何布局 (geometry) 取决于您的控制器是否启用了扩展翻译支持 (extended translation support， 通常这个选项会标示为 “支持 >1GB 的 DOS 磁盘” 或类似的概念)。 如果这个选项是关闭的， 则应使用 N 柱面 (cylinders)、 64 磁头 (heads) 和每磁道 32 扇区 (sectors/track)， 此处 N 是以 MB 为单位的磁盘容量。 举例来说， 2GB 的磁盘应该是 2048 柱面、 64 磁头和每磁道 32 扇区。

如果该 SCSI 有支持使用 extended translation 的话， (通常这个方式在MS-DOS®使用上有某些限制)，并且硬盘容量大于 1GB，那么硬盘的几何布局(geometry)就会 使用类似：M cylinders、每磁道 63 sectors(不是 64)、255 heads，这里讲的 M 是指硬盘的容量(单位：MB)再除以 7.844238所得出的数值！所以，在这个例子中，2GB 的硬盘应该是261 cylinders、每磁道63 sectors、255 heads。

如果您对上面所讲的不确定，或者 FreeBSD 在安装时不能正确检测到硬盘几何布局(geometry)的话，最简 单的解决方法通常是在硬盘上建立一块小的 DOS 分区。这样一来，BIOS 就能检测到正确的硬盘几何布局 (geometry)了，如果不想继续保留那一小块 DOS 分区的话，可以随时用 partition editor 来删掉它。或者把 它留着当作网卡驱动程序编程使用，也可以留做您喜欢的用途。

此外， 随 FreeBSD 发行版有一个免费提供的 pfdisk.exe 工具。 您可以在 FreeBSD CDROM 和众多 FreeBSD FTP 站点的 tools 目录中找到它。 这个程序可以从使用磁盘的其他操作系统中读取硬盘的几何布局信息。 您可以在分区表编辑器中输入这些参数。

有，您必须确认您的 root 分区是在 1024 cylinders 之内，以便让 BIOS 可以从中引导内核。(注意： 这是 PC 的 BIOS 功能限制，而不是 FreeBSD 的限制)。

对 SCSI 硬盘而言， 通常这表示将根分区放到硬盘最前面的 1024 MB (如果启用了扩展地址翻译功能， 则是最前面的 4096 MB － 参见前一个问题)。 对于 IDE 硬盘， 则是 504 MB。

FreeBSD 可以识别 Ontrack Disk Manager 并能够为其留出需要的空间。 不过， 它并不支持其他的磁盘管理器。

如果您的整块硬盘上只打算安装 FreeBSD， 就不再需要磁盘管理器了。 只要把磁盘配置为 BIOS 所能处理的最大空间 (通常是 504 兆字节)， FreeBSD 会算出实际可用的空间大小。 如果您使用的是采用 MFM 控制器的旧式磁盘， 则需要告诉 FreeBSD 实际的柱面数 (cylinders)。

如果您希望在磁盘上同时安装 FreeBSD 和其他操作系统， 可能也不需要磁盘管理器： 只需确保 FreeBSD 的引导分区以及其他操作系统的分区都在前 1024 个柱面上就可以了。 如果您足够细心的话， 20 兆字节的引导分区应该够用了。

通常原因出在 FreeBSD 及 DOS 或其它操作系统在硬盘的 geometry 上有冲突。您需要重新安装 FreeBSD，只要遵守上面给出的说明，您基本就可以解决这个问题。

这是上文提到的问题的另外一个症状。这是因为您的 BIOS 几何布局(geometry)和 FreeBSD 的几何布局 (geometry)不一致。如果您的磁盘控制器和 BIOS 支持 cylinder translation (通常被标记为 “支持 >1GB 的驱动器”)，尝试更改相关设定，并重装 FreeBSD。

一般而言 ，不需要。然而，我们强烈建议您的源代码最少要安装 base， 其中包含了本文中提到的一些文件，以及 sys(kernel)，这是 内核的源代码。系统的操作不需要源代码，然而，kernel-configuration 程序 config(8)则需要源代码。 在没有内核源代码情况下，我们仍然可以自己构建源代码结构。你可以通过 NFS 从别的地方用只读方式装 载源代码，然后您依然能够构建新的二进制文件。(由于内核源代码的限制，我们建议您不要直接把源代码装 载到 /usr/src 下，而是装载到其他的地方，然后使用合适的符号链接 把源代码复制到源代码树的顶层架构上。)

拥有在线的源代码并且知道怎么用源代码构建整个系统，会让您更容易地把系统升级到更高级的发行版。

如果需要选择源代码的子集， 在系统安装工具选择 Distributions (软件包) 时， 选择其中的 Custom (定制安装) 菜单项。

在过去， 联编新内核原本是安装 FreeBSD 时非常必要的一步， 不过得益于近来的一些版本采用的更为人性化的内核配置方式， 内核的配置工作可以通过更灵活的 “hints” 来完成， 这些可以在引导加载器的提示符处进行。

联编只包含您用到的驱动程序有时还是有价值的， 因为这可以节省一些 RAM， 但对多数系统而言这已经不再是必需的了。

为了节约一点内存而构建一个仅仅含有您需要的驱动的新内核还是值得的，但是对大部分操作系统而言， 这一点已经不再是必需的。

FreeBSD 上的默认采用的是基于 MD5 的密码格式。 这种格式通常被认为比采用 DES 算法的传统 UNIX 密码格式更安全。 如果您需要与仍在使用不太安全的密码格式的那些旧式操作系统共享口令文件的话， 仍然可以选择使用 DES 密码。 此外， FreeBSD 还允许使用更加安全的 Blowfish 密码格式。 新口令使用何种密码格式是由 /etc/login.conf 中所配置的 passwd_format 登录能力 (login capability) 决定的， 它可以设置为 des、 blf (如果可用) 或 md5 之一。 请参见联机手册 login.conf(5) 以了解关于登录能力的更多信息。

如果您安装了一块 IDE Zip® 或者 Jaz® 驱动器，把它卸载掉，然后重试一遍。引导软盘会被这 些驱动器搞糊涂。在系统安装之后，您可以把这些驱动器重新安装到机器上。希望这一问题可以在之后的发行版 中得到修正。

这一错误信息来自引导块和内核对磁盘设备理解之间的混淆。这一错误信息通常出现在双 IDE 系统 上，这样的系统中硬盘被设置为 IDE 控制器上的主盘或者唯一的设备，而此时 FreeBSD 安装在附属的 IDE 控制器上。引导块认为系统是安装在 ad0 (BIOS 识别出来的第二块硬盘) 上， 而内核则把第一块磁盘指派到附属控制器 ad2 上。 在设备检测之后， 内核试图装载引导块所认为的引导磁盘， ad0， 但是实际上那是 ad2，因此启动过程出现错误。

为了修正这一错误，您可以采用下面方法中一种：

1. 重启系统，然后在 Booting kernel in 10 seconds; hit [Enter] to interrupt 提示符处按 Enter 键。这将进入 boot loader。

   然后输入 set root_disk_unit="disk_number" 。 如果 FreeBSD 安装在第一块 IDE 控制器上的主盘上，disk_number 就是 0 ，如果 FreeBSD 安装在第一块 IDE 控制器的从盘上， disk_number 就是 1 ，如果FreeBSD安装在 第二块IDE控制器的主盘上，disk_number 就是 2， 如果 FreeBSD 安装在第二块 IDE 控制器的从盘上，disk_number 就是 3 。

   然后输入 boot，这样您的系统应该能正确引导了。

   如果想让这些改动成为永久有效的，(这样您就不需要在每次重启或者引导 FreeBSD 系统的时候做 这一工作了)，把 root_disk_unit="disk_number" 这句话写入 /boot/loader.conf.local 文件中。

2. 把 FreeBSD 磁盘移至主 IDE 控制器上，这样几块硬盘的编号就是连续的了。

内存的最高限制与所使用的平台有关。 对于标准的 i386 而言， 这个限制是 4 GB， 不过， 通过 pae(4) 可以支持更多的内存， 请参见 在 i386 上使用 4 GB 或更多内存。

FreeBSD/pc98 的内存上限是 4 GB， 并且不支持 PAE。 其它 FreeBSD 支持的硬件架构理论上支持非常多的内存 (数个 terabytes)。

对 FFS 文件系统而言， 其理论容量限制是 8 TB (2 G 个块)， 或如果使用 8 KB 的块尺寸时， 其容量限制为 16 TB。 实际使用中， 软限制是 1 TB， 但经过修改可以使用 4 TB (并且是实际存在的)。

在 FFS 上的单个文件的最大尺寸是大约 1 G 个块， 换言之对 4 KB 块尺寸的文件系统来说， 这个尺寸限制是 4 TB。

当 FS 的块尺寸是 4 KB 时， 系统能够使用三级间接块， 所有对象受限于三级间接块所能表达的最大 FS 块的数量 (大约是 1024³ + 1024² + 1024), 然而在文件系统块数方面有一个 (错误的) 1 G - 1 限制。 FS 本身的块数限制是 2 G - 1。 当 FS 块数接近 2 G - 1 时会有一些错误， 但这样多的块在 FS 块尺寸为 4 KB 时是不可能达到的。

当文件系统块尺寸为 8 KB 或更大时， 文件系统中的对象尺寸限制应该是 2 G - 1 个块， 但实际上受制于 FS 块数限制 1 G - 1。 使用正确的 2 G - 1 块限制反而会导致错误发生。

因为您的 world 和内核(kernel)不同步， 这是不被支持的做法。 请确保您使用 make buildworld 和 make buildkernel 来升级内核。

您可以在系统引导到第二个阶段， 在引导加载器开始前的 | 符号出现时按下任意键， 另行指定用于引导系统的内核。

尝试禁用 ACPI 支持。 当引导加载器加载内核时， 按 Space 键。 系统会显示：

OK

输入：

unset acpi_load

然后输入：

boot

最有可能的原因是， 内存的物理地址与虚拟地址存在差异。

对于多数 PC 硬件而言， 它们会将位于 3.5 GB 与 4 GB 之间的内存地址空间用于一些特殊的目的 (通常会用于 PCI)。 由于这部分地址空间被 PCI 硬件设备占用， 因而也就无法用于访问实际的物理内存。

这一区域的内存究竟会作何处理取决于您使用的硬件。 不幸的是， 一些硬件什么都不做， 因而最后这 500 MB 的 RAM 也就完全丢失了。

幸运的是， 多数硬件会将这些内存重新映射到更高的位置， 因而它们仍能正常使用。 不过， 如果您观察引导时的提示信息的话， 仍然可能会产生一些误解。

在 32  位版本本的 FreeBSD， 这些内存看起来会丢失， 因为它们会被重新映射到高于 4 GB 的位置， 而这些位置 32 位 的内核是无法访问的。 这种情况下， 您可以考虑联编启用了 PAE 的内核。 请参阅 关于内存限制的问题 以及 不同平台上不同的内存数量限制 以了解进一步的信息。

在 64-位 版本的 FreeBSD， 或启用了 PAE 的内核上， FreeBSD 就能够正确检测并重新映射内存。 不过由于这个重新映射的过程， 在系统引导时， FreeBSD 会显示多于系统实际内存容量的内存， 实际的内存数量会在引导过程结束时修正为正确的值。

With SCSI drives, the drive should be capable of re-mapping these automatically. However, many drives ship with this feature disabled.

To enable bad block remapping edit the first device page mode, which can be done by giving the command (as root)

# camcontrol modepage sd0 -m 1 -e -P 3

and changing the values of AWRE and ARRE from 0 to 1:

AWRE (Auto Write Reallocation Enbld):  1
ARRE (Auto Read Reallocation Enbld):  1

Modern IDE drives also have bad block remapping features in the controller, and they ship with this feature turned on.

If you see warnings about bad blocks (on either type of drive), it is time to consider replacing the drive. You might be able to use the drive manufacturer's diagnostic program to lock out those bad blocks, but at best this will buy you some time.

This is basically a known problem. The EISA on-board SCSI controller in the HP Netserver machines occupies EISA slot number 11, so all the “true” EISA slots are in front of it. Alas, the address space for EISA slots >= 10 collides with the address space assigned to PCI, and FreeBSD's auto-configuration currently cannot handle this situation very well.

So now, the best you can do is to pretend there is no address range clash :), by bumping the kernel option EISA_SLOTS to a value of 12. Configure and compile a kernel, as described in the Handbook entry on configuring the kernel.

Of course, this does present you with a chicken-and-egg problem when installing on such a machine. In order to work around this problem, a special hack is available inside UserConfig. Do not use the “visual” interface, but the plain command-line interface there. Simply type

eisa 12
quit

at the prompt, and install your system as usual. While it is recommended you compile and install a custom kernel anyway.

Hopefully, future versions will have a proper fix for this problem.

This is usually caused by an interrupt conflict (e.g., two boards using the same IRQ). Boot with the -c option and change the ed0/de0/... entry to match your board.

If you are using the BNC connector on your network card, you may also see device timeouts because of bad termination. To check this, attach a terminator directly to the NIC (with no cable) and see if the error messages go away.

Some NE2000 compatible cards will give this error if there is no link on the UTP port or if the cable is disconnected.

This card has a bad habit of losing its configuration information. Refresh your card's settings with the DOS utility 3c5x9.exe.

If the only problem is that the printer is terribly slow, try changing your printer port mode as discussed in the Printer Setup section of the Handbook.

Signal 11 errors are caused when your process has attempted to access memory which the operating system has not granted it access to. If something like this is happening at seemingly random intervals then you need to start investigating things very carefully.

These problems can usually be attributed to either:

1. If the problem is occurring only in a specific application that you are developing yourself it is probably a bug in your code.

2. If it is a problem with part of the base FreeBSD system, it may also be buggy code, but more often than not these problems are found and fixed long before us general FAQ readers get to use these bits of code (that is what -current is for).

In particular, a dead giveaway that this is not a FreeBSD bug is if you see the problem when you are compiling a program, but the activity that the compiler is carrying out changes each time.

For example, suppose you are running make buildworld, and the compile fails while trying to compile ls.c into ls.o. If you then run make buildworld again, and the compile fails in the same place then this is a broken build ── try updating your sources and try again. If the compile fails elsewhere then this is almost certainly hardware.

What you should do:

In the first case you can use a debugger e.g. gdb(1) to find the point in the program which is attempting to access a bogus address and then fix it.

In the second case you need to verify that it is not your hardware at fault.

Common causes of this include:

1. Your hard disks might be overheating: Check the fans in your case are still working, as your disk (and perhaps other hardware might be overheating).

2. The processor running is overheating: This might be because the processor has been overclocked, or the fan on the processor might have died. In either case you need to ensure that you have hardware running at what it is specified to run at, at least while trying to solve this problem. i.e. Clock it back to the default settings.

   If you are overclocking then note that it is far cheaper to have a slow system than a fried system that needs replacing! Also the wider community is not often sympathetic to problems on overclocked systems, whether you believe it is safe or not.

3. Dodgy memory: If you have multiple memory SIMMS/DIMMS installed then pull them all out and try running the machine with each SIMM or DIMM individually and narrow the problem down to either the problematic DIMM/SIMM or perhaps even a combination.

4. Over-optimistic Motherboard settings: In your BIOS settings, and some motherboard jumpers you have options to set various timings, mostly the defaults will be sufficient, but sometimes, setting the wait states on RAM too low, or setting the “RAM Speed: Turbo” option, or similar in the BIOS will cause strange behavior. A possible idea is to set to BIOS defaults, but it might be worth noting down your settings first!

5. Unclean or insufficient power to the motherboard. If you have any unused I/O boards, hard disks, or CDROMs in your system, try temporarily removing them or disconnecting the power cable from them, to see if your power supply can manage a smaller load. Or try another power supply, preferably one with a little more power (for instance, if your current power supply is rated at 250 Watts try one rated at 300 Watts).

You should also read the SIG11 FAQ (listed below) which has excellent explanations of all these problems, albeit from a Linux® viewpoint. It also discusses how memory testing software or hardware can still pass faulty memory.

Finally, if none of this has helped it is possible that you have just found a bug in FreeBSD, and you should follow the instructions to send a problem report.

There is an extensive FAQ on this at the SIG11 problem FAQ

The FreeBSD developers are very interested in these errors, but need some more information than just the error you see. Copy your full crash message. Then consult the FAQ section on kernel panics, build a debugging kernel, and get a backtrace. This might sound difficult, but you do not need any programming skills; you just have to follow the instructions.

This is a known problem with the ATI Mach64 video card. The problem is that this card uses address 2e8, and the fourth serial port does too. Due to a bug (feature?) in the sio(4) driver it will touch this port even if you do not have the fourth serial port, and even if you disable sio3 (the fourth port) which normally uses this address.

Until the bug has been fixed, you can use this workaround:

1. Enter -c at the boot prompt. (This will put the kernel into configuration mode).

2. Disable sio0, sio1, sio2 and sio3 (all of them). This way the sio(4) driver does not get activated ── no problems.

3. Type exit to continue booting.

If you want to be able to use your serial ports, you will have to build a new kernel with the following modification: in /usr/src/sys/dev/sio/sio.c (or in /usr/src/sys/pc98/cbus/sio.c for pc98) find the one occurrence of the string 0x2e8 and remove that string and the preceding comma (keep the trailing comma). Now follow the normal procedure of building a new kernel.

Due to the manner in which FreeBSD gets the memory size from the BIOS, it can only detect 16 bits worth of Kbytes in size (65535 Kbytes = 64 MB) (or less... some BIOSes peg the memory size to 16 MB). If you have more than 64 MB, FreeBSD will attempt to detect it; however, the attempt may fail.

To work around this problem, you need to use the kernel option specified below. There is a way to get complete memory information from the BIOS, but we do not have room in the bootblocks to do it. Someday when lack of room in the bootblocks is fixed, we will use the extended BIOS functions to get the full memory information...but for now we are stuck with the kernel option.

options MAXMEM=n

Where n is your memory in Kilobytes. For a 128 MB machine, you would want to use 131072.

Normally, FreeBSD determines a number of kernel parameters, such as as the maximum number of files that can be open concurrently, from the amount of memory installed in the system. On systems with one gigabyte of RAM or more, this “auto sizing” mechanism may choose values that are too high: while starting up, the kernel allocates various tables and other structures that fill up most of the available kernel memory. Later on, while the system is running, the kernel has no more space left for dynamic memory allocations, and panics.

Compile your own kernel, and add the VM_KMEM_SIZE_MAX to your kernel configuration file, increasing the maximum size to 400 MB (options VM_KMEM_SIZE_MAX=419430400). 400 MB appears to be sufficient for machines with up to 6 GB of memory.

The panic indicates that the system ran out of virtual memory for network buffers (specifically, mbuf clusters). You can increase the amount of VM available for mbuf clusters by following the instructions in the Network Limits section of the Handbook.

The FreeBSD kernel will only allow a certain number of processes to exist at one time. The number is based on the kern.maxusers sysctl(8) variable. kern.maxusers also affects various other in-kernel limits, such as network buffers (see this earlier question). If your machine is heavily loaded, you probably want to increase kern.maxusers. This will increase these other system limits in addition to the maximum number of processes.

To adjust your kern.maxusers value, see the File/Process Limits section of the Handbook. (While that section refers to open files, the same limits apply to processes.)

If your machine is lightly loaded, and you are simply running a very large number of processes, you can adjust this with the kern.maxproc tunable. If this tunable needs adjustion it needs to be defined in in /boot/loader.conf. The tunable will not get adjusted until the system is rebooted. For more information about tuning tunables, you should see the loader.conf(5) and sysctl.conf(5) manual pages. If these processes are being run by a single user, you will also need to adjust kern.maxprocperuid to be one less than your new kern.maxproc value. (It must be at least one less because one system program, init(8), must always be running.)

To make a sysctl change permanent place the proper value in /etc/sysctl.conf. More information about system tuning with sysctl(8) can be found at the Tuning with sysctl section of the Handbook.

The logic that attempts to detect an out of date /var/db/kvm_*.db files sometimes fails and using a mismatched file can sometimes lead to panics.

If this happens, reboot single-user and do:

# rm /var/db/kvm_*.db

This is a conflict with an Ultrastor SCSI Host Adapter.

During the boot process enter the kernel configuration menu and disable uha0, which is causing the problem.

Your motherboard lacks the external logic to support automatic termination. Switch your SCSI BIOS to specify the correct termination for your configuration rather than automatic termination. The ahc(4) driver cannot determine if the external logic for cable detection (and thus auto-termination) is available. The driver simply assumes that this support must exist if the configuration contained in the serial EEPROM is set to “automatic termination”. Without the external cable detection logic the driver will often configure termination incorrectly, which can compromise the reliability of the SCSI bus.

You can find a detailed answer for this question in the Handbook.

The remote machine may be setting your terminal type to something other than the cons25 terminal type required by the FreeBSD console.

There are a number of possible work-arounds for this problem:

• After logging on to the remote machine, set your TERM shell variable to ansi or sco if the remote machine knows about these terminal types.

• Use a VT100 emulator like screen at the FreeBSD console. screen offers you the ability to run multiple concurrent sessions from one terminal, and is a neat program in its own right. Each screen window behaves like a VT100 terminal, so the TERM variable at the remote end should be set to vt100.

• Install the cons25 terminal database entry on the remote machine. The way to do this depends on the operating system on the remote machine. The system administration manuals for the remote system should be able to help you here.

• Fire up an X server at the FreeBSD end and login to the remote machine using an X based terminal emulator such as xterm or rxvt. The TERM variable at the remote host should be set to xterm or vt100.

The reasons for this behavior are explained by the following e-mail, posted to the FreeBSD 一般问题邮件列表 by Peter Wemm <peter@FreeBSD.org>, in answer to a question about an internal modem that was no longer found after an upgrade to FreeBSD 4.X (the comments in [] have been added to clarify the context).

The PNP bios preconfigured it [the modem] and left it laying around in port space, so [in 3.X] the old-style ISA probes “found” it there.

Under 4.0, the ISA code is much more PnP-centric. It was possible [in 3.X] for an ISA probe to find a “stray” device and then for the PNP device ID to match and then fail due to resource conflicts. So, it disables the programmable cards first so this double probing cannot happen. It also means that it needs to know the PnP IDs for supported PnP hardware. Making this more user tweakable is on the TODO list.

To get the device working again requires finding its PnP ID and adding it to the list that the ISA probes use to identify PnP devices. This is obtained using pnpinfo(8) to probe the device, for example this is the output from pnpinfo(8) for an internal modem:

# pnpinfo
Checking for Plug-n-Play devices...

Card assigned CSN #1
Vendor ID PMC2430 (0x3024a341), Serial Number 0xffffffff
PnP Version 1.0, Vendor Version 0
Device Description: Pace 56 Voice Internal Plug & Play Modem

Logical Device ID: PMC2430 0x3024a341 #0
        Device supports I/O Range Check
TAG Start DF
    I/O Range 0x3f8 .. 0x3f8, alignment 0x8, len 0x8
        [16-bit addr]
    IRQ: 4  - only one type (true/edge)

[more TAG lines elided]

TAG End DF
End Tag

Successfully got 31 resources, 1 logical fdevs
-- card select # 0x0001

CSN PMC2430 (0x3024a341), Serial Number 0xffffffff

Logical device #0
IO:  0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8
IRQ 5 0
DMA 4 0
IO range check 0x00 activate 0x01

The information you require is in the Vendor ID line at the start of the output. The hexadecimal number in parentheses (0x3024a341 in this example) is the PnP ID and the string immediately before this (PMC2430) is a unique ASCII ID.

Alternatively, if pnpinfo(8) does not list the card in question, pciconf(8) can be used instead. This is part of the output from pciconf -vl for an onboard sound chip:

# pciconf -vl
chip1@pci0:31:5:        class=0x040100 card=0x00931028 chip=0x24158086 rev=0x02 hdr=0x00
    vendor   = 'Intel Corporation'
    device   = '82801AA 8xx Chipset AC'97 Audio Controller'
    class    = multimedia
    subclass = audio

Here, you would use the chip value, 0x24158086.

This information (Vendor ID or chip value) needs adding to the file /usr/src/sys/dev/sio/sio_isa.c.

You should first make a backup of sio_isa.c just in case things go wrong. You will also need it to make the patch to submit with your PR (you are going to submit a PR, are you not?) then edit sio_isa.c and search for the line:

static struct isa_pnp_id sio_ids[] = {

Then scroll down to find the correct place to add the entry for your device. The entries look like this, and are sorted on the ASCII Vendor ID string which should be included in the comment to the right of the line of code along with all (if it will fit) or part of the Device Description from the output of pnpinfo(8):

{0x0f804f3f, NULL},     /* OZO800f - Zoom 2812 (56k Modem) */
{0x39804f3f, NULL},     /* OZO8039 - Zoom 56k flex */
{0x3024a341, NULL},     /* PMC2430 - Pace 56 Voice Internal Modem */
{0x1000eb49, NULL},     /* ROK0010 - Rockwell ? */
{0x5002734a, NULL},     /* RSS0250 - 5614Jx3(G) Internal Modem */

Add the hexadecimal Vendor ID for your device in the correct place, save the file, rebuild your kernel, and reboot. Your device should now be found as an sio device.

The problem is that the application you are trying to run is looking for a specific kernel symbol, but, for whatever reason, cannot find it; this error stems from one of two problems:

• Your kernel and userland are not synchronized (i.e., you built a new kernel but did not do an installworld, or vice versa), and thus the symbol table is different from what the user application thinks it is. If this is the case, simply complete the upgrade process (see /usr/src/UPDATING for the correct sequence).

• You are not using /boot/loader to load your kernel, but doing it directly from boot2 (see boot(8)). While there is nothing wrong with bypassing /boot/loader, it generally does a better job of making the kernel symbols available to user applications.

The symptom: there is a long delay between the time the TCP connection is established and the time when the client software asks for a password (or, in telnet(1)'s case, when a login prompt appears).

The problem: more likely than not, the delay is caused by the server software trying to resolve the client's IP address into a hostname. Many servers, including the Telnet and SSH servers that come with FreeBSD, do this in order to, among other things, store the hostname in a log file for future reference by the administrator.

The remedy: if the problem occurs whenever you connect from your computer (the client) to any server, the problem is with the client; likewise, if the problem only occurs when someone connects to your computer (the server) the problem is with the server.

If the problem is with the client, the only remedy is to fix the DNS so the server can resolve it. If this is on a local network, consider it a server problem and keep reading; conversely, if this is on the global Internet, you will most likely need to contact your ISP and ask them to fix it for you.

If the problem is with the server, and this is on a local network, you need to configure the server to be able to resolve address-to-hostname queries for your local address range. See the hosts(5) and named(8) manual pages for more information. If this is on the global Internet, the problem may be that your server's resolver is not functioning correctly. To check, try to look up another host ── say, www.yahoo.com. If it does not work, that is your problem.

Following a fresh install of FreeBSD, it is also possible that domain and nameserver information is missing from /etc/resolv.conf. This will often cause a delay in SSH, as the option UseDNS is set to yes by default in the sshd_config file in /etc/ssh. If this is causing the problem, you will either need to fill in the missing information in /etc/resolv.conf or set UseDNS to no in sshd_config as a temporary workaround.

Stray IRQs are indications of hardware IRQ glitches, mostly from hardware that removes its interrupt request in the middle of the interrupt request acknowledge cycle.

One has three options for dealing with this:

• Live with the warnings. All except the first 5 per irq are suppressed anyway.

• Break the warnings by changing the value of MAX_STRAY_LOG from 5 to 0 in your platform's (e.g. i386) intr_machdep.c file and rebuild the new kernel and all the warnings will be suppressed.

• Break the warnings by installing parallel port hardware that uses IRQ 7 and the PPP driver for it (this happens on most systems), and install an ide drive or other hardware that uses IRQ 15 and a suitable driver for it.

This error message indicates you have exhausted the number of available file descriptors on your system. Please see the kern.maxfiles section of the Tuning Kernel Limits section of the Handbook for a discussion and solution.

There is a known problem when enabling Intel Enhanced SpeedStep from the BIOS causes the kernel to start printing “calcru” messages like this:

calcru: runtime went backwards from 6 usec to 3 usec for pid 37 (pagezero)
calcru: runtime went backwards from 6 usec to 3 usec for pid 36 (vmdaemon)
calcru: runtime went backwards from 170 usec to 138 usec for pid 35 (pagedaemon)
calcru: runtime went backwards from 553 usec to 291 usec for pid 15 (swi6: task queue)
calcru: runtime went backwards from 15521 usec to 10366 usec for pid 2 (g_event)
calcru: runtime went backwards from 25 usec to 12 usec for pid 11 (swi1: net)
calcru: runtime went backwards from 4417 usec to 3960 usec for pid 1 (init)
calcru: runtime went backwards from 2084385 usec to 1793542 usec for pid 1 (init)
calcru: runtime went backwards from 408 usec to 204 usec for pid 0 (swapper)

It is because Intel SpeedStep (EIST) is incompatible with some motherboards.

Workaround: Disable the EIST feature in the BIOS. You can still achieve ACPI-based processor frequency throttling by using powerd(8).

Your computer has two or more clocks, and FreeBSD has chosen to use the wrong one.

Run dmesg(8), and check for lines that contain Timecounter. The one with the highest quality value that FreeBSD chose.

# dmesg | grep Timecounter
Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
Timecounter "TSC" frequency 2998570050 Hz quality 800
Timecounters tick every 1.000 msec

You can confirm this by checking the kern.timecounter.hardware sysctl(3).

# sysctl kern.timecounter.hardware
kern.timecounter.hardware: ACPI-fast

It may be a broken ACPI timer. The simplest solution is to disable the ACPI timer in /etc/loader.conf:

debug.acpi.disabled="timer"

Or the BIOS may modify the TSC clock──perhaps to change the speed of the processor when running from batteries, or going into a power saving mode, but FreeBSD is unaware of these adjustments, and appears to gain or lose time.

In this example, the i8254 clock is also available, and can be selected by writing its name to the kern.timecounter.hardware sysctl(3).

# sysctl -w kern.timecounter.hardware=i8254
kern.timecounter.hardware: TSC -> i8254

Your computer should now start keeping more accurate time.

To have this change automatically run at boot time, add the following line to /etc/sysctl.conf:

kern.timecounter.hardware=i8254

This problem is common on laptops that boot more than one operating system. Some non-BSD operating systems leave PC card hardware in an inconsistent state. pccardd(8) will detect the card as “"(null)""(null)"” instead of its actual model.

You must remove all power from the PC card slot to fully reset the hardware. Completely power off the laptop. (Do not suspend it, do not let it go into standby; the power needs to be completely off.) Wait a few moments, and reboot. Your PC card should work now.

Some laptop hardware lies when it claims to be off. If the above does not work shut down, remove the battery, wait a moment, replace the battery, and reboot.

FreeBSD's boot loader is incorrectly recognizing the hard drive's geometry. This must be manually set within fdisk(8) when creating or modifying FreeBSD's slice.

The correct drive geometry values can be found within the machine's BIOS. Look for the number of cylinders, heads and sectors for the particular drive.

Within sysinstall(8)'s fdisk, hit G to set the drive geometry.

A dialog will pop up requesting the number of cylinders, heads and sectors. Type the numbers found from the BIOS separated by forward slashes. For example, values of 5000 cylinders, 250 heads, and 60 sectors would be entered as 5000/250/60.

Press Enter to set the values, and hit W to write the new partition table to the drive.

Enter sysinstall(8) and choose Configure, then Fdisk. Select the disk the Boot Manager resided on with the Space key. Press W to write changes to the drive. A prompt will appear asking which boot loader to install. Select this, and it will be restored.

This means that a process is trying to page memory to disk, and the page attempt has hung trying to access the disk for more than 20 seconds. It might be caused by bad blocks on the disk drive, disk wiring, cables, or any other disk I/O-related hardware. If the drive itself is actually bad, you will also see disk errors in /var/log/messages and in the output of dmesg. Otherwise, check your cables and connections.

The ata(4) driver reports “UDMA ICRC” errors when a DMA transfer to or from a drive is corrupted. The driver will retry the operation a few times. Should the retries fail, it will switch from DMA to the slower PIO mode of communication with the device.

The problem can be caused by many factors, although perhaps the most common cause is faulty or incorrect cabling. Check that the ATA cables are undamaged and rated for the Ultra DMA mode in use. If you are using removable drive trays, they must also be compatible. Be sure that all connections are making good contact. Problems have also been noticed when an old drive is installed on the same ATA channel as an Ultra DMA 66 (or faster) drive. Lastly, these errors can indicate that the drive is failing. Most drive vendors provide testing software for their drives, so test your drive, and, if necessary, back up your data and replace it.

The atacontrol(8) utility can be used to show and select the DMA or PIO modes used for each ATA device. In particular, atacontrol mode channel will show the modes in use on a particular ATA channel, where the primary channel is numbered 0, and so on.

An answer for this question can be found in the FreeBSD Glosssary, see LOR.

This means that a function that may sleep was called while a mutex (or other unsleepable) lock was held.

The reason this is an error is because mutexes are not intended to be held for long periods of time; they are supposed to only be held to maintain short periods of synchronization. This programming contract allows device drivers to use mutexes to synchronize with the rest of the kernel during interrupts. Interrupts (under FreeBSD) may not sleep. Hence it is imperative that no subsystem in the kernel block for an extended period while holding a mutex.

To catch such errors, assertions may be added to the kernel that interact with the witness(4) subsystem to emit a warning or fatal error (depending on the system configuration) when a potentially blocking call is made while holding a mutex.

In summary, such warnings are non-fatal, however with unfortunate timing they could cause undesirable effects ranging from a minor blip in the system's responsiveness to a complete system lockup.

This error does not mean that the touch(1) utility is missing. The error is instead probably due to the dates of the files being set sometime in the future. If your CMOS-clock is set to local time you need to run the command adjkerntz -i to adjust the kernel clock when booting into single user mode.

开放源代码的 OpenOffice.org 办公套件可以直接在 FreeBSD 上运行。 此外， OpenOffice.org 的非开源增值版本， Linux 版本的 StarOffice 也可以在 FreeBSD 上使用。

FreeBSD 的 Ports 套件中还包括了许多文本编辑器、 电子表格软件和绘图程序。

Open Group 发布了 Motif 2.2.2 的源代码。 您可以直接安装预编译的 x11-toolkits/open-motif 软件包， 或从 ports 来进行编译安装。 请参见 《使用手册》 中关于 ports 的部分 以了解如何完成这些工作。

此外， 还有一些可用的商业 Motif 软件包。 这些软件并不是免费的， 但它们的许可证允许将这些软件用于非开源的软件中。 联系 Apps2go 可以得到最便宜的用于 FreeBSD (i386) 的 ELF Motif 2.1.20 软件包。

一共有两种软件包， “开发版” 和 “运行环境版” (价格低很多)。 这些软件包中包括：

• OSF/Motif 管理器、 xmbind、 panner、 wsm。

• 开发包提供了 uil、 mrm、 xm、 xmcxx， 头文件， 以及 Imake 文件。

• 静态和动态 ELF 库。

• 示范性小程序。

订购时请务必说明您需要的是 FreeBSD 版本的 Motif (也不要忘记说明所用的平台架构)！ Versions for NetBSD and OpenBSD are also sold by Apps2go 也出售 NetBSD 和 OpenBSD 的版本。 目前这些都只能通过 FTP 下载。

Xi Graphics 曾经出售用于 FreeBSD 的 CDE， 但现在已经不再销售了。

KDE 是一个与 CDE 十分类似的开放源代码的 X11 桌面系统。 您可能也会喜欢 xfce 的外观和使用体验。 KDE 和 xfce 均可通过 ports 系统 来安装。

有！参见 FreeBSD 网站的 Commercial Vendors 一节。

也可以参见 Ports 集的 Databases 一节。

可以。 下面的网页会告诉您如何在 FreeBSD 上配置 Linux 版本的 Oracle：

• http://www.unixcities.com/oracle/index.html

• http://www.shadowcom.net/freebsd-oracle9i/

请浏览 ports 页 来获取有关移植到 FreeBSD 上的软件包的信息。这个列表目前 包含 20,000 个软件并且正在迅速增长，所以你可以通过经常 查看该页面或者订阅 FreeBSD 公告邮件列表 来获取关于新项目的周期性更新。

大多数 ports 应该能在 6.X、 7.X 和 8.X 开发分支的系统上运行。 每次 FreeBSD 发布一个新版本， ports 树的发布时的一个快照也会包含在 ports/ 目录中。

我们也支持“预编译包”的概念， 其实也就是一个压缩了的二进制发布包，附带有一点小小的智能， 能够完成手动安装所要做的所有工作。 一个预编译包能被轻松地多次安装及卸载而不用了解里面 包含了哪些文件等令人厌烦的的细节。

使用 sysinstall(8) (在 Configure 菜单项中) 的 Packages 预编译包安装菜单， 或以您希望安装的预编译包名字作为参数执行 pkg_add(1) 命令就可以安装预编译包了。 预编译包的扩展名， 通常会是 .tbz， 而发布 CDROM 发行版的人会在他们的光盘上提供一个 packages/All 目录。 用于不同版本的 FreeBSD 的这类文件， 也可以通过网络从下列位置安装：

或者从离你最近的本地镜像站点下载。

请注意， 并不是所有的 ports 都有与之对应的预编译包， 因为我们在不断地增加新的软件。 如果有兴趣， 我们建议您定期到 ftp.FreeBSD.org 主站看看有哪些包可用。

在安装好 news/inn 预编译包或 port 之后， Dave Barr's INN Page 是个很好的起点，在那里你能找到 INN 的 FAQ.

是的。请查看 http://www.FreeBSD.org/java/ 。

如果您运行的 FreeBSD 版本严重落后于 -CURRENT 或 -STABLE， 您可能需要更新 Ports 套件； 请参阅 Porters 手册 中的 保持同步 部分了解更多关于如何完成这样操作的信息。 如果您的系统已经是最新版了， 有可能有人提交了对 port 的变动， 使其能够在 -CURRENT 上运行， 但影响了它在 -STABLE 上的正常工作。 请通过 send-pr(1) 命令报告这一问题， 因为 Ports 套件应该是能够在 -CURRENT 和 -STABLE 分支上同时运行的。

首先，请确认你有一套完整的最新的 Ports 套件。 影响到从最新的 Ports 套件构建 INDEX 文件的问题是很明显的， 所以总是会很快得到解决。

但是，如果你已经更新到了最新版，可能你遇到的是另一个问题。 make index 在处理不完整的 Ports 套件副本时， 存在已知问题。 它假定您本地版本的 ports 均有其所依赖的全部 ports 副本。 具体来说， 如果你在硬盘中有 foo/bar 的一个副本，并且 foo/bar 依赖于 baz/quux， 那么您的硬盘上也必须有 baz/quux 的一个副本， 对于 baz/quux 依赖的 ports 也一样， 等等。 否则， make index 没有足够多的信息来创建它的依赖关系树。

对于使用 cvsup(1) (或 csup(1)) 来更新 Ports 套件， 但又通过 refuse 中指定来不安装某些类别的 FreeBSD 用户来说， 这是个尤其明显的问题。 理论上， 用户应该能够删除某些类别， 但实际上有太多的 ports 基于其它类别的 ports。 在有人对此问题拿出一套解决方案之前， 实际情况就是如果需要构建 INDEX 文件， 就必须有完整的 Ports 套件的副本。

在很少的情况下 INDEX 不能被构建是因为涉及到 make.conf 中设定的 WITH_* 或 WITHOUT_* 变量的奇特的情况。 如果你认为这是问题所在， 请在将其报告至 FreeBSD ports 邮件列表 之前先尝试把这些构建变量关闭再编译 INDEX 文件。

FreeBSD 基本系统是设计为能够自行联编的 ── 换句话说， 只需要使用非常有限的工具就能够联编整个操作系统。 因此， 用于编译 FreeBSD 源代码的联编工具均与源代码捆绑在一起。 这其中包括 C 编译器 (gcc(1))、 make(1)、 awk(1) 以及类似的其他工具。

由于 CVSup 是使用 Modula-3 来书写的， 将其加入 FreeBSD 基本系统需要同时加入并维护 Modula-3 编译器。 这不仅会增加 FreeBSD 源代码消耗的磁盘空间， 也会增加许多额外的维护工作。 因此， 对开发人员和用户来说， 将 CVSup 作为一个单独的 port 提供都会带来很大的便利， 它可以很容易地通过随 FreeBSD 安装 CD 附带的预编译包来安装。

不过， 从 FreeBSD 6.2-RELEASE 开始， FreeBSD 用户没有整合在基本系统中的与 CVSup 兼容的客户端的时代结束了。 感谢 Maxime Henrion <mux@FreeBSD.org> 的工作， CVSup 使用 C 重写成了 csup(1)， 并成为了基本系统的一部分。 虽然它目前还没有完全实现 CVSup 的功能， 它已经足够 (并且非常快！） 用来完成代码的同步工作了。 对于 6.2 之前的系统， 可以通过 port 或 package (参见 net/csup) 来安装它。

FreeBSD 本身并不包含用于升级 port 的工具， 但提供了一些简化升级工作的工具。 您可以安装这些附加的工具来简化 port 的日常维护， 具体细节， 请参见 FreeBSD 使用手册中的 如何升级 Ports 部分。

因为 POSIX® 要求必须有这样一个 shell 。

详细解答： 许多人需要编写能够被移植到各种系统上的 shell 脚本。 这就是为什么 POSIX 详细规范了 shell 以及其他常用工具。 许多脚本是为 Bourne shell 所写， 并且多种重要的编程接口 (make(1), system(3), popen(3), 以及其它类似的高级脚本语言， 比如 Perl 和 Tcl) 都使用 Bourne shell 来解释命令。 因为 Bourne shell 被如此广泛而频繁地使用， 对它来说快速启动， 行为确定， 占用很少的内存是很重要的。

现在的实现是我们尽全力同时满足最多的要求的结果。 为了保持 /bin/sh 尽可能小， 我们没有提供许多其它 shell 所具有的简便功能。 这也是为什么 Ports 套件中包含许多功能强大的像 bash、 scsh、 tcsh 以及 zsh 这样的 shell 的原因。 (您可以自己比较它们的内存占用， 通过在 ps -u 的输出列表中观察 “VSZ” 和 “RSS” 列。)

常见的原因是您系统中的 DNS 配置不正确。 Netscape 和 Opera 在启动时均检查 DNS， 而在它们收到回应或确定网络没有连接之前， 是不会出现在桌面上的。

如果您只更新 Ports 套件中的一部分， 使用的是 CVSup 的某些子集而不是 ports-all CVSup 集合， 就应该 确保 同时更新了 ports-base 子集！ 具体原因在 使用手册 中进行了介绍。

要从 MIDI 文件创建音乐 CD， 首先要从 ports 安装 audio/timidity++， 然后手动安装 Eric A. Welsh 制作的 GUS 补丁包， 这个补丁包可以在 http://alleg.sourceforge.net/digmid.html 找到。 正确安装了 TiMidity++ 之后， 可以用下列命令将 MIDI 文件转换为 WAV 文件：

% timidity -Ow -s 44100 -o /tmp/juke/01.wav 01.mid

随后您可以将 WAV 文件转换成其它格式， 或者刻录到音乐 CD 上， 后者在 FreeBSD 使用手册 中进行了介绍。

一点也不难。查看 使用手册的内核配置章节。

也许你从内核配置文件中删除了 npx0 (参见 npx(4))，而你的计算机却也没有数学协处理器。 设备 npx0 是 必需的， 即使你在的硬件中的确有个设备提供硬件浮点支持， 即使不再是在很老的 386 时代使用的那种单独设备。 你 必须 包括 npx0 设备。 甚至即使你已经建造了一个不带 npx0 支持的内核， 也是无法引导的。

可能是你编译了你的内核为 调试模式。 建造于调试模式的内核包含许多用于调试的符号， 因此内核的大小就大大增加了。注意， 运行一个调试内核不会有什么性能提高， 在系统崩溃时保留一个调试内核就有用了。

然而，如果你的磁盘空间吃紧， 或是你不需要运行一个调试内核， 确保如下两点：

• 不要将这样一行放于你的内核配置文件中：

  makeoptions DEBUG=-g
  

• 运行 config(8) 时不要带 -g 选项。

上述设置中的任何一个都会导致你的内核被建造于调试模式。 一旦你确保了上述两点， 你可以按通常情况建造你的内核了， 你应该可以注意到一个很大的文件大小的减少； 多数内核应该是 1.5 MB 到 2 MB。

当我编译带有多个串行端口代码的内核时， 被告知只有第一个端口被侦测到， 而其余的由于中断冲突被忽略。 我应该如何解决这个问题？

这里的问题是 FreeBSD 有内建的代码防止内核因为硬件或软件冲突而变成垃圾。 解决这个问题的办法是除一个端口之外省去其它端口的 IRQ 设置。 这里是一个例子：

#
# 多端口高速串行线 - 16550 UARTS
#
device sio2 at isa? port 0x2a0 tty irq 5 flags 0x501 vector siointr
device sio3 at isa? port 0x2a8 tty flags 0x501 vector siointr
device sio4 at isa? port 0x2b0 tty flags 0x501 vector siointr
device sio5 at isa? port 0x2b8 tty flags 0x501 vector siointr

这个问题有许多可能的原因。 没有什么特别的顺序，他们是：

• 您没有使用 make buildkernel 和 make installkernel 目标， 而您的源代码树又与目前正在运行的系统不同 (例如， 您在 7.4-RELEASE 上编译 8.2-RELEASE 系统)。 如果您正在尝试升级， 请务必仔细阅读 /usr/src/UPDATING 文件， 特别是其结尾处的 “COMMON ITEMS” (一般事项) 部分。

• 尽管您使用了 make buildkernel 和 make installkernel 目标， 但没有确保 make buildworld 正确完成。 make buildkernel 目标依赖由 make buildworld 目标生成的文件来正确地完成操作。

• 即使你尝试建造 FreeBSD-STABLE， 仍然有可能你抓取代码树是在代码树正在被修改， 或是由于一些原因而坏掉的时候； 只有正式发行版 (RELEASE) 是绝对被保证可以建造的，尽管 FreeBSD-STABLE 在大部分时间建造的更好。 如果你没有成功完成建造， 尝试重新抓取源代码树看看问题是否消失。

检查系统中是否有 kern.sched.quantum sysctl。 如果有， 您应该会看到类似这样的输出：

% sysctl kern.sched.quantum
kern.sched.quantum: 99960

如果存在 kern.sched.quantum sysctl， 那么您正在使用的是 4BSD 调度器 (sched_4bsd(4))。 如果没有， 则 sysctl(8) 会显示一条错误信息 (可以忽略)：

% sysctl kern.sched.quantum
sysctl: unknown oid 'kern.sched.quantum'

此外， 目前正在使用的调度器的名字， 可以直接通过 kern.sched.name sysctl 来获得：

% sysctl kern.sched.name
kern.sched.name: 4BSD

kern.sched.quantum 是进程被抢断之前可以执行的最大时钟跳数 (tick)。 这是 4BSD 调度器专有的， 因此您可以使用它来判断系统正在使用哪个调度器。

请参阅 FreeBSD 使用手册中关于 如何添加磁盘 的说明。

理想的做法是在新磁盘上重新安装 OS， 然后将用户数据挪上去。 如果您长期使用 -STABLE， 或更新到了一个新的版本时， 这也是推荐的方式。 您可以使用 boot0cfg(8) 在新旧两块硬盘上安装 booteasy， 在两个系统之间双启动， 直至对新配置满意为止。 如果您这样做了， 就可以直接跳过下一段， 开始迁移数据了。

有时您可能不希望进行一次完整的全新安装， 此时应使用 sysinstall(8) 或 fdisk(8) 和 disklabel(8) 对新磁盘进行分区和 label。 此外i， 您还应使用 boot0cfg(8) 在两块硬盘上都安装 booteasy， 以便在复制完成后能够选择启动新旧系统。 请参见 介质格式化 介绍文章 以了解这一过程的细节。

现在您的新磁盘已经就绪， 并可以往上搬移数据了。 不过， 您并不能闭着眼睛复制全部数据。 类似设备文件 (在 /dev 中)、 文件系统标记， 以及连接这样的东西， 很可能会使这一过程失败。 您需要使用能够能够支持这些文件的工具， 例如 dump(8) 来进行配置。 除此之外， 尽管一般而言推荐在单用户模式下进行迁移， 但这并不是必需的。

在搬移根文件系统时， 不应使用 dump(8) 和 restore(8) 之外的任何工具。 tar(1) 命令也许能用 ── 但如之前所说的那样， 也可能不能用。 如果从一个分区搬移到另一个空白分区时， 您就应使用 dump(8) 和 restore(8)。 使用 dump 将一个分区上的数据搬移到另一个分区上的操作如下：

举例来说， 如果您准备将根分区挪到 /dev/ad1s1a， 并使用 /mnt 作为临时挂接点， 则命令为：

# newfs /dev/ad1s1a
# mount /dev/ad1s1a /mnt
# cd /mnt
# dump 0af - / | restore xf -

使用 dump 来重新整理分区所需要的操作更多一些。 如果希望将类似 /var 这样的分区与其父目录合并， 需要创建一个能够容纳下两者的分区， 并像前面介绍的那样移动父目录所在的分区， 然后将子目录所在的分区移动到那个分区上：

# newfs /dev/ad1s1a
# mount /dev/ad1s1a /mnt
# cd /mnt
# dump 0af - / | restore xf -
# cd var
# dump 0af - /var | restore xf -

要将一个目录从其父目录分离出来， 例如将 /var 放到一个单独的分区中， 应首先创建分区， 然后将分区挂接到各自的子目录， 接着移动老的单个分区：

# newfs /dev/ad1s1a
# newfs /dev/ad1s1d
# mount /dev/ad1s1a /mnt
# mkdir /mnt/var
# mount /dev/ad1s1d /mnt/var
# cd /mnt
# dump 0af - / | restore xf -

在迁移用户数据时， 您可能更喜欢用 cpio(1)、 pax(1)、 tar(1) 而不是 dump(8)。 目前， 这些工具都可能导致文件标记 (flag) 信息丢失， 因此应小心使用。

在安装过程中， 会提示您从两种不同分区方式之一来对硬盘完成分区的操作。 默认的方式是与其他操作系统兼容的， 其方法是使用 fdisk(8) 分区表 (在 FreeBSD 中称作 “slices”)， 并使用这个 FreeBSD slice。 这时， 您也可以选择安装启动选择器， 以便在启动时选择磁盘上已经安装的操作系统。 另一种方式， 则将整个磁盘交由 FreeBSD 使用， 从而不提供对其他操作系统的兼容性。

那么， 为什么这种方式被叫做 “危险的 (dangerous)” 呢？ 这是因为在这种模式并不包含普通 PC 工具能识别的有效 fdisk(8) 分区表。 随这些工具设计的不同， 在您试图操作这些磁盘时， 它们有可能会产生错误提示， 或者在更糟糕的情况下， 这些工具可能会在不询问和通知您的情况下毁掉 BSD 的引导记录。 此外目前已经知道， “dangerously dedicated” 这种磁盘格式， 会导致许多 BIOS， 包括 AWARD (例如 HP Netserver 和 Micronics 的服务器， 以及许多台式机) 和 Symbios/NCR (见于 53C8xx 系列的 SCSI 控制器) 出现问题。 这并不是完整的列表， 仍有许多其他问题。 这些问题的现象包括 FreeBSD 引导记录提示 “read error” 消息表示无法找到自己， 以及系统在启动时死锁等等。

那么， 为什么要提供这种模式呢？ 它只能节省几 k 字节的磁盘空间， 而且可能会给全新安装的系统带来问题。 “Dangerously dedicated” 模式最初是为了解决阻碍 FreeBSD 安装的一个常见问题 ── BIOS 提供的 “几何尺寸” 参数与磁盘不一致 ── 而设计的。

“Geometry” is an outdated concept, but one still at the heart of the PC's BIOS and its interaction with disks. When the FreeBSD installer creates slices, it has to record the location of these slices on the disk in a fashion that corresponds with the way the BIOS expects to find them. If it gets it wrong, you will not be able to boot.

“Dangerously dedicated” mode tries to work around this by making the problem simpler. In some cases, it gets it right. But it is meant to be used as a last-ditch alternative ── there are better ways to solve the problem 99 times out of 100.

So, how do you avoid the need for “DD” mode when you are installing? Start by making a note of the geometry that your BIOS claims to be using for your disks. You can arrange to have the kernel print this as it boots by specifying -v at the boot: prompt, or using boot -v in the loader. Just before the installer starts, the kernel will print a list of BIOS geometries. Do not panic ── wait for the installer to start and then use scrollback to read the numbers. Typically the BIOS disk units will be in the same order that FreeBSD lists your disks, first IDE, then SCSI.

When you are slicing up your disk, check that the disk geometry displayed in the FDISK screen is correct (ie. it matches the BIOS numbers); if it is wrong, use the G key to fix it. You may have to do this if there is absolutely nothing on the disk, or if the disk has been moved from another system. Note that this is only an issue with the disk that you are going to boot from; FreeBSD will sort itself out just fine with any other disks you may have.

Once you have got the BIOS and FreeBSD agreeing about the geometry of the disk, your problems are almost guaranteed to be over, and with no need for “DD” mode at all. If, however, you are still greeted with the dreaded “read error” message when you try to boot, it is time to cross your fingers and go for it - there is nothing left to lose.

To return a “dangerously dedicated” disk for normal PC use, there are basically two options. The first is, you write enough NULL bytes over the MBR to make any subsequent installation believe this to be a blank disk. You can do this for example with

# dd if=/dev/zero of=/dev/rda0 count=15

Alternatively, the undocumented DOS “feature”

C:\> fdisk /mbr

will to install a new master boot record as well, thus clobbering the BSD bootstrap.

Short answer: you can usually use Soft Updates safely on all partitions.

Long answer: There used to be some concern over using Soft Updates on the root partition. Soft Updates has two characteristics that caused this. First, a Soft Updates partition has a small chance of losing data during a system crash. (The partition will not be corrupted; the data will simply be lost.) Also, Soft Updates can cause temporary space shortages.

When using Soft Updates, the kernel can take up to thirty seconds to actually write changes to the physical disk. If you delete a large file, the file still resides on disk until the kernel actually performs the deletion. This can cause a very simple race condition. Suppose you delete one large file and immediately create another large file. The first large file is not yet actually removed from the physical disk, so the disk might not have enough room for the second large file. You get an error that the partition does not have enough space, although you know perfectly well that you just released a large chunk of space! When you try again mere seconds later, the file creation works as you expect. This has left more than one user scratching his head and doubting his sanity, the FreeBSD filesystem, or both.

If a system should crash after the kernel accepts a chunk of data for writing to disk, but before that data is actually written out, data could be lost or corrupted. This risk is extremely small, but generally manageable. Use of IDE write caching greatly increases this risk; it is strongly recommended that you disable IDE write caching when using Soft Updates.

These issues affect all partitions using Soft Updates. So, what does this mean for the root partition?

Vital information on the root partition changes very rarely. Files such as /boot/kernel/kernel and the contents of /etc only change during system maintenance, or when users change their passwords. If the system crashed during the thirty-second window after such a change is made, it is possible that data could be lost. This risk is negligible for most applications, but you should be aware that it exists. If your system cannot tolerate this much risk, do not use Soft Updates on the root filesystem!

/ is traditionally one of the smallest partitions. If you put the /tmp directory on / and you have a busy /tmp, you might see intermittent space problems. Symlinking /tmp to /var/tmp will solve this problem.

The symptom of this is:

# ccdconfig -C
ccdconfig: ioctl (CCDIOCSET): /dev/ccd0c: Inappropriate file type or format

This usually happens when you are trying to concatenate the c partitions, which default to type unused. The ccd(4) driver requires the underlying partition type to be FS_BSDFFS. Edit the disklabel of the disks you are trying to concatenate and change the types of partitions to 4.2BSD.

The symptom of this is:

# disklabel ccd0
(it prints something sensible here, so let us try to edit it)
# disklabel -e ccd0
(edit, save, quit)
disklabel: ioctl DIOCWDINFO: No disk label on disk;
use "disklabel -r" to install initial label

This is because the disklabel returned by ccd(4) is actually a “fake” one that is not really on the disk. You can solve this problem by writing it back explicitly, as in:

# disklabel ccd0 > /tmp/disklabel.tmp
# disklabel -Rr ccd0 /tmp/disklabel.tmp
# disklabel -e ccd0
(this will work now)

FreeBSD supports a variety of other filesystems.

FreeBSD also supports network filesystems such as NFS (see mount_nfs(8)), NetWare (see mount_nwfs(8)), and Microsoft-style SMB filesystems (see mount_smbfs(8)). You can find ports based on FUSE (sysutils/fusefs-kmod) for many other filesystems.

The secondary DOS partitions are found after all the primary partitions. For example, if you have an “E” partition as the second DOS partition on the second SCSI drive, there will be a device file for “slice 5” in /dev, so simply mount it:

# mount -t msdos /dev/da1s5 /dos/e

Yes. You can use either gbde(8) or geli(8), see the Encrypting Disk Partitions section of the FreeBSD Handbook.

The general idea is that you copy the first sector of your native root FreeBSD partition into a file in the DOS/Windows NT partition. Assuming you name that file something like c:\bootsect.bsd (inspired by c:\bootsect.dos), you can then edit the c:\boot.ini file to come up with something like this:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows NT"
C:\BOOTSECT.BSD="FreeBSD"
C:\="DOS"

If FreeBSD is installed on the same disk as the Windows NT boot partition simply copy /boot/boot1 to C:\BOOTSECT.BSD. However, if FreeBSD is installed on a different disk /boot/boot1 will not work, /boot/boot0 is needed.

/boot/boot0 needs to be installed using sysinstall(8) by selecting the FreeBSD boot manager on the screen which asks if you wish to use a boot manager. This is because /boot/boot0 has the partition table area filled with NULL characters but sysinstall(8) copies the partition table before copying /boot/boot0 to the MBR.

When the FreeBSD boot manager runs it records the last OS booted by setting the active flag on the partition table entry for that OS and then writes the whole 512-bytes of itself back to the MBR so if you just copy /boot/boot0 to C:\BOOTSECT.BSD then it writes an empty partition table, with the active flag set on one entry, to the MBR.

If you have FreeBSD and Linux on the same disk, just follow LILO's installation instructions for booting a non-Linux operating system. Very briefly, these are:

Boot Linux, and add the following lines to /etc/lilo.conf:

other=/dev/hda2
        table=/dev/hda
        label=FreeBSD

(the above assumes that your FreeBSD slice is known to Linux as /dev/hda2; tailor to suit your setup). Then, run lilo as root and you should be done.

If FreeBSD resides on another disk, you need to add loader=/boot/chain.b to the LILO entry. For example:

other=/dev/dab4
        table=/dev/dab
        loader=/boot/chain.b
        label=FreeBSD

In some cases you may need to specify the BIOS drive number to the FreeBSD boot loader to successfully boot off the second disk. For example, if your FreeBSD SCSI disk is probed by BIOS as BIOS disk 1, at the FreeBSD boot loader prompt you need to specify:

Boot: 1:da(0,a)/boot/kernel/kernel

You can configure boot(8) to automatically do this for you at boot time.

The Linux+FreeBSD mini-HOWTO is a good reference for FreeBSD and Linux interoperability issues.

Booting FreeBSD using GRUB is very simple. Just add the following to your configuration file /boot/grub/menu.lst (or /boot/grub/grub.conf in some systems, e.g. Red Hat Linux and its derivatives).

title FreeBSD 6.1
    root (hd0,a)
    kernel /boot/loader
     

Where hd0,a points to your root partition on the first disk. If you need to specify which slice number should be used, use something like this (hd0,2,a). By default, if the slice number is omitted, GRUB searches the first slice which has a partition.

Install LILO at the start of your Linux boot partition instead of in the Master Boot Record. You can then boot LILO from BootEasy.

If you are running Windows and Linux this is recommended anyway, to make it simpler to get Linux booting again if you should need to reinstall Windows (which is a Jealous Operating System, and will bear no other Operating Systems in the Master Boot Record).

You can not do that with the standard boot manager without rewriting it. There are a number of other boot managers in the sysutils ports category that provide this functionality.

Whether it is a removable drive like a Zip or an EZ drive (or even a floppy, if you want to use it that way), or a new hard disk, once it is installed and recognized by the system, and you have your cartridge/floppy/whatever slotted in, things are pretty much the same for all devices.

(this section is based on Mark Mayo's ZIP FAQ)

If it is a ZIP drive or a floppy, you have already got a DOS filesystem on it, you can use a command like this:

# mount -t msdos /dev/fd0c /floppy

if it is a floppy, or this:

# mount -t msdos /dev/da2s4 /zip

for a ZIP disk with the factory configuration.

For other disks, see how they are laid out using fdisk(8) or sysinstall(8).

The rest of the examples will be for a ZIP drive on da2, the third SCSI disk.

Unless it is a floppy, or a removable you plan on sharing with other people, it is probably a better idea to stick a BSD filesystem on it. You will get long filename support, at least a 2X improvement in performance, and a lot more stability. First, you need to redo the DOS-level partitions/filesystems. You can either use fdisk(8) or sysinstall(8), or for a small drive that you do not want to bother with multiple operating system support on, just blow away the whole FAT partition table (slices) and just use the BSD partitioning:

# dd if=/dev/zero of=/dev/rda2 count=2
# disklabel -Brw da2 auto

You can use disklabel(8) or sysinstall(8) to create multiple BSD partitions. You will certainly want to do this if you are adding swap space on a fixed disk, but it is probably irrelevant on a removable drive like a ZIP.

Finally, create a new filesystem, this one is on our ZIP drive using the whole disk:

# newfs /dev/rda2c

and mount it:

# mount /dev/da2c /zip

and it is probably a good idea to add a line like this to /etc/fstab (see fstab(5)) so you can just type mount /zip in the future:

/dev/da2c /zip ffs rw,noauto 0 0

You have to tell mount(8) the type of the device that you want to mount. This is described in the Handbook section on optical media, specifically the section Using Data CDs.

This generally means that there is no CDROM in the CDROM drive, or the drive is not visible on the bus. Please see the Using Data CDs section of the Handbook for a detailed discussion of this issue.

Your CDROM probably uses the “Joliet” extension for storing information about files and directories. This is discussed in the Handbook chapter on creating and using CDROMs, specifically the section on Using Data CDROMs.

You most likely burned a raw file to your CD, rather than creating an ISO 9660 filesystem. Take a look at the Handbook chapter on creating CDROMs, particularly the section on burning raw data CDs.

This is discussed in the Handbook section on duplicating data CDs. For more on working with CDROMs, see the Creating CDs Section in the Storage chapter in the Handbook.

If you try to mount an audio CD, you will get an error like “cd9660: /dev/acd0c: Invalid argument”. This is because mount only works on filesystems. Audio CDs do not have filesystems; they just have data. You need a program that reads audio CDs, such as the audio/xmcd port.

By default, mount(8) will attempt to mount the last data track (session) of a CD. If you would like to load an earlier session, you must use the -s command line argument. Please see mount_cd9660(8) for specific examples.

Ordinary users can be permitted to mount devices. Here is how:

All users can now mount the floppy /dev/fd0 onto a directory that they own:

% mkdir ~/my-mount-point
% mount -t msdos /dev/fd0 ~/my-mount-point

Users in group operator can now mount the CDROM /dev/acd0c onto a directory that they own:

% mkdir ~/my-mount-point
% mount -t cd9660 /dev/acd0c ~/my-mount-point

Unmounting the device is simple:

% umount ~/my-mount-point

Enabling vfs.usermount, however, has negative security implications. A better way to access MS-DOS formatted media is to use the emulators/mtools package in the Ports Collection.

You need to understand what du and df really do. du goes through the directory tree, measures how large each file is, and presents the totals. df just asks the filesystem how much space it has left. They seem to be the same thing, but a file without a directory entry will affect df but not du.

When a program is using a file, and you delete the file, the file is not really removed from the filesystem until the program stops using it. The file is immediately deleted from the directory listing, however. You can see this easily enough with a program such as more. Assume you have a file large enough that its presence affects the output of du and df. (Since disks can be so large today, this might be a very large file!) If you delete this file while using more on it, more does not immediately choke and complain that it cannot view the file. The entry is simply removed from the directory so no other program or user can access it. du shows that it is gone ── it has walked the directory tree and the file is not listed. df shows that it is still there, as the filesystem knows that more is still using that space. Once you end the more session, du and df will agree.

Note that Soft Updates can delay the freeing of disk space; you might need to wait up to 30 seconds for the change to be visible!

This situation is common on web servers. Many people set up a FreeBSD web server and forget to rotate the log files. The access log fills up /var. The new administrator deletes the file, but the system still complains that the partition is full. Stopping and restarting the web server program would free the file, allowing the system to release the disk space. To prevent this from happening, set up newsyslog(8).

In the Configuration and Tuning section of the Handbook, you will find a section describing how to do this.

Disk manufacturers calculate gigabytes as a billion bytes each, whereas FreeBSD calculates them as 1,073,741,824 bytes each. This explains why, for example, FreeBSD's boot messages will report a disk that supposedly has 80 GB as holding 76,319 MB.

Also note that FreeBSD will (by default) reserve 8% of the disk space.

A portion of each UFS partition (8%, by default) is reserved for use by the operating system and the root user. df(1) does not count that space when calculating the Capacity column, so it can exceed 100%. Also, you will notice that the Blocks column is always greater than the sum of the Used and Avail columns, usually by a factor of 8%.

For more details, look up the -m option in tunefs(8).

最主要的设置文件是 /etc/defaults/rc.conf (见 rc.conf(5)) 系统启动的脚本文件 /etc/rc 和 /etc/rc.d (见 rc(8)) 只是包含这个文件。不要编辑 它! 然而， 如果在 /etc/defaults/rc.conf 里面有一个配制选项你要修改， 你应该把那一行复制到 /etc/rc.conf 里面，并且 在那里修改。

例如，如果你想开机启动内建的域名服务器 named(8)， 你要做的就像下面那样：

# echo named_enable="YES" >> /etc/rc.conf

要启动一个本地服务，把 shell 脚本放在 /usr/local/etc/rc.d 目录里面。这些 shell 脚本应该被设置成可执行的， 默认的文件模式是 555。

使用 adduser(8) 命令，或者 pw(8) 命令,如果你需要更复杂的解法 .

要删除一个用户，使用命令 rmuser(8) 或者, 如果必须, 使用命令 pw(8).

这通常是由于编辑系统 crontab 文件 (/etc/crontab) 然后使用 crontab(1) 安装它造成的：

# crontab /etc/crontab

这不是作这件事的正确方法。 系统 crontab 文件拥有与每用户 crontabs 不同的格式 而 crontab(1) 只更新每用户 crontabs ( crontab(5) 手册 详细解释了二者的不同).

如果你这么作了，现在的 crontab 只是 /etc/crontab 的一个格式错误的拷贝 。 用下面的命令删除它：

# crontab -r

下次，当你编辑 /etc/crontab 时，你除了通知 cron(8) 这些改变外不用作其他事情，既然 它自己会自动的通知他们 .

如果你希望什么事每天每周或者 每月运行，可能更好的选择是增加脚本 /usr/local/etc/periodic, 然后让 periodic(8) 命令从 系统 cron 调度器 那里象其他的系统任务 那样进行调度 .

导致这个错误的实际原因是系统的 crontab 中有一个额外的字段用于指定执行命令的用户。 在随 FreeBSD 提供的默认系统 crontab 中， 所有条目中这个字段均为 root。 因而， 当这个 crontab 作为 root 用户的个人 crontab 使用时 (它与系统 crontab 不同)， cron(8) 假定字符串 root 是所希望执行命令的第一个单词， 然而系统并没有提供这个命令。

这是一项安全特性。 想要 su 成 root (或其他任何有超级用户权限的用户)， 就必须是 wheel 组的成员。 如果没有这个特性， 那么任何拥有系统用户帐号， 并且知道 root 的口令的用户， 便可以获得系统的超级用户权限。 有了这个特性， 这种操作就不会成功了； su(1) 会阻止没有在 wheel 组中的用户， 哪怕只是试试口令。

要允许用户 su 成 root， 将其加入 wheel 组就可以了。

在引导加载器提示符处输入 boot -s 进入单用户模式。 当系统提示输入 shell 路径名时， 按下 Enter， 接着执行 mount -urw / 来以读写模式重新挂接根文件系统。 如果需要使用其他编辑器， 您可能还需要使用 mount -a -t ufs 来挂接其他文件系统。 如果您习惯使用的编辑器在网络文件系统上， 您就需要手工配置网络， 或使用本地文件系统中的编辑器， 如 ed(1).

如果您希望使用类似 vi(1) 或 emacs(1) 这样的全屏幕编辑器， 可能还需要执行 export TERM=cons25 以便让这些编辑器从 termcap(5) 数据库中加载正确的终端信息数据。

一旦完成了上述步骤， 就可以像平时那样编辑 /etc/rc.conf 并修正其中的语法错误了。 在内核启动信息之后紧接着显示的错误信息应该能够告诉您发生错误的文件和行号。

请参阅 使用手册中关于打印的部分。 这能够解决您大部分的问题。

某些打印机需要主机驱动才能够打印。 这种 “WinPrinters” 打印机无法被 FreeBSD 直接支持。 如果您的打印机在 DOS 或 Windows 下不能正常工作， 它很可能是个 WinPrinter。 您让这种打印机工作唯一的希望是看看 print/pnm2ppa port 是否支持它。

请看手册中关于 using localization 的章节，特别是关于 console setup 的章节 .

下面的内容摘自 FreeBSD-CURRENT 邮件列表 邮件列表中的一封邮件。

• 您的内核可能没有配置使用配额功能。 如果是这种情况， 则需要将下述选项加入内核配置， 并重新编译和安装内核：

  options QUOTA
  

  请参阅 使用手册中关于配额的章节 以了解更具体的细节。

• 不要在 / 上启用配额。

• 把配额文件放到那些被强制实行配额的文件系统上 ，象：

  Filesystem	Quota file
  /usr	/usr/admin/quotas
  /home	/home/admin/quotas
  ...	...

是的，在 GENERIC 内核中 FreeBSD 支持 System V-style IPC, 包括 shared memory (共享内存), messages (消息) and semaphores (信号). 在一个自定义内核中, 向内核配置文件中添加下面这些行来提供 相应的支持 .

options    SYSVSHM   # enable shared memory
options    SYSVSEM    # enable for semaphores
options    SYSVMSG    # enable for messaging

重新编译并安装你的内核 .

sendmail 是 FreeBSD 默认的邮件服务器软件， 但您可以很容易地使用其它 MTA (例如， 通过 ports 安装的 MTA) 来替换它。

在 ports 套件中已经提供了多种不同的 MTA 供您选择， 其中 mail/exim、 mail/postfix、 mail/qmail， 以及 mail/zmailer 是最流行的选择。

更多选择， 更多欢笑。 多样化的邮件服务器选择是一件好事； 因此， 您应避免在邮件列表中提出类似 “sendmail 是否比 qmail 更好？” 这样的问题。 如果实在想要问， 请首先查阅一下邮件列表的历史存档。 每一种 MTA 的优缺点都已经被讨论过了。

别慌！ 重启系统， 在 Boot: 提示符处输入 boot -s 进入单用户模式。 在系统询问使用哪个 shell 时， 按下 Enter。 这样您就会进入 # 提示符。 输入 mount -urw / 将根文件系统以可读写模式重新挂接， 接着， 执行 mount -a 来挂接其他文件系统。 运行 passwd root 即可修改 root 的密码， 然后输入 exit(1) 来继续引导过程。

如果您使用的是 syscons(4) (默认的控制台驱动)， 用包含下面这行的配置文件重新联编并安装内核：

options SC_DISABLE_REBOOT

如果不希望重启系统， 也可以通过设置 sysctl(8) 来修改相关配置：

# sysctl hw.syscons.kbd_reboot=0

如果您使用的是 pcvt(4) 控制台驱动， 则应使用下面的内核配置行， 并同样需要重新联编和安装内核：

options PCVT_CTRL_ALT_DEL

用下面的 perl(1) 命令：

% perl -i.bak -npe 's/\r\n/\n/g' file(s)

其中 file(s) 是需要处理的一个或若干个文件。 全部修改是在原文件上进行的， 而原始的文件将增加一个 .bak 保存为备份。

可选择的,你可以使用命令 tr(1) ：

% tr -d '\r' < dos-text-file > unix-file

dos-text-file 是包含 DOS 文本的文件， 而 unix-file 则是转换输出文件。 这会比使用 perl 快得多。

除此之外， 还有一个对 DOS 文本文件格式进行重整的方法是使用 Ports 套件中的 converters/dosunix port。 具体用法请参阅其文档。

使用 killall(1).

这个错误来自于 Kerberos 分布式认证系统。 问题虽不致命但是很烦人。 您可以用带 -K 参数的 su， 或按照下一个问题中描述的那样卸载 Kerberos。

想要从系统中删除 Kerberos， 需要重新安装您运行的发行版本中的 base 软件包。 如果您使用 CDROM， 可以将其挂载 (我们假定是在 /cdrom) 并执行：

# cd /cdrom/base
# ./install.sh

另外， 也可以通过在 /etc/make.conf 中配置 NO_KERBEROS 选项， 并重新联编 world 来达到目的。

FreeBSD 5.X 和更高版本采用了按需生成设备的 devfs(8)。 设备驱动程序会在需要时自动创建新的设备节点， 这使得 /dev/MAKEDEV 过时了。

如果您的 telnet、 ssh、 X 或 screen 用户很多， 可能会用完虚拟终端。 下面是如何增加更多的虚拟终端：

进入单用户系统,然后回到多用户模式.

在控制台下:

# shutdown now
(Note: without -r or -h)

# return
# exit

简短的回答： 这些只是名字。 RC 的意思是 “Release Candidate” (候选发行版本)， 表示新的发行版本即将产生。 在 FreeBSD 中， -PRERELEASE 通常是正式发布新的发行版之前代码冻结的同义词。 (对某些发行版而言， -BETA 标签与 -PRERELEASE 的含义相同。)

具体的回答： FreeBSD 的发行版本是从两个地方中的一个派生出来的。 主要的、 次版本号为零的版本， 例如 6.0-RELEASE 和 7.0-RELEASE， 是从通常称作 -CURRENT 的开发分支的最新版本中切分出来的。 其后的次要发行版， 例如 6.3-RELEASE 或 5.2-RELEASE， 则是其对应的活跃 -STABLE 分支上的快照。 从 4.3-RELEASE 开始， 每个发行版本也拥有了其对应的分支， 以便供需要非常保守的开发节奏的人们更新使用 (通常这些分支中只提供安全更新)。

在准备发布新的发行版时， 派生出这一发行版的分支需要进行一系列开发过程。 这一过程中的一个重要部分便是代码冻结。 一旦代码冻结开始， 便会将分支的名称改为反映其将成为新的发行版的名字。 例如， 如果某个分支过去的名字叫 6.2-STABLE， 那么在进行代码冻结的时候， 便会将其更名为 6.3-PRERELEASE， 表示正在进行发行版发布之前的测试。 这个过程中， 对问题的修正仍能提交并成为最终发行版本的一部分。 当源代码已经基本成形时， 对应的名字就是 6.3-RC 这样的形式， 表示正式的发行版即将从这个分支发布。 一旦进入 RC 阶段， 就只有新发现的最严重的 bug 才会被修正了。 一旦发行版本 (这个例子中是 6.3-RELEASE) 和发行版分支均完成之后， 前述分支便会更名为 6.3-STABLE。

如欲了解关于版本号， 以及 CVS 分支的细节， 请参见 发布工程。

简短的回答： 您的安全级别可能设置成了大于 0 的数字。 重启并进入单用户模式就可以安装内核了。

冗长的回答： FreeBSD 在安全级别高于0是不容许更改系统标志( system flags ) 。 你可以使用用下面的命令检查你的安全级别：

# sysctl kern.securelevel

安全级别是不能降低的； 您必须重新启动进入单用户模式， 或修改 /etc/rc.conf 中的设置并重启系统才能安装内核。 请参阅联机手册 init(8) 中 securelevel 更进一步的介绍、 /etc/defaults/rc.conf 以及联机手册 rc.conf(5) 以了解关于配置 rc.conf 更进一步的信息。

简短的回答： 您的安全级别可能设置成了大于 0 的数字。 重启并进入单用户模式就可以修改系统日期了。

冗长的回答： FreeBSD 在安全级别高于0是不容许更改系统时间的 。 你可以使用用下面的命令检查你的安全级别：

# sysctl kern.securelevel

安全级别是不能降低的； 您必须重新启动进入单用户模式， 或修改 /etc/rc.conf 中的设置并重启系统才能安装内核。 请参阅联机手册 init(8) 中 securelevel 更进一步的介绍、 /etc/defaults/rc.conf 以及联机手册 rc.conf(5) 以了解关于配置 rc.conf 更进一步的信息。

不， 这不是内存泄露， 并且它也没有真的用到 256 MB 内存。 为了方便， rpc.statd 会将可怕的数量的内存映射到其地址空间。 从技术角度说， 这样作并没什么错； 它只是影响了类似 top(1) 和 ps(1) 这样程序的显示输出。

rpc.statd(8) 会将其状态文件 (位于 /var) 映射到其地址空间； 为了避免在需求增长时重新进行映射， 它会使用一个较大的尺寸。 您可以从源代码中发现这一点， 传给 mmap(2) 的长度参数是 0x10000000， 也就是 IA32 地址空间的十六分之一， 或 256 MB。

当你运行在较高的安全级别(也就是高于0) 。 降低安全级别试试。 要得到更多的 信息，查看 the FAQ entry on securelevel 和 init(8) 手册 .

在较新版本的 FreeBSD 中默认 .shosts 不再能够使用的原因是 ssh(1) 不再以 suid root 来安装了。 如果希望 “修正” 这个问题， 您需要做下列几种操作之一：

• 永久性修正， 方法是在 /etc/make.conf 中将 ENABLE_SUID_SSH 设为 true 并重新联编和安装 ssh(1) (也可以执行 make world)。

• 临时性修正， 方法是以 root 执行 chmod 4555 /usr/bin/ssh 来将 /usr/bin/ssh 的属性模式改为 4555。 接下来， 您还应在 /etc/make.conf 中加入 ENABLE_SUID_SSH= true 以便让下次执行 make world 时自动完成这些操作。

vnlru 释放 vnodes 当 系统达到 kern.maxvnodes 限制的时候。 内核线程通常是空闲的,只有 只有当你有很大的内存并且访问了数以万计的小文件时才被激活.

• Active: 最近使用的页面.

• Inactive: 最近没有使用的页面.

• Cache: (大部分通常) 从inactive 到自己要求更改他们自己的数据, 然而经常立刻 就被重用 (或者是他们的就的关联, 或者使用一个新的关联 .) 如果页面被清理(未更改), 可能立刻从 active 改变到 cache 状态 ,若非更改大概只是一种策略,依赖于VM系统维护人员的算法选择.

• Free: 没有数据内容的页面 , 在cache页面不合格的情况下可以被立即使用. Free 页面在中断或进程状态下可以使用.

• Wired: 内存中固定的页面 ，经常是为了内核的目的，偶尔 在进程中为了特定的使用.

• 页面处于非活跃 (inactive) 状态时， 通常会回写至磁盘 (相当于 VM 同步)， 但活跃 (active) 的页面有时也会被同步。 这取决于 CPU 是否有能力追踪修改位， 因为有些时候将 VM 页面成批回写而无论它们是或否是活跃状态是有好处的。 多数情况下， 可以将非活跃页面队列理解为近期使用较少的页面， 它们有可能会进行回写， 也可能不进行回写。 缓存 (cached) 页面是已经同步、 但已经不再有映射关系的页面， 这些页面可以在进程需要时立即以之前， 或新的关联方式使用。 空闲 (free) 页面在中断一级可以使用， 而缓存和空闲页在进程状态下都可以随时重新使用。 中断模式下， 由于缓存页没有进行充分的上锁， 因而无法直接加以利用。

  一些其他的标志 (例如， 忙标志或忙计数) 可能会改变前面所说的一些规则。

有几个种类的 “空闲 内存”. 一类是不需要换出任何页面的立即可用的内存总量. 这个大约是 cache 队列的大小 + free 队列的大小 (含有一个降阶因子,这依赖于系统调整 .) 另外一类 “空闲内存” 是 VM 空间的总量。 这个 复杂些，但它依赖于交换空间的大小和内存 。 其他类型的 “ 空闲内存 ” 描述也是可能的, 但是定义这些基本没有用 ，除了对确定页面调度率保持很低和确保不用完交换分区很重要外.

/var/empty 是一个 sshd(8) 程序在进行特权分离时使用的目录. /var/empty 目录是空的，拥有者是 root ,还被设置了 schg 标志 .

虽然不建议删除这个目录 ,但如果需要,你要先除去 schg 标志 。查看 chflags(1) 手册,关于它更多的信息 ( 并且记住答案 the question on unsetting the schg flag).

X 视窗系统 (通常也称作 X11) 是在 UNIX 或 类-UNIX 系统， 也包括 FreeBSD 中使用最为广泛的视窗系统。 X.Org 基金会 掌管着 X 协议标准， 以及其最新的参考实现， 版本 11 的 7.5.1 版， 您会经常看到有人将其简称为 X11。

这套系统在不同的硬件平台和操作系统上也有许多不同的实现。 对其服务器端的实现， 通常也称为 X 服务。

过去， 在 FreeBSD 上默认的 X 实现是由 The XFree86 Project, Inc. 维护的 XFree86™。 这个软件在 FreeBSD 到 4.10 和 5.2 以前的所有版本都是默认的。 尽管 Xorg 自己在这段时间也维护了一个实现， 但它基本上只是作为一个参考平台提供， 因为它本身有非常多的问题， 而代码也已年久失修。

然而， 在 2004 年初， 由于对代码变动节奏、 未来方向， 以及一些人际关系上发生的冲突， 导致一些 XFree86 开发人员离开了这个项目， 转而直接为 Xorg 进行开发。 此时， Xorg 将其代码更新到了在 XFree86 修改授权之前的最后一个版本 (XFree86 version 4.3.99.903)， 并集成了许多先前独立维护的变动， 并将这一软件作为 X11R6.7.0 发布。 一个独立但相关的项目， freedesktop.org (或简写为 fd.o)， 则开始重构之前的 XFree86 代码， 以便将更多的工作下放给图形卡 (以期改善性能)， 并将其变得更加模块化 (以期改善可维护性， 以便更快地发布新版本， 并更容易配置)。 Xorg 计划在未来的版本中集成 freedesktop.org 所做的修改。

2004 年 7 月， 在 FreeBSD-CURRENT 上， Xorg 取代 XFree86 成为了默认实现。 此后， FreeBSD 中默认的 X11 实现就是 Xorg 了。

如欲了解进一步的信息， 请参阅 FreeBSD 使用手册中的 X11 部分。

这个问题的答案已经超出了这个 FAQ 的范围。 在 Internet 上关于这个问题有许多邮件列表存档， 因此您可以使用最喜欢的搜索引擎来查找这一历史， 而不是在 FreeBSD 邮件列表中提问。 有些情况则可能只有当事人清楚。

Xorg 开发人员宣称他们的目标是更快地发布新版本， 并在其中集成新特性。 如果他们确实能做到这一点， 那么这将是非常有吸引力的。 此外， 他们的软件仍然使用传统的 X 授权， 而 XFree86 则使用了他们修改过的授权。

如果需要在已经装好的系统上增加 X， 则应使用 x11/xorg meta-port， 它会联编并安装所有需要的组件， 或通过 FreeBSD 预编译包来安装 Xorg：

# pkg_add -r xorg

另外， 您也可以通过在 sysinstall(8) 中选择 Configure、 Distributions， 然后是 The X.Org Distribution 来安装 Xorg。

装好 Xorg 之后， 您应按照联机手册 xorgconfig(1) 进行操作。 它会帮助您配置 Xorg 使用您的显卡、 鼠标等设备。 此外， 您也可以看看 xorgcfg(1) 工具， 它使用图形化的界面来完成 X 的配置过程。

如欲了解进一步的信息， 请参阅 FreeBSD Handbook 中的 X11 部分。

您的系统可能是以较高的 securelevel 运行的。 在提高了 securelevel 的系统上是不能运行 X 的， 因为 X 需要对 io(4) 进行写操作。 如欲了解进一步的详情， 请参阅联机手册 init(8)。

所以这个问题变成： 您需要如何解决这个问题。 基本上， 您有两种选择： 要么将 securelevel 降回零 (通常是在 /etc/rc.conf)， 要么在系统启动时就运行 xdm(1) (在 securelevel 被升高之前)。

请参考 问： 11.12. 以取得更多有关启动时执行 xdm(1) 的信息。

如果您用的是 syscons(4) (默认的 console 驱动程序) 的话， 您可以经由设定 FreeBSD 来让它支持在每个 virtual console 使用鼠标。 为了避免和 X 产生冲突， syscons(4) 使用了一个叫做 /dev/sysmouse 的虚拟装置。 所有鼠标产生的事件， 都会利用 moused 来写到 sysmouse 这个装置。 如果您希望在一个或更多 virtual console 上使用鼠标， 而且 还要使用 X 的话， 请参考 问： 4.5.4. 来配置 moused。

然后编辑 /etc/X11/xorg.conf 这个文件， 并确认你有以下这几行的配置：

Section "InputDevice"
   Option          "Protocol" "SysMouse"
   Option          "Device" "/dev/sysmouse"
.....

有些人比较喜欢在 X 中使用 /dev/mouse。 为了让这个配置正常工作， 需要将 /dev/mouse 连接到 /dev/sysmouse (请参考联机手册 sysmouse(4))， 具体做法是在 /etc/devfs.conf (请参考联机手册 devfs.conf(5)) 中加入下列配置：

link    sysmouse    mouse

以 root)身份重启 devfs(5)：

# /etc/rc.d/devfs restart

可以。

您需要告诉 X 您使用的是 5 键鼠标。 要完成这项工作， 只需将 Buttons 5 和 ZAxisMapping 4 5 写到 /etc/X11/xorg.conf 中的 “InputDevice” 小节就可以了。 例如， 您可能会希望在 /etc/X11/xorg.conf 中使用下面的 “InputDevice” 配置。

Section "InputDevice"
   Identifier      "Mouse1"
   Driver          "mouse"
   Option          "Protocol" "auto"
   Option          "Device" "/dev/sysmouse"
   Option          "Buttons" "5"
   Option          "ZAxisMapping" "4 5"
EndSection

;; wheel mouse
(global-set-key [mouse-4] 'scroll-down)
(global-set-key [mouse-5] 'scroll-up)

基于安全理由， 默认的配置中是不允许一台机器启用远程窗口的。

要启用这一功能， 只需在启动 X 时指定可选的 -listen_tcp 参数：

% startx -listen_tcp
       

简单来说，virtual console 就是可以让您不必做太多复杂的设置， 例如使用网络或执行 X， 而在同一台机器上同时做好几件事的方法。

当启动系统并显示完所有开机信息之后，您就会在屏幕上看到一个 login 的提示符号。在这个时候您就可以输入您的 login name 以及 password， 然后就可以在第一个 virtual console 上开始工作了 (或者开始玩！)。

在某些情况下，您可能会想要作其它的工作，例如说是看看您正在执行的程序的说明文件， 或是当您在 FTP 传输的等待时间中看看您的邮件。 您只需要按 Alt+F2 (按住 Alt 键不放，并按下 F2 键)， 然后您就会在第二个 “virtual console”上看到一个 login 提示符了！ 当您想要回到原来的工作时，请按 Alt+F1。

FreeBSD 在安装时的默认值是使用八个 virtual consoles。 您可以使用 Alt+F1、 Alt+F2、 Alt+F3 等等这些组合键在它们之间做切换。

如果需要更多的 virtual console 的话， 需要编辑 /etc/ttys (请参阅 ttys(5)) 并在 “Virtual terminals” 后面的注释处添加从 ttyv8 到 ttyvc 的对应项：

# Edit the existing entry for ttyv8 in /etc/ttys and change
# "off" to "on".
ttyv8   "/usr/libexec/getty Pc"         cons25  on secure
ttyv9   "/usr/libexec/getty Pc"         cons25  on secure
ttyva   "/usr/libexec/getty Pc"         cons25  on secure
ttyvb   "/usr/libexec/getty Pc"         cons25  on secure

您想用几个就设几个。 您设的 virtual terminal 越多， 它们就用掉越多系统资源； 如果您只有不到 8MB RAM 的内存的话，这影响就大了。 您可能也会想把 secure 换成 insecure。

取消一个 console 最简单的方法就是把它关掉。举例来说，如果 您像上面讲的一样设定了全部的 12 个 terminal 并且想要执行 X ， 您必需把 virtual terminal 12 的配置从：

ttyvb   "/usr/libexec/getty Pc"         cons25  on  secure

改为：

ttyvb   "/usr/libexec/getty Pc"         cons25  off secure

如果您的键盘只有 10 个功能键的话，您就要改成这样：

ttyv9   "/usr/libexec/getty Pc"         cons25  off secure
ttyva   "/usr/libexec/getty Pc"         cons25  off secure
ttyvb   "/usr/libexec/getty Pc"         cons25  off secure

(您也可以直接把这几行砍掉。)

接下来， 想要启动这些 virtual console 最简单 (也是最干净) 的做法就是重开机。然后，如果您不想重开机的话，您可以把 X Window 关掉，然后 (以 root 身份)：

# kill -HUP 1

当您执行这个命令前，您一定要完全把 X Window 关掉。如果 您不这么做的话，您的系统可能会在您执行 kill 命令后出现当掉， 或出现死锁的情况。

请用 Ctrl+Alt+Fn 以切回至 virtual console。 Ctrl+Alt+F1 可以切回至第一个 virtual console。

当你切回至文字 console 后，你就可以使用一般的 Alt+Fn 组合键在各 console 之间切换了。

要回到 X 的话，你必须切回至执行 X 的 virtual console。 如果你是从命令行启动的 X 的话， (例如， 使用 startx)， 那么 X 会依附在下一个未使用的 virtual console， 而不是它被启动的文字 console。如果你有八个使用中的 virtual terminal，那么 X 就会在第九个上执行，你就可以使用 Alt+F9 以返回至 X 中。

启动 xdm(1) 有两种不同流派的方法。 一种是像前面的例子那样使用 /etc/ttys (参见 ttys(5)) 来启动 xdm， 另一种则是简单地在 rc.local (参见 rc(8)) 中启动 xdm， 或使用 /usr/local/etc/rc.d 中的 X 脚本来启动它。 这两种方法都是有效的， 但有时一种方法适用， 而另一种则不适用。 它们的结果都是一样的： X 会弹出一个图形化的登录提示。

使用 ttys(5) 的优点在于指明了用于启动 X 的 vty， 并将在注销之后重启 X 服务器的责任转嫁给了 init(8)。 rc(8) 方法的优点则在于它使得在 X 服务器出现问题时对 xdm 使用 kill xdm 变得容易。

如果透过 rc(8) 来加载， xdm 应以不带参数的方式启动 (也就是说， 以服务方式启动)。 xdm 命令必须在 getty(8) 启动 之后 运行， 否则 getty 和 xdm 会发生冲突， 并导致控制台发生死锁。 绕过这个问题的方法是让脚本休眠 10 秒左右， 然后再运行 xdm。

即使透过 /etc/ttys 来启动 xdm， 仍然有可能出现 xdm 和 getty(8) 发生冲突的情况。 避免这个问题的方法是在 /usr/local/lib/X11/xdm/Xservers 文件中配置 vt 编号：

:0 local /usr/local/bin/X vt4

上面的例子会指示 X 服务器在 /dev/ttyv3 上运行。 请注意这些数字是差一的， 因为 X 服务器从一开始对 vty 进行编号， 而 FreeBSD 内核则是从零开始对 vty 进行编号。

如果你是用 startx 来启动 startx 的话， /dev/console 的权限并 不会 改变， 结果就是 xterm -C 和 xconsole 这类的程序无法正常执行。

这一切的问题，都是因为控制台 (console) 的权限是采用系统默认值。 在一个多用户的系统里， 我们不希望每个使用者都可以直接写入系统控制台。 如果使用者是从机器的 VTY 直接 login 的话，那么 fbtab(5) 可以解决这类的问题。

简单地说，请确保 /etc/fbtab (请参考 fbtab(5)) 这个文件中的这一行没有被注释掉：

/dev/ttyv0 0600 /dev/console

这一行设定的存在可以确保从 /dev/ttyv0 登入的使用者可以控制 console。

所有的 X server 都需要以 root 来执行， 才能直接存取你的视讯硬件。旧版本的 XFree86 (<= 3.3.6) 会自动 将所附的 server 以利用 root 身份执行的方式安装起来 (setuid 为 root)。 由于 X server 都是体积庞大又复杂的程序， 显而易见地， 这是一个安全上的灾难。 因为这个原因， 新版的 XFree86 就不将这些 server 以 setuid 为 root 的方式安装。

很明显地，我们完全无法接受将 X server 以 root 的身份执行。起码就安全上不是个好主意。 有两种方法可以以一般使用者的身份使用 X。第一是利用 xdm 或是其它的 display manager (例如 kdm)；第二是利用 Xwrapper。

xdm 是一个处理图形界面登入的 daemon。 它通常在开机时执行起来，而且负责对使用者作身份认证，以及起动 使用者的工作环境；它可说是图形环境下的 getty(8) 与 login(1) 的对应程序。 想得知更多有关 xdm 的信息，请参考 XFree86 文档，以及其 FAQ 项目。

Xwrapper 是 X server 的包装程序；它可以 让一般使用者可以手动起动 X server 的小工具，而还能维持一定的安全 环境。它会检查传入的命令列参数，如果没问题的话，就起动适当的 X server。如果你因为某种理由而不想执行 display manager 的话， 它是为你而设定的。如果你安装了完整的 Ports 套件，你可以在 x11/wrapper 中找到它。

您的鼠标和您的鼠标驱动程序可能存在有不同步的现象。

在极少数的案例中， 这些驱动程序会误报同步性错误， 然后您就会看到这样的内核信息：

psmintr: out of sync (xxxx != yyyy)

然后您就会发现您的鼠标不能正常运作了。

如果发生了这样的状况， 就必须将 PS／2 鼠标驱动的 flag 配置我 0x100 来关闭同步确认。 在开机提示符处输入 -c 来进入 UserConfig：

boot: -c

然后，在 UserConfig 命令列中键入：

UserConfig> flags psm0 0x100
UserConfig> quit

有一些报告指出某些厂牌的 PS/2 鼠标只能在 “高分辨率” 状态下才能运作。如果不是的话，鼠标光标 会常常跑到屏幕的左上角去。

在 PS/2 鼠标驱动程序中设定 0x04 的 flag 会把鼠标设成高分辨率模式。在开机提示符号时用 -c 选项来进入 UserConfig：

boot: -c

然后，在 UserConfig 的命令行中键入：

UserConfig> flags psm0 0x04
UserConfig> quit

前一节有提到另一个可能导致鼠标问题的原因。

在您的 .xinitrc 或 .xsession 中执行 xmodmap -e "pointer = 3 2 1"。

FreeBSD 提供了在启动时显示 “splash” 图形的功能。 目前， splash 图形必须是 256 色的位图 (*.BMP) 或 ZSoft PCX (*.PCX) 文件。 此外， 如果使用标准 VGA， 它们的分辨率必须是 320x200 或更低； 而如果您的内核有编入 VESA 支持， 则可以使用大至 1024x768 的图形。 实际的 VESA 支持可以通过 VESA 内核配置选项直接联编进内核， 也可以通过在启动时加载 VESA kld 模块来启用。

要使用 splash 图形， 您需要修改控制 FreeBSD 启动过程的文件。

您的 /boot/loader.rc 必须包括这几行：

include /boot/loader.4th
start

还需要一个包含以下几行的 /boot/loader.conf：

splash_bmp_load="YES"
bitmap_load="YES"

这是假设您用 /boot/splash.bmp 来当作 splash 的屏幕显示。如果想用 PCX 的档案，把它拷成 /boot/splash.pcx，如上述做出 /boot/loader.rc，再将这几行加到 /boot/loader.conf 中：

splash_pcx_load="YES"
bitmap_load="YES"
bitmap_name="/boot/splash.pcx"

现在就只剩下 splash 用来显示的图文件，您可以在 http://www.baldwin.cx/splash/ 找到各种样品。

可以。你所要作的，就是利用 xmodmap(1) 去定义你想使用的功能。

假设所有的 “Windows” 键盘都是标准的， 那这 3 个键的 keycode 分别为：

• 115 ── Windows 键， 在左手的 Ctrl 和 Alt 键之间

• 116 ── Windows 键， 在 AltGr 键右边

• 117 ── Menu 键， 在右手 Ctrl 键左边

要让左手的 Windows 键对应逗点， 试试这个：

# xmodmap -e "keycode 115 = comma"

你可能要重跑你的 windows manager，才会有动作。

要让 Windows 键的对映在每次 X 起动时自动设定好，你可以在你的 ~/.xinitrc 里加上 xmodmap， 或是最好建立一个 ~/.xmodmaprc 文件， 里面每一行就是一个 xmodmap 的选项， 然后把

xmodmap $HOME/.xmodmaprc

加到你的 ~/.xinitrc 中。

例如， 你想要将这三个键各对映到 F13、 F14 和 F15。 这让你能在你的程序或是 window manager 内将其对应到便利的功能上，等一下 我们会示范。

把这些放进 ~/.xmodmaprc。

keycode 115 = F13
keycode 116 = F14
keycode 117 = F15

假如你用 x11-wm/fvwm2 port 的话，你可以作这样的对映， 让 F13 能够让光标所在的窗口缩成小图标 (或是反过来)。 F14 让光标所在的窗口变成最上层的窗口， 或是退到下层去 (如果它已经是最上层了的话)。 F15 则将主 Workplace (应用程序) 选单叫出来， 即使光标不在桌面上。 当你没有可见的桌面区域时， 这个功能就相当地方便 (而且按键上的图案和这个功能相吻合)。

以下的 ~/.fvwmrc 配置可作出前述的功能。

Key F13        FTIWS    A        Iconify
Key F14        FTIWS    A        RaiseLower
Key F15        A        A        Menu Workplace Nop

是否能够使用 3D 加速能力取决于您使用的 Xorg 版本， 以及所使用的显示芯片型号。 如果您使用 nVidia 芯片， 可以通过下面的 ports 来安装针对 FreeBSD 的二进制驱动：

• 最新的 nVidia 卡由 x11/nvidia-driver port 支持。

• 类似 GeForce2 MX/3/4 系列的 nVidia 卡由 96XX 系列的驱动程序支持， 您可以通过 x11/nvidia-driver-96xx port 来安装。

• 更老一些的卡， 如 GeForce 和 RIVA TNT， 由 71XX 系列的驱动程序支持， 您可以通过 x11/nvidia-driver-71xx port 来安装。

事实上， nVidia 提供了关于哪个驱动能够支持哪些显卡的详细信息。 这些信息可以从他们的网站获得： http://www.nvidia.com/object/IO_32667.html。

对于 Matrox G200/G400， 您需要安装 x11-servers/mga_hal port。

对于 ATI Rage 128 和 Radeon， 请参阅联机手册 ati(4)、 r128(4) 以及 radeon(4)。

对于 3dfx Voodoo 3、 4、 5 以及 Banshee 显卡， 有对应的 x11-servers/driglide port。

“无盘启动” 就是让 FreeBSD 从网络启动， 并且从网络上的 server 上读取其它必要的文件， 而非由本机硬盘上获得。 详细的资料， 可以参考 FreeBSD 使用手册中关于无盘启动的部分。

可以的。 请参见使用手册中的 网络进阶篇， 特别是其中的 路由器与网关 部分。

基本上，会问这种问题的人在家里至少有两台计算机，一台跑 FreeBSD 另外一台跑某个版本的 Windows； 具体的想法是将 FreeBSD 主机连上 Internet， 然后透过这台 FreeBSD 主机， 让跑 Windows 的计算机能够上网。 这个问题算是前一个问题的一个特例， 因此答案当然是可以的。

如果您正使用拨号方式接入 Internet， 则可以使用用户态 ppp(8) 提供的 -nat 选项。 如果您在运行 ppp(8) 时指定了 -nat 选项， 则应在 /etc/rc.conf 中将 gateway_enable 设置为 YES， 并相应地对 Windows 机器进行配置， 这样就可以很好地工作了。 具体细节， 请参见 ppp(8) 的联机手册， 以及 使用手册中关于 PPP 的那章。

如果使用的是内核模式的 PPP， 或者以以太网方式联入 Internet， 则需要使用 natd(8)。 请参见使用手册中的 natd 部分所提供的教程。

是的。 你可以查查 slattach(8)、 sliplogin(8)、 ppp(8)， 以及 pppd(8) 的联机手册， 以了解相关的情况。 ppp(8) 和 pppd(8) 分别提供了进出双向联机的支持， 另外 sliplogin(8) 专门提供进入联机的支持， 而 slattach(8) 专门提供向外联机的支持。

如果你需要更进一步的数据的话， 请查阅 使用手册关于 PPP 和 SLIP 的部分。

如果你只能够过 “shell 帐号” 来访问 Internet， 的话， 也许可以试试 net/slirp 这个套件程序。 这个套件程序可以提供你的计算机直接连上某些 (有限的) 服务， ftp 及 http 等等。

是的。 如果您希望在用户态 PPP 连接上使用 NAT 的话， 请参见 使用手册中关于用户态 PPP 的部分。 如果您希望在某种其它形式的网络连接上使用 NAT， 请参阅使用手册中的 natd 部分。

请参考手册中关于 PLIP 的部分。

如果你的 alias 地址跟你目前网络接口的地址在同一个子网下的话， 在 ifconfig(8) 命令行中指定 netmask 0xffffffff， 类似下面这样：

# ifconfig ed0 alias 192.0.2.2 netmask 0xffffffff

反之， 就像平时那样指定子网掩码即可：

# ifconfig ed0 alias 172.16.141.5 netmask 0xffffff00

You can read more about this in the FreeBSD Handbook.

如果您想使用其它的网口， 必须在 ifconfig(8) 的命令中指定额外的参数。 默认的端口是 link0。 如果希望使用 AUI 网口来代替 BNC 的话， 则应指定 link2。 这些参数也应放到 /etc/rc.conf 中的 ifconfig_* 变量中 (参见 rc.conf(5))。

我们用含蓄一点的说法，某些 PC 的网络卡比其它的好， 这种状况在造成 NFS 这种对网络敏感的程序有时会出现问题。

参考 使用手册中关于 NFS 的部分 以了解进一步的详情。

某些版本的 Linux NFS 程序代码只接受来自特权端口的挂接请求； 试用这行指令看看：

# mount -o -P linuxbox:/blah /mnt

跑 SunOS™ 4.X 的 Sun 工作站只接受来自特权端口的挂接请求； 试用这行指令看看：

# mount -o -P sunbox:/blah /mnt

这个问题最常发生的原因是在于不了解 /etc/exports 的正确格式。 请详读 exports(5) 以及使用手册中的 NFS 部分， 特别是 配置 NFS 这节。

尝试禁用 TCP 扩展， 方法是在 /etc/rc.conf (参见 rc.conf(5)) 中， 把以下这个值设成 NO：

tcp_extensions=NO

Xylogic 的 Annex 主机也有相同的问题， 您要做相同的修改才能连上这些主机。

FreeBSD 默认即支持多播主机的操作。 如果希望让您的机器作为多播路由器运行， 则需要重新编译内核， 以便在其中加入 MROUTING， 并运行 mrouted(8)。 如果您在 /etc/rc.conf 中将 mrouted_enable 设置为 YES， 则 FreeBSD 会在开机时自动启动 mrouted(8)。

MBONE 的各种工具可以在它们 ports 下所属叫做 mbone 的目录中找到。 如果您在找视频会议的工具如 vic 或 vat， 看看那里吧。

以下是 Glen Foster <gfoster@driver.nsta.org> 提供的清单：

请参阅 FreeBSD Handbook 中的答案。

如果您有在内核中联编进 IPFIREWALL 选项， 则需要小心其默认配置是禁止所有没有明确地允许的包。

如果您无意中错误地配置了系统中的防火墙设置， 则可以以 root 身份登录系统， 并输入下面的命令：

# ipfw add 65534 allow all from any to any

也可以在 /etc/rc.conf 加入 firewall_type="open" 的配置。

关于如何配置 FreeBSD 防火墙的进一步细节， 请参见 使用手册中的对应章节。

可能是你除了转送封包以外还额外想进行地址转译 (NAT)。 “fwd” 规则所进行的动作就如同字面所示； 仅转送封包， 它并不会去修改封包中的数据。 假设我们有如下的规则：

01000 fwd 10.0.0.1 from any to foo 21

当一个通往特定目标地址 foo 的封包送达主机时， 根据这条规则， 封包将被转送至 10.0.0.1， 但是它的目标地址却仍然是 foo！ 封包的目标地址并 没有 更改为 10.0.0.1。 大部分的主机会将封包丢弃， 因为它们并不是这个目标地址。 因此， 使用 “fwd” 规则时往往不如使用者所预期的那般顺利。 这种行为是系统特性，而非错误。

参考 关于服务转向的常见问答集、 natd(8) 联机手册， 或是使用 Ports 套件 中许多服务转向的工具来正确地完成你想进行的工作。

您可以利用 sysutils/socket port 来对 FTP (以及其他服务) 进行转向。 只需简单地将服务命令替换为 socket， 如下所示：

ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.example.com ftp

其中 ftp.example.com 和 ftp 分别是被转到的机器和服务端口名称。

FreeBSD 上提供了三种带宽管理工具。 dummynet(4) 是以 ipfw(4) 一部分的形式整合进 FreeBSD 的， 而 ALTQ 则是作为 pf(4) 的一部分整合进来。 Emerging Technologies 提供的 Bandwidth Manager 则是商业产品。

你执行了一个需要 Berkeley 封包过滤器 (bpf(4)) 的程序， 但在内核中则没有。 把下面这一行加到内核的编译配置中， 并重新联编新的内核：

device bpf        # Berkeley Packet Filter

使用 SMBFS 工具组。 这套工具组中包含了一系列的内核变动， 以及一些使用者的工具程序。 这些程序和信息在是作为基本系统中的 mount_smbfs(8) 提供的。

这是系统内核告诉你有某些活动引发它送出比它所认为应该送出更多的 ICMP 或 TCP 重置 (RST) 回应。 ICMP 响应讯息常常是因为有人尝试连接未被使用的通讯端口。 而 TCP 重置讯息则是有人尝试连接未开放 TCP 通讯端口造成的结果。 以下这些活动可能就是造成这些讯息的原因：

• 暴力法的拒绝服务 (DoS) 攻击 (相较于针对特殊弱点使用单一封包的攻击方式)。

• 大量的通讯端口扫描 (相较于仅尝试少数的常见服务通讯端口)。

出现的数字中第一个代表根据这些流量内核应该送出的封包数， 第二个数字则是内核目前限制最大发送数。你可以利用 sysctl 修改 net.inet.icmp.icmplim 变数值来更改最大值。 举例来说， 如果希望修改限制为每秒 300 个：

# sysctl -w net.inet.icmp.icmplim=300

如果你不想在系统日志中看到这些讯息， 但是仍然希望保持响应的限制的话， 你可以利用 sysctl 修改 net.inet.icmp.icmplim_output 来取消这些讯息：

# sysctl -w net.inet.icmp.icmplim_output=0

最后， 如果你想取消这些限制的话， 可以把 sysctl 变量 net.inet.icmp.icmplim 设定 (如上例所示) 为 0基于上述理由， 我们建议你不要取消这些限制。

这代表你的局域网络联机上有一些设备使用 FreeBSD 看不懂的 MAC 地址格式。 这通常是代表有人在你的局域网络上进行实验， 最常见的就是 cable modem 的联机。 这讯息无害， 而且应该不至于影响到 FreeBSD 主机的效能。

首先，看看错误的讯息是否如下：

/usr/libexec/ld-elf.so.1: Shared object "libXaw.so.6" not found

这种错误讯息代表你主机上安装的 net/cvsup 没有配合所需的 Xorg 套件一起安装。 如果您希望使用 CVSup 的 GUI， 则应安装 Xorg。 此外， 如果只希望使用命令行模式的 CVSup， 则应首先卸载先前安装的套件， 并安装 net/cvsup-without-gui 或 net/csup。 如果您使用较新的 FreeBSD 版本， 可以试试看 csup(1)。 在使用手册中的 CVSup 一节 中有更详细的说明。

“沙盒” 是一个安全术语。 它有两种含义：

• 放在某些虚拟防护墙里的执行程序， 这些防护墙是用来阻止某些人侵入进程， 进而出入于系统中更大的范围。

  进程可以完全在防护墙里 “动作”。 也就是说， 它所执行的任何程序不可能会渗透到墙的外面。 所以如果您对它有安全上的顾虑， 并不需要特别去监听它的一举一动， 因为反正它只能在墙内活动。

  举例来说，可以用 user ID 来做这道防护墙，这正是 security(7) 和 named(8) 联机手册中的定义。

  现在就用 ntalk 这个服务作说明 (见 inetd(8))。 这个服务以前的 user ID 是 root， 现在执行时则是用 tty。 tty 这个用户就是一个 sandbox， 即使有人能够顺利用 ntalk 侵入系统， 现在他就算进得来也只能用这个 user ID。

• 放在某个仿真机器里的程序，这比上述来得更严密。 基本上这表示能侵入该程序的人相信他能再进入所属的机器， 但事实上只会进入模拟出来的机器， 无法进一步修改任何真实的数据。

  达到这个目的最常用的方法， 就是在某个子目录下做出仿真的环境， 然后用 chroot 执行该程序 (也就是说， 对于那个进程而言 / 并不是系统中真实的 /)。

  另一个常见作法是将某个档案系统 mount 成只读， 但在它上面另外制造出程序以为可以写入的档案系统。 这个程序会相信它可以对其他档案读写， 但只有它看不到这个只读效应 ── 系统执行的一般程序都看得到。

  我们试图将这类沙盒尽量透明化， 让使用者或侵入者无法看到他是否在某个沙盒里面。

UNIX 实现了两种核心沙盒。 其一是在进程层面， 另一个则是通过 userid 来达成。

每个 UNIX 执行程序会用防火墙将它和所有其它程序隔开， 某个程序不可以随意修改其它程序地址空间中的数据。 这和 Windows 中， 进程可以轻易覆盖其它地址空间的数据， 并导致崩溃的情形完全不同。

每个 UNIX 进程都归属于特定的 user ID。 如果 user ID 不是 root 用户， 则它也是对于其他用户所有的进程的一道防火墙。 除此之外， user ID 也被用来管理磁盘配额。

securelevel 是在内核中实现的一种安全机制。 基本上， 当 securelevel 是正值时， 内核会限制某些操作； 即使是超级用户 (也就是 root) 也无法完成那些工作。 在撰写在一般的限制外，还能够限制以下的功能：

• 清除某些文件标记， 例如 schg (系统只读标志)，

• 经由 /dev/mem 和 /dev/kmem 将数据写入至内核内存中，

• 加载内核模块， 以及

• 修改防火墙规则

想要检查在某个运作中的系统的 securelevel 状态， 只要执行以下命令即可：

# sysctl kern.securelevel

输出的结果会包含一个 sysctl(8) 变量名称 (本例中为 kern.securelevel) 以及一个数字。 后者即是目前 securelevel 的值。 如果它是一个正值 (也就是大于 0)， 则表示启用了某些或全部 securelevel 的保护机制。

运行中的系统是无法降低其 securelevel 的； 如果可以的话， 这个机制就失去意义了。 如果你要作一些需要 securelevel 为非正值才可以的动作的话 (例如 installworld 或修改日期)， 就必须修改 /etc/rc.conf 中的 securelevel 配置 (找找 kern_securelevel 和 kern_securelevel_enable 变量)， 并重启系统。

如欲了解更多有关于 securelevel 以及不同等级影响的细节， 请参见 init(8) 联机手册。

BIND 用随机的高编号通讯端口来对外查询。 如果你因为要适合防火墙的配置， 或是单纯的想让自己看来舒服一点而想用 53 通讯端口进行对外查询， 则可以尝试更改 /etc/namedb/named.conf 中的相关内容：

options {
        query-source address * port 53;
};

如果希望进行进一步的限制， 还可以将 * 改为特定 IP 地址。

顺便恭喜你。 能够读取你系统上的 sockstat(1) 报告并且留意不正常状况是一件好事！

较新版本的 sendmail 支持 mail submission 这项功能， 并且使用通讯端口 587。 这项功能还没有被广泛支持， 但是支持的数目正在增长中。

放心。 toor 是一个 “备用的” 超级用户帐号 (toor 是 root 的反向拼法)。 以往它是随安装 bash(1) 而建立的， 后来则成为系统内定建制的一个账号。 这个账号将伴随一个非标准的 shell 测试使用， 让你不需要去更改 root 的内建 shell。 因为这些其它的 shell 默认并不随系统安装 (举例来说，某些由 ports 安装的 shell packages)， 会默认安装在 /usr/local/bin 目录下， 有可能存在不同的文件系统中。 倘若 root 的 shell 位于 /usr 中的 /usr/local/bin (或其它包含 /usr/local/bin 的文件系统) 由于某种原因没有挂接， 则 root 将没有机会登录并修正问题 (不过， 如果您重启并进入单用户模式， 则系统会提示您选择 shell 所在的路径)。

有些人使用 toor 账号进行日常的 root 维护工作， 如此可以使用非标准的 shell， 而 root 则可以保留标准 shell， 以因应单用户模式或紧急状况处理。 依照系统默认值， 是无法使用 toor 登入的， 因为这个账号尚未更改密码。 因此如果想启用这个账号， 就需要为 toor 设置口令了。

出于安全方面的考虑， suidperl 默认并不安装。 如果您希望在以源代码方式升级时联编 suidperl， 应在联编 perl 之前修改 /etc/make.conf 并添加 ENABLE_SUIDPERL=true。

You should first read the ppp(8) manual page and the PPP section of the handbook. Enable logging with the command

set log Phase Chat Connect Carrier lcp ipcp ccp command

This command may be typed at the ppp(8) command prompt or it may be entered in the /etc/ppp/ppp.conf configuration file (the start of the default section is the best place to put it). Make sure that /etc/syslog.conf (see syslog.conf(5)) contains the lines

!ppp
*.*        /var/log/ppp.log

and that the file /var/log/ppp.log exists. You can now find out a lot about what is going on from the log file. Do not worry if it does not all make sense. If you need to get help from someone, it may make sense to them.

This is usually because your hostname will not resolve. The best way to fix this is to make sure that /etc/hosts is consulted by your resolver first by editing /etc/host.conf and putting the hosts line first. Then, simply put an entry in /etc/hosts for your local machine. If you have no local network, change your localhost line:

127.0.0.1        foo.example.com foo localhost

Otherwise, simply add another entry for your host. Consult the relevant manual pages for more details.

You should be able to successfully ping -c1 `hostname` when you are done.

First, check that you have got a default route. By running netstat -rn (see netstat(1)), you should see two entries like this:

Destination        Gateway            Flags     Refs     Use     Netif Expire
default            10.0.0.2           UGSc        0        0      tun0
10.0.0.2           10.0.0.1           UH          0        0      tun0

This is assuming that you have used the addresses from the handbook, the manual page, or from the ppp.conf.sample file. If you do not have a default route, it may be because you forgot to add the HISADDR line to the ppp.conf file.

Another reason for the default route line being missing is that you have mistakenly set up a default router in your /etc/rc.conf (see rc.conf(5)) file and you have omitted the line saying

delete ALL

from ppp.conf. If this is the case, go back to the Final System Configuration section of the handbook.

This error is usually due to a missing

MYADDR:
  delete ALL
  add 0 0 HISADDR

section in your /etc/ppp/ppp.linkup file. This is only necessary if you have a dynamic IP address or do not know the address of your gateway. If you are using interactive mode, you can type the following after entering packet mode (packet mode is indicated by the capitalized PPP in the prompt):

delete ALL
add 0 0 HISADDR

Refer to the PPP and Dynamic IP addresses section of the handbook for further details.

The default PPP timeout is 3 minutes. This can be adjusted with the line

set timeout NNN

where NNN is the number of seconds of inactivity before the connection is closed. If NNN is zero, the connection is never closed due to a timeout. It is possible to put this command in the ppp.conf file, or to type it at the prompt in interactive mode. It is also possible to adjust it on the fly while the line is active by connecting to ppp's server socket using telnet(1) or pppctl(8). Refer to the ppp(8) man page for further details.

If you have Link Quality Reporting (LQR) configured, it is possible that too many LQR packets are lost between your machine and the peer. Ppp deduces that the line must therefore be bad, and disconnects. Prior to FreeBSD version 2.2.5, LQR was enabled by default. It is now disabled by default. LQR can be disabled with the line

disable lqr

Sometimes, on a noisy phone line or even on a line with call waiting enabled, your modem may hang up because it thinks (incorrectly) that it lost carrier.

There is a setting on most modems for determining how tolerant it should be to temporary losses of carrier. On a U.S. Robotics® Sportster® for example, this is measured by the S10 register in tenths of a second. To make your modem more forgiving, you could add the following send-expect sequence to your dial string:

set dial "...... ATS10=10 OK ......"

Refer to your modem manual for details.

Many people experience hung connections with no apparent explanation. The first thing to establish is which side of the link is hung.

If you are using an external modem, you can simply try using ping(8) to see if the TD light is flashing when you transmit data. If it flashes (and the RD light does not), the problem is with the remote end. If TD does not flash, the problem is local. With an internal modem, you will need to use the set server command in your ppp.conf file. When the hang occurs, connect to ppp(8) using pppctl(8). If your network connection suddenly revives (PPP was revived due to the activity on the diagnostic socket) or if you cannot connect (assuming the set socket command succeeded at startup time), the problem is local. If you can connect and things are still hung, enable local async logging with set log local async and use ping(8) from another window or terminal to make use of the link. The async logging will show you the data being transmitted and received on the link. If data is going out and not coming back, the problem is remote.

Having established whether the problem is local or remote, you now have two possibilities:

• If the problem is remote, read on entry 问： 14.9..

• If the problem is local, read on entry 问： 14.10..

There is very little you can do about this. Most ISPs will refuse to help if you are not running a Microsoft OS. You can enable lqr in your ppp.conf file, allowing ppp(8) to detect the remote failure and hang up, but this detection is relatively slow and therefore not that useful. You may want to avoid telling your ISP that you are running user-PPP.

First, try disabling all local compression by adding the following to your configuration:

disable pred1 deflate deflate24 protocomp acfcomp shortseq vj
deny pred1 deflate deflate24 protocomp acfcomp shortseq vj

Then reconnect to ensure that this makes no difference. If things improve or if the problem is solved completely, determine which setting makes the difference through trial and error. This will provide good ammunition when you contact your ISP (although it may make it apparent that you are not running a Microsoft product).

Before contacting your ISP, enable async logging locally and wait until the connection hangs again. This may use up quite a bit of disk space. The last data read from the port may be of interest. It is usually ASCII data, and may even describe the problem (“Memory fault”, “Core dumped”).

If your ISP is helpful, they should be able to enable logging on their end, then when the next link drop occurs, they may be able to tell you why their side is having a problem. Feel free to send the details to Brian Somers <brian@FreeBSD.org>, or even to ask your ISP to contact him directly.

Your best bet here is to rebuild ppp(8) with debugging information, and then use gdb(1) to grab a stack trace from the ppp process that is stuck. To rebuild the ppp utility with debugging information, you can type:

# cd /usr/src/usr.sbin/ppp
# env DEBUG_FLAGS='-g' make clean
# env DEBUG_FLAGS='-g' make install

Then you should restart ppp and wait until it hangs again. When the debug build of ppp hangs, start gdb on the stuck process by typing:

# gdb ppp `pgrep ppp`

At the gdb prompt, you can use the bt or where commands to get a stack trace. Save the output of your gdb session, and “detach” from the running process by the quit command of gdb.

Finally, send the log of your gdb session to Brian Somers <brian@FreeBSD.org>.

Prior to FreeBSD version 2.2.5, once the link was established, ppp(8) would wait for the peer to initiate the Line Control Protocol (LCP). Many ISPs will not initiate negotiations and expect the client to do so. To force ppp(8) to initiate the LCP, use the following line:

set openmode active

Occasionally, just after connecting, you may see messages in the log that say “Magic is same”. Sometimes, these messages are harmless, and sometimes one side or the other exits. Most PPP implementations cannot survive this problem, and even if the link seems to come up, you will see repeated configure requests and configure acknowledgments in the log file until ppp(8) eventually gives up and closes the connection.

This normally happens on server machines with slow disks that are spawning a getty(8) on the port, and executing ppp(8) from a login script or program after login. There were reports of it happening consistently when using slirp. The reason is that in the time taken between getty(8) exiting and ppp(8) starting, the client-side ppp(8) starts sending Line Control Protocol (LCP) packets. Because ECHO is still switched on for the port on the server, the client ppp(8) sees these packets “reflect” back.

One part of the LCP negotiation is to establish a magic number for each side of the link so that “reflections” can be detected. The protocol says that when the peer tries to negotiate the same magic number, a NAK should be sent and a new magic number should be chosen. During the period that the server port has ECHO turned on, the client ppp(8) sends LCP packets, sees the same magic in the reflected packet and NAKs it. It also sees the NAK reflect (which also means ppp(8) must change its magic). This produces a potentially enormous number of magic number changes, all of which are happily piling into the server's tty buffer. As soon as ppp(8) starts on the server, it is flooded with magic number changes and almost immediately decides it has tried enough to negotiate LCP and gives up. Meanwhile, the client, who no longer sees the reflections, becomes happy just in time to see a hangup from the server.

This can be avoided by allowing the peer to start negotiating with the following line in your ppp.conf file:

set openmode passive

This tells ppp(8) to wait for the server to initiate LCP negotiations. Some servers however may never initiate negotiations. If this is the case, you can do something like:

set openmode active 3

This tells ppp(8) to be passive for 3 seconds, and then to start sending LCP requests. If the peer starts sending requests during this period, ppp(8) will immediately respond rather than waiting for the full 3 second period.

There is currently an implementation mis-feature in ppp(8) where it does not associate LCP, CCP & IPCP responses with their original requests. As a result, if one PPP implementation is more than 6 seconds slower than the other side, the other side will send two additional LCP configuration requests. This is fatal.

Consider two implementations, A and B. A starts sending LCP requests immediately after connecting and B takes 7 seconds to start. When B starts, A has sent 3 LCP REQs. We are assuming the line has ECHO switched off, otherwise we would see magic number problems as described in the previous section. B sends a REQ, then an ACK to the first of A's REQs. This results in A entering the OPENED state and sending and ACK (the first) back to B. In the meantime, B sends back two more ACKs in response to the two additional REQs sent by A before B started up. B then receives the first ACK from A and enters the OPENED state. A receives the second ACK from B and goes back to the REQ-SENT state, sending another (forth) REQ as per the RFC. It then receives the third ACK and enters the OPENED state. In the meantime, B receives the forth REQ from A, resulting in it reverting to the ACK-SENT state and sending another (second) REQ and (forth) ACK as per the RFC. A gets the REQ, goes into REQ-SENT and sends another REQ. It immediately receives the following ACK and enters OPENED.

This goes on until one side figures out that they are getting nowhere and gives up.

The best way to avoid this is to configure one side to be passive ── that is, make one side wait for the other to start negotiating. This can be done with the following command:

set openmode passive

Care should be taken with this option. You should also use the this command to limit the amount of time that ppp(8) waits for the peer to begin negotations:

set stopped N

Alternatively, the following command (where N is the number of seconds to wait before starting negotiations) can be used:

set openmode active N

Check the manual page for details.

When you execute the shell or ! command, ppp(8) executes a shell (or if you have passed any arguments, ppp(8) will execute those arguments). The ppp program will wait for the command to complete before continuing. If you attempt to use the PPP link while running the command, the link will appear to have frozen. This is because ppp(8) is waiting for the command to complete.

If you wish to execute commands like this, use the !bg command instead. This will execute the given command in the background, and ppp(8) can continue to service the link.

There is no way for ppp(8) to automatically determine that a direct connection has been dropped. This is due to the lines that are used in a null-modem serial cable. When using this sort of connection, LQR should always be enabled with the line

enable lqr

LQR is accepted by default if negotiated by the peer.

If ppp(8) is dialing unexpectedly, you must determine the cause, and set up Dial filters (dfilters) to prevent such dialing.

To determine the cause, use the following line:

set log +tcp/ip

This will log all traffic through the connection. The next time the line comes up unexpectedly, you will see the reason logged with a convenient timestamp next to it.

You can now disable dialing under these circumstances. Usually, this sort of problem arises due to DNS lookups. To prevent DNS lookups from establishing a connection (this will not prevent ppp(8) from passing the packets through an established connection), use the following:

set dfilter 1 deny udp src eq 53
set dfilter 2 deny udp dst eq 53
set dfilter 3 permit 0/0 0/0

This is not always suitable, as it will effectively break your demand-dial capabilities ── most programs will need a DNS lookup before doing any other network related things.

In the DNS case, you should try to determine what is actually trying to resolve a host name. A lot of the time, sendmail(8) is the culprit. You should make sure that you tell sendmail not to do any DNS lookups in its configuration file. See the section on using email with a dialup connection in the FreeBSD Handbook for details on how to create your own configuration file and what should go into it. You may also want to add the following line to your .mc file:

define(`confDELIVERY_MODE', `d')dnl

This will make sendmail queue everything until the queue is run (usually, sendmail is invoked with -bd -q30m, telling it to run the queue every 30 minutes) or until a sendmail -q is done (perhaps from your ppp.linkup file).

I keep seeing the following errors in my log file:

CCP: CcpSendConfigReq
CCP: Received Terminate Ack (1) state = Req-Sent (6)

This is because ppp(8) is trying to negotiate Predictor1 compression, and the peer does not want to negotiate any compression at all. The messages are harmless, but if you wish to remove them, you can disable Predictor1 compression locally too:

disable pred1

In order to log all lines of your modem “conversation”, you must enable the following:

set log +connect

This will make ppp(8) log everything up until the last requested “expect” string.

If you wish to see your connect speed and are using PAP or CHAP (and therefore do not have anything to “chat” after the CONNECT in the dial script ── no set login script), you must make sure that you instruct ppp(8) to “expect” the whole CONNECT line, something like this:

set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \
  \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n"

Here, we get our CONNECT, send nothing, then expect a line-feed, forcing ppp(8) to read the whole CONNECT response.

The ppp utility parses each line in your config files so that it can interpret strings such as set phone "123 456 789" correctly and realize that the number is actually only one argument. In order to specify a " character, you must escape it using a backslash (\).

When the chat interpreter parses each argument, it re-interprets the argument in order to find any special escape sequences such as \P or \T (see the manual page). As a result of this double-parsing, you must remember to use the correct number of escapes.

If you wish to actually send a \ character to (say) your modem, you would need something like:

set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK"

It will result in the following sequence:

ATZ
OK
AT\X
OK

Or:

set phone 1234567
set dial "\"\" ATZ OK ATDT\\T"

It will result in the following sequence:

ATZ
OK
ATDT1234567

The ppp utility (or any other program for that matter) should never dump core. Because ppp(8) runs with an effective user ID of 0, the operating system will not write core image of ppp(8) to disk before terminating it. If, however ppp(8) is actually terminating due to a segmentation violation or some other signal that normally causes core to be dumped, and you are sure you are using the latest version (see the start of this section), then you should install the system sources and do the following:

#  cd /usr/src/usr.sbin/ppp
# echo STRIP= >> /etc/make.conf
# echo CFLAGS+=-g >> /etc/make.conf
# make install clean

You will now have a debuggable version of ppp(8) installed. You will have to be root to run ppp(8) as all of its privileges have been revoked. When you start ppp(8), take a careful note of what your current directory was at the time.

Now, if and when ppp(8) receives the segmentation violation, it will dump a core file called ppp.core. You should then do the following:

% su
# gdb /usr/sbin/ppp ppp.core
(gdb) bt
.....
(gdb) f 0
....
(gdb) i args
....
(gdb) l
.....

All of this information should be given alongside your question, making it possible to diagnose the problem.

If you are familiar with gdb(1), you may wish to find out some other bits and pieces such as what actually caused the dump or the addresses and values of the relevant variables.

This was a known problem with ppp(8) set up to negotiate a dynamic local IP number with the peer in -auto mode. It has been fixed a long time ago ── search the manual page for iface.

The problem was that when that initial program calls connect(2), the IP number of the tun(4) interface is assigned to the socket endpoint. The kernel creates the first outgoing packet and writes it to the tun(4) device. ppp(8) then reads the packet and establishes a connection. If, as a result of ppp(8)'s dynamic IP assignment, the interface address is changed, the original socket endpoint will be invalid. Any subsequent packets sent to the peer will usually be dropped. Even if they are not, any responses will not route back to the originating machine as the IP number is no longer owned by that machine.

There are several theoretical ways to approach this problem. It would be nicest if the peer would re-assign the same IP number if possible. The current version of ppp(8) does this, but most other implementations do not.

The easiest method from our side would be to never change the tun(4) interface IP number, but instead to change all outgoing packets so that the source IP number is changed from the interface IP to the negotiated IP on the fly. This is essentially what the iface-alias option in the latest version of ppp(8) is doing (with the help of libalias(3) and ppp(8)'s -nat switch) ── it is maintaining all previous interface addresses and NATing them to the last negotiated address.

Another alternative (and probably the most reliable) would be to implement a system call that changes all bound sockets from one IP to another. ppp(8) would use this call to modify the sockets of all existing programs when a new IP number is negotiated. The same system call could be used by DHCP clients when they are forced to call the bind() function for their sockets.

Yet another possibility is to allow an interface to be brought up without an IP number. Outgoing packets would be given an IP number of 255.255.255.255 up until the first SIOCAIFADDR ioctl(2) is done. This would result in fully binding the socket. It would be up to ppp(8) to change the source IP number, but only if it is set to 255.255.255.255, and only the IP number and IP checksum would need to change. This, however is a bit of a hack as the kernel would be sending bad packets to an improperly configured interface, on the assumption that some other mechanism is capable of fixing things retrospectively.

The reason games and the like do not work when libalias(3) is in use is that the machine on the outside will try to open a connection or send (unsolicited) UDP packets to the machine on the inside. The NAT software does not know that it should send these packets to the interior machine.

To make things work, make sure that the only thing running is the software that you are having problems with, then either run tcpdump(1) on the tun(4) interface of the gateway or enable ppp(8) TCP/IP logging (set log +tcp/ip) on the gateway.

When you start the offending software, you should see packets passing through the gateway machine. When something comes back from the outside, it will be dropped (that is the problem). Note the port number of these packets then shut down the offending software. Do this a few times to see if the port numbers are consistent. If they are, then the following line in the relevant section of /etc/ppp/ppp.conf will make the software functional:

nat port proto internalmachine:port port

where proto is either tcp or udp, internalmachine is the machine that you want the packets to be sent to and port is the destination port number of the packets.

You will not be able to use the software on other machines without changing the above command, and running the software on two internal machines at the same time is out of the question ── after all, the outside world is seeing your entire internal network as being just a single machine.

If the port numbers are not consistent, there are three more options:

1. Submit support in libalias(3). Examples of “special cases” can be found in /usr/src/sys/netinet/libalias/alias_*.c (alias_ftp.c is a good prototype). This usually involves reading certain recognised outgoing packets, identifying the instruction that tells the outside machine to initiate a connection back to the internal machine on a specific (random) port and setting up a “route” in the alias table so that the subsequent packets know where to go.

   This is the most difficult solution, but it is the best and will make the software work with multiple machines.

2. Use a proxy. The application may support socks5 for example, or (as in the cvsup case) may have a “passive” option that avoids ever requesting that the peer open connections back to the local machine.

3. Redirect everything to the internal machine using nat addr. This is the sledge-hammer approach.

Not yet, but this is intended to grow into such a list (if any interest is shown). In each example, internal should be replaced with the IP number of the machine playing the game.

• Asheron's Call

  nat port udp internal :65000 65000

  Manually change the port number within the game to 65000. If you have got a number of machines that you wish to play on assign a unique port number for each (i.e. 65001, 65002, etc) and add a nat port line for each one.

• Half Life

  nat port udp internal:27005 27015

• PCAnywhere 8.0

  nat port udp internal:5632 5632

  nat port tcp internal:5631 5631

• Quake

  nat port udp internal:6112 6112

• Quake 2

  nat port udp internal:27901 27910

  nat port udp internal:60021 60021

  nat port udp internal:60040 60040

• Red Alert

  nat port udp internal:8675 8675

  nat port udp internal:5009 5009

FCS stands for Frame Check Sequence. Each PPP packet has a checksum attached to ensure that the data being received is the data being sent. If the FCS of an incoming packet is incorrect, the packet is dropped and the HDLC FCS count is increased. The HDLC error values can be displayed using the show hdlc command.

If your link is bad (or if your serial driver is dropping packets), you will see the occasional FCS error. This is not usually worth worrying about although it does slow down the compression protocols substantially. If you have an external modem, make sure your cable is properly shielded from interference - this may eradicate the problem.

If your link freezes as soon as you have connected and you see a large number of FCS errors, this may be because your link is not 8-bit clean. Make sure your modem is not using software flow control (XON/XOFF). If your datalink must use software flow control, use the command set accmap 0x000a0000 to tell ppp(8) to escape the ^Q and ^S characters.

Another reason for seeing too many FCS errors may be that the remote end has stopped talking PPP. You may want to enable async logging at this point to determine if the incoming data is actually a login or shell prompt. If you have a shell prompt at the remote end, it is possible to terminate ppp(8) without dropping the line by using the close lcp command (a following term command) will reconnect you to the shell on the remote machine.

If nothing in your log file indicates why the link might have been terminated, you should ask the remote administrator (your ISP?) why the session was terminated.

Thanks to Michael Wozniak <mwozniak@netcom.ca> for figuring this out and Dan Flemming <danflemming@mac.com> for the Mac solution:

This is due to what is called a “Black Hole” router. Mac OS and Windows 98 (and maybe other Microsoft OSs) send TCP packets with a requested segment size too big to fit into a PPPoE frame (MTU is 1500 by default for Ethernet) and have the “do not fragment” bit set (default of TCP) and the Telco router is not sending ICMP “must fragment” back to the WWW site you are trying to load. (Alternatively, the router is sending the ICMP packet correctly, but the firewall at the WWW site is dropping it.) When the www server is sending you frames that do not fit into the PPPoE pipe the Telco router drops them on the floor and your page does not load (some pages/graphics do as they are smaller than a MSS.) This seems to be the default of most Telco PPPoE configurations.

One fix is to use regedit on your 95/98 system to add the following registry entry:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\NetTrans\0000\MaxMTU

It should be a string with a value 1436, as some ADSL routers are reported to be unable to deal with packets larger than this. This registry key has been changed to Tcpip\Parameters\Interfaces\ID for adapter\MTU in Windows 2000 and becomes a DWORD.

Refer to the Microsoft Knowledge Base documents Q158474 - Windows TCPIP Registry Entries and Q120642 - TCPIP & NBT Configuration Parameters for Windows NT for more information on changing Windows MTU to work with a NAT router.

Another regedit possibility under Windows 2000 to set the Tcpip\Parameters\Interfaces\ID for adapter\EnablePMTUBHDetect DWORD to 1 as mentioned in the Microsoft document 120642 mentioned above.

Unfortunately, Mac OS does not provide an interface for changing TCP/IP settings. However, there many commercial software available that will allow users to customize TCP/IP settings. Mac OS NAT users should search for their MTU settings and enter 1450 instead of 1500.

The ppp(8) has an enable tcpmssfixup command that will automatically adjust the MSS to an appropriate value. This facility is enabled by default. If you are stuck with an older version of ppp(8), you may want to look at the net/tcpmssd port.

If all else fails, send as much information as you can, including your config files, how you are starting ppp(8), the relevant parts of your log file and the output of the netstat -rn command (before and after connecting) to the FreeBSD 一般问题邮件列表 or the comp.unix.bsd.freebsd.misc news group, and someone should point you in the right direction.

在 FreeBSD 内核引导过程中， 它会根据配置去探测系统中的串口。 您可以在系统启动时观察， 或在系统完全启动之后运行下面的命令：

% dmesg | grep -E "^sio[0-9]"

下面是上述命令常见的输出结果：

sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
sio0: type 16550A
sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A

上面显示了两个串口。 第一个在 IRQ 4 上， 正在使用的端口地址 0x3f8， 为 16550A 类型的 UART 芯片。 第二块使用同样类型的芯片但是使用 IRQ 3 端口地址为 0x2f8。 内置调制解调器按串口方式处理 ── 除非始终有一个调制解调器“连接” 在端口上。

GENERIC kernel 支持上例中的两个串口使用相同 IRQ 和端口地址。 如果这样设置在你的系统上显示不正确， 可能是你增加了调制解调器卡， 或者你使用比在 kernel 上配置的更多的端口， 那么你重新配置一下 kernel 就可以了。 可以查看 关于创建 kernel 以获取更多细节.

请查阅前一问题的相关解答.

第三个串口, sio2 (查看 sio(4), 就像在DOS下的 COM3 一样), 在 /dev/cuad2 上有拨出设备, 同时在 /dev/ttyd2 上有拨入 设备. 这两类设备有什么区别吗?

你使用 ttydX 来拨入. 当打开设备 /dev/ttydX 使它处于阻塞模式时, 一个进程将等待 相应的设备 cuadX 改变为非激活态, 然后等待载波检测线路变为激活态. 当你打开设备, cuadX 它将确认串口是否已经被设备 ttydX 使用. 如果端口可用, 它将 “获取” 该端口, 通过设备 ttydX 进行该端口的获取. 同样, 设备 cuadX 并不在意载波检测. 通过这种方式和一个自动应答调制解调器, 你可以实现 远程用户登录,在该远程登录过程的同时还可以用同一个调制解调器拨出号码, 由系统来处理该冲突.

再次强调， 关于内核配置的部分提供了与之相关的信息。 对于多端口串口卡， 您可能需要为卡上的每个 sio(4) 设备在 device.hints(5) 文件中进行对应的配置。 不过， 只需要在其中的一项上指定 IRQ。 卡上的所有端口会共享同一个 IRQ。 出于一致性的考虑， 请使用最后一个串口来指定 IRQ。 此外， 您应在内核的联编配置中加入下列选项：

options COM_MULTIPORT

下面的 /boot/device.hints 例子用于 AST 4-端口串口卡， 使用 IRQ 12：

hint.sio.4.at="isa"
hint.sio.4.port="0x2a0"
hint.sio.4.flags="0x701"
hint.sio.5.at="isa"
hint.sio.5.port="0x2a8"
hint.sio.5.flags="0x701"
hint.sio.6.at="isa"
hint.sio.6.port="0x2b0"
hint.sio.6.flags="0x701"
hint.sio.7.at="isa"
hint.sio.7.port="0x2b8"
hint.sio.7.flags="0x701"
hint.sio.7.irq="12"

这些标志表示主端口的 minor 编号是 7 (0x700)， 而所有的端口共享 IRQ (0x001)。

尚不可以。 您必须为每一个多端口卡配置不同的 IRQ。

请参见 FreeBSD 使用手册中的 串口通讯 部分。

请参见 FreeBSD 使用手册中的 拨入服务 部分。

请参见 FreeBSD 使用手册中的 终端 部分。

在您的系统上， tip(1) 和 cu(1) 这两个程序可能只能通过以 uucp 用户和 dialer 组身份运行时才能访问 /var/spool/lock 目录。 您可以通过 dialer 组来控制谁可以访问您的调制解调器或远程系统。 例如， 您可以只将自己加入到 dialer 组中。

你可以让在你系统上的每一个用户运行 tip(1) 和 cu(1) 通过键入如下命令的方式来执行:

# chmod 4511 /usr/bin/cu
# chmod 4511 /usr/bin/tip

请参阅 FreeBSD 使用手册中的 这个答案。

请参阅 FreeBSD 使用手册中的 这个答案。

请参阅 FreeBSD 使用手册中的 这个答案。

请参阅 FreeBSD 使用手册中的 这个答案。