分类：
2008-04-08 16:36:36
本章介绍几种用于安装 ON 位的灵活方法。请注意，由于 ON 不包含工作系统所需的全部程序，因此您只有在已经进行了完全安装（通常为 Solaris 或 Solaris Express）后，才能成功执行这些过程。
此外，还介绍了内核和 userland 核心组件的一些常用测试过程。虽然这些测试旨在尽可能多地检测系统的各个方面，并提供充分的灵活性以便可将附加测试写入和添加到基础结构，但大多数测试仍由特定于项目的测试套件完成。修复错误或添加新功能时，最好与将更改的代码的属主联系以获取任何现有测试。另外，还应提供新的测试（代码），用于检测需要 修复的错误或检验新功能。
除了手动将特定文件从原始区域复制到实时系统外，在系统中安装位还有三种主要方法。具体使用哪种方法将取决于所更改的内容：如果仅更改了内核，请参见第5.1.1了解有关Install的信息。如果更改了内核和 ON 的 userland 组件，并且必须同时应用更改，则必须在使用Install前手动复制userland更改的内容或用BFU，有 关BFU信息，请参见第 5.3 节。
为了能够在即使缺少某些源代码的情况下也可以进行完全功能生成，已提供一组不公开的二进制代码，并已将生成系统修改为可以利用这些二进制代码。您需要将 closed-bins.
在这些安装方法中，每一种方法都越来越复杂并且耗时，但可升级大部分系统。由于大多数 ON 开发者仅修改 ON 源文件，并且不负责集成测试，因此 BFU 是目前为止最常用的系统升级方法。专注于内核开发的开发者通常会在开发过程中利用 Install，并会使用 BFU 在测试阶段之间保持内核继续运行。
本节简要介绍了每一种方法。有关详细说明，请参见第 5.2 节和第 5.3 节。
Install（发音为 cap-eye-install）用于仅更新内核及其在特定系统上的关联模块。该方法将新内核放在非标准位置，并仅安装适合特定主机的特定于平台的模块。通过该方法，可以测试更改而无需删除标准内核；如果新内核未引导或崩溃，则很容易恢复。
BFU 用于更新所有 ON 位（包括内核和 userland）。该方法能够更新某些配置文件，并了解对 ON 所做更改的影响。BFU比Install更全面，且 所需时间更长。另外，与 Install 不同，新内核将安装在现有内核上，因此如果其没有正常工作，则可能必须从备用介质引导以便恢复。
在某些情况下，需要首先安装一个或多个较新版本的系统软件包，然后才能使用新版本的 ON 位。如果出现这种情况，则称为标志日期。标志日期通知发布在 中，并 且包含用于生成和/或安装所需的较新版本软件的说明。需要注意的是，无法保证此安装过程与标准打包工具（如 pkgadd(1M)）正常交互操作。特别是，使用 BFU（请参见第 4.1.4 节）或临时替换 Solaris 组件意味着，无法再使用 Solaris 软件包更新这些组件。如果要考虑这种情况，则建议您以独占方式使用 Solaris Express 来管理系统软件包安装，并在生成最新的 Express 时仅对最新的源代码树进行生成和测试。您可以
首先，必须具有容纳生成的内核的 工作区。如果需要更多有关生成内核的信息，请参见第 4 章（尤其是第 4.3 节）。生成内核后，需要使用 Install 命令生成 Install tarball。
Install(1) 实用程序创建的 tar 文件可以提取到相应计算机的根目录中。该实用程序利用生成的现有内核树和内核 makefile 来确定 tar 文件的正确内容。有关完整的选项列表，请参见 Install(1) 或 'Install -h' 的输出；此处仅介绍了最常用的选项。
通过 Install 构造的 tar 文件特定于体系结构，如 sun4u 或 i86pc。指定要使用 Install 为其创建归档文件的体系结构的方法有两种。第一种方法是在运行 Install 时处于体系结构的子目录中 (usr/src/uts/
通常使用 -G 选项指定的另一种设置是 ``glomname''。这是 /platform/
简单的 Install 调用如下所示：
$ Install -G kernel.foo -k sun4u
... lots of spew ...
Creating tarfile /tmp/Install.username/Install.sun4u.tar
Install complete
现在，可将 /tmp/Install.username/Install.sun4u.tar 复制到测试计算机，然后在根目录中将其提取。提取时最好使用 '-o' 选项，以便文件拥有权正确。& amp; lt; /p>
在包含第 14 版或更新版本的 x86 上，需要首先将内核添加到引导归档文件中，然后才能引导。为此，请将以下行：
platform/i86pc/kernel.foo
添加到 /boot/solaris/filelist.ramdisk，其中 kernel.foo 是 glomname（ -G 的参数）。此要求已在第 18 版和更新版本中消除，并且不适用于 SPARC。
安装内核后，请通过运行以下命令来重新引导测试计算机，并使其使用新内核：
(SPARC)
# reboot -- 'kernel.foo/sparcv9/unix'
(AMD64)
# reboot -- 'kernel.foo/amd64/unix'
(x86)
# reboot -- 'kernel.foo/unix'
请注意，在每次希望引导测试内核时都需要使用此重新引导语法，或使用 bootloader 或 OBP 的类似参数。否则，将会引导通过 BFU 或正常安装而安装的标准内核。
尽管 Install 适用于仅更改了内核代码的开发者，但对其他人员则作用不大。特别是，如果最新的标志日期通知表明较新的内核与现有的 userland 库或命令不兼容，则在通过 BFU 或其他某些机制（如正常安装或升级过程）升级 userland 之前，无法使用 Install 来测试已更新的内核。
与 bfu 类似（请参见第 5.3 节），Install 是与其特定发行版紧密关联的，因此应使用 门中与要生成的发行版匹配的当前版本。通常，这位于该门的 public/bin 子目录中；但是，对于 Sun 外部的安装，则位于 /opt/onbld/bin 中。
Install 用户安装正确的特定于平台的模块集非常关键，尤其是在 SPARC 系统中。否则，可能会导致系统无法引导。有关特定于平台的模块如何与 Install 关联的更多信息，请参见下面的第 5.2.2 节。
基于 BFU 的 Install 的一个主要优点是能够保持现有内核，从而在测试内核证实中毒时仍可引导。如果您使用 Install 测试内核，则强烈建议您利用此功能，并对测试的每个新内核使用不同的位置（请参见以上第 5.2.1 节中所述的 -G 选项）。否则，可能必须从备用介质引导，以便在安装错误内核后修复系统。
通常，Install 不会生成包含特定于实现的模块的归档文件。如果将这些归档文件安装到需要所缺少模块的系统，则系统可能无法引导或正常工作。如果执行此操作，则需要从一个已知的工作内核进行引导，从而更正该问题。
问题症状示例 (Enterprise 3500)：
SunOS Release on81 Version jrhyason_[ws-vmstat]_05/15/01 64-bit
Copyright 1983-2001 Sun Microsystems, Inc. All rights
reserved.
DEBUG enabled
obpsym:symbolic debugging is available.
Read 297063 bytes from misc/forthdebug
WARNING:consconfig:consconfig_util_openvp failed:err 6 vnode
0x2803c80
WARNING:consconfig:consconfig_util_link I_PLINK failed:error
22
configuring IPv4 interfaces:hme0
...
未显示控制台！
要在 Install tarball 中包含所需模块，请确保使用
$ Install -i
来包含特定于实现的模块。但是，如何知道所需要的 sun4u 实现呢？首先，从 'uname -i' 输出中获取计算机的“正式”实现名称。然后，在 usr/src/uts/sun4u 中运行 ``grep IMPLEMENTED_PLATFORM */Make*''，以查看 uname(1) 报告的实现列表和对应的平台名称。
在以上示例中，E3500 将报告如下信息：
$ uname -i
SUNW,Ultra-Enterprise
并且从 grep 输出中看到：
$ grep IMPLEMENTED_PLATFORM */Make*
...
sunfire/Makefile:IMPLEMENTED_PLATFORM =
SUNW,Ultra-Enterprise
...
在这种情况下，必须添加 ``-i sunfire'' 参数才能获得正确的行为。
此外，最易使 Install wads 出错的一种方法是因为并非所有驱动程序均通过 ON 传送。对于 x86，这种情况尤其明显，但是对于 SPARC 也会出现这种情况，尤其是帧缓冲区驱动程序。解 决此问题的一种方法是执行以下命令：
# cd /platform/{sun4u,i86pc}
# mkdir glomname
# (cd kernel; tar cf - .) | (cd glomname; tar xf -)
然后安装 Install glom 映像。这会将现有驱动程序复制到新内核安装中，从而确保不属于 ON（或整个 OpenSolaris）的驱动程序在重新引导时可用。
模糊快速升级 (Blindingly Fast Upgrade, BFU) 或 Bonwick-Faulkner 升级是一个进程，用于更新系统上的 ON 位。普通的 Solaris 升级过程需要完整的 WOS，并且至少需要 30 分钟（通常会更长）。为节省时间，BFU 使用一组 cpio(1) 归档文件来直接覆写系统的现有内容。 BFU 完成运行需要的时间一般不到 10 分钟，如果从最新内部版本升级，则冲突解决方案通常只需要几分钟。使用 BFU 一年后，可节省大量开发时间。
为了使用 BFU，首先需要设置三个附加环境变量。您可以在登录点文件或命令行中设置这些变量。如果您愿意，也可以为 bfu(1) 创建一个本地包装，以首先设置这些变量。这些环境变量如下：
此变量通常应设置为 /opt/onbld/bin/`uname -p`/fastfs。
此变量通常应设置为 /opt/onbld/bin/`uname -p`/bfuld。
此变量通常应设置为 /usr/bin/gzip。
BFU 使用简单，通常仅接受一个参数，即要安装的归档文件集的路径。例如，如果 工作区位于 /home/jdoe/workspace 中，并且已完成 nightly(1) 生成，则可按如下方式调用 bfu(1)：
# bfu /home/jdoe/workspace/archives/`uname -p`/nightly
请注意，由于 bfu(1) 会修改系统软件安装，因此必须始终以超级用户身份来运行它。
当 bfu 完成时，无法保证新命令和库与当前运行的（旧）内核兼容。因此，无需退出，bfu 便可将您置入 PATH=/tmp/bfubin 和 LD_LIBRARY_PATH=/tmp/bfulib 的子 shell 中。这些目录包含解决冲突和重新引导系统通常所需的旧版本命令和库。这些目录也已进行了修改，以便用于保存的旧动态链接程序的副本。& amp; lt; /p>
请注意，您可能会从 BFU 收到有关无法从 ``greenline.eng'' 或其他系统或位置复制文件的警告。通常，这些警告应作为错误进行报告。但是，出现这些警告时，如果在尝试执行 BFU 之前系统运行的版本不低于 Solaris 10 build 74，则这些警告是无害的。有关任何附加要求和限制，请参见最新的发行说明。
虽然 BFU 可节省时间，但并不能解决所有问题。本节包含有关 BFU 缺点的信息。您应仔细评估这些优缺点，然后确定 BFU 是否适合您的需要。通常，如果您不是当前开发者，则建议您不要使用 BFU。
BFU 不会更新软件包信息。因此，在已执行 BFU 的系统上，很可能无法安装正式的 Solaris 修补程序，或运行完整的系统升级过程。这一点的重要性无论如何强调都不为过： 如果对系统执行BFU，则将来不要尝试使用 “常规”系统管理步骤进行更新。请使用BFU 或REINSTALL。
即使需要非 ON 软件包的更新版本以成功安装或运行安装的 ON 版本，BFU 也不会更新这些软件包。在执行 BFU 前后，可能需要更新这些软件包。要 了解可能需要的软件包更新，请参阅 ，以获取当前运行的内部版本和希望执行 BFU 的内部版本之间的标志日期完整列表。每个标志日期通知都会指示需要的软件包更新（如果有），以及是必须在执行 BFU 之前还是之后完成更新。在执行 BFU 之前阅读、理解并严格遵循这些说明非常关键。否则，很可能会 破坏您的系统。有关标志日期的更多信息，请参见第 5.1.3 节。
虽然 BFU 的核心功能由将 cpio(1) 归档文件解压缩到当前运行系统的简单活动组成，但是 BFU 也执行许多与系统更新相关的其他任务。其中很多任务特定于几年来在源文件中所做的特定更改。如果系统特征异常，则这些附加更新可能会失败，从而导致系统无 法正常运行。由于这些更新差异很大，因此无法预知哪些更新会失败，或可能出现哪种故障模式。尽管此类故障非常少见，但也可能会发生。如果用BFU，则应追 踪 ON 的开发情况，以了解所做的可能对系统产生不利影响的更改。如果您不确定 BFU 如何根据对 ON 的主要更改更新系统的特定方面，请阅读 bfu(1) 并咨询进行此更改的工程师。
bfu 完成后，它将使用受限制的 PATH 调用 ksh。PATH 包含的程序已经过专门修改，以便在不考虑 BFU 归档文件可能包含的更改的情况下运行。您可以使用这些程序解决冲突（请参见第 5.3.2 节）。特别是，``reboot'' 运行，但 ``init 6'' 不运行。如果需要，可以退出该受保护环境，但是建议不要退出，除非您确信自上次执行 bfu 后尚无任何“标志日期”（同步内核 /userland 更改）。
决不要在窗口中执行 BFU；请始终使用系统控制台。如果 BFU 或系统在中途崩溃，或者在使用窗口系统时崩溃或挂起，则系统将处于不一致的状态。您可能会无法引导。因此，您应在启动 BFU 之前尽可能确保系统处于停顿状态，并且确保在必要时可随时安装适当的系统软件介质副本。
决不要对生产系统执行 BFU。应始终使用支持的升级机制将生产系统更新至已批准的发行版。
每台计算机均有几个配置文件，它们通过缺省安装进行修改；bfu 保留了这些文件的列表。此列表称为冲突数据库。
BFU 在 /bfu.child 中保存将覆写的各配置文件的副本；同样，它还将提取的 cpio 归档文件中的所有此类文件副本存储在 /bfu.parent 中，并将上一个 BFU 的 /bfu.parent（如果有）移至 /bfu.ancestor。我们将这些目录中保存的文件分别称为子文件、父文件和祖先文件。
完成提取后，BFU 将区分这些配置文件的各个版本，并根据以下规则执行操作：
* 如果文件未更改（即子文件和父文件没有差别），则不执行任何操作或报告任何内容。
* 如果文件是从上次运行的父文件接受的（即子文件与祖先文件相同），则此时会自动接受父文件；此类文件被标记为“更新：”。
* 如果文件与上一个文件的开头相同，则假定用户已在文件末尾添加了行（即子文件由父文件加上添加的部分行组成）；子文件版本将会恢复；此类文件被标记为“恢复：”。
* 如果父文件和子文件不同，但父文件和祖先文件相同，则视为旧冲突；此类文件被标记为“旧：”。
* 最后，如果父文件和子文件不同，父文件和祖先文件也不同，则视为新冲突；此类文件被标记为“新：”。
至此，我们已了解新冲突意味着某文件已和缺省文件不同，其中缺省文件已被更新。要解决这种差别，必须将新内部版本中引入的任何更改都导入到系统中的现有文件。
虽然有可能会盲目接受父文件，但这样将导致子文件中的任何自定义内容丢失。由于对于这些文件，通过非 ON 软件包的类操作脚本自动进行此类自定义非常普遍，因此这通常是错误的，可能会导致数小时的效率损失。为此，提供了两种形式的冲突解决方案，如 以下两节中所述。这两种方案是自动冲突解决方案和手动冲突解决方案。
如果选择手动解决冲突，或者如果自动工具无法解决所有冲突，则采取正确的 BFU 基准安装将非常有用。要建立此类基准，应在安装后立即安装与分发对应的 BFU 归档文件。强烈建议您只有在安装足够新并且此 BFU 归档文件可用时，才开始此过程。特别是， 对版本低于 Solaris 11 build 16 的系统执行 BFU 将会失败，并可能使系统无法引导。
如果对与分发中包含的内部版本相同的内部版本执行 BFU，则可以忽略所有冲突，因为已知现有已安装的配置文件可针对此内部版本正常工作。然后，您必须在对较新的内部版本执行 BFU 之前重新引导。& amp; lt; /p>
自动冲突解决方案由称为 acr 的脚本执行。此脚本位于 ON 工作区的 /opt/onbld/bin 和 usr/src/tools/scripts 目录中。在 usr/src/tools/scripts 目录中，如果使用 -t 选项进行 nightly(1) 生成，则由 acr.sh 生成 acr 可执行文件。在 ON 工作区的 /opt/onbld/man/man1 和 usr/src/tools/scripts 目录中，包含手册页 acr.1。& lt; /p>
使用 acr 的标准方法是在执行 BFU 后仍处于受保护环境中时调用它。在此模式下，无需指定任何命令行参数。
对于更专用的应用程序，acr 可接受一个或两个参数。第一个参数是备用根目录的名称。第二个参数（如果指定）是包含归档文件的目录的名称。
acr 使用一个称为 conflict_resolution.gz 的文件，该文件位于包含 BFU cpio 归档文件的目录中。只要 nightly(1) 创建归档文件，就会构造此冲突解决文件。也即是说，只要 nightly(1) 使用 -a 选项运行。
当 acr 运行时，将会列出要处理为标准输出的文件。详细结果将写入 /tmp 子目录中一个称为 allresults 的文件中。acr 退出后，将会列显该 allresults 文件的全路径名。要确保在 acr 处理过程中不出现任何错误，应检查该 allresults 文件。如 果出现了错误，则需要采用手动冲突解决方案，如下节中所述。
手动冲突解决方案要求您手动解决每个冲突。解决冲突的一般方法是：
% diff /bfu.ancestor/$file /bfu.parent/$file
然后将差异手动应用到 /$file。请注意，如果以前尚未执行 BFU，则不会具有 /bfu.ancestor，因此，如果已建立上述基准，您就会发现手动冲突解决方案更容易。对于许多文件，可以使用快捷方式。BFU 在完成后可用于访问 /bfu.conflicts，并且大多数更改都是增加或修改，因此执行以下命令：
% diff $file /$file
并确保差异均指向右侧（即 ``>'' 而不是 ``<''）就会达到目的。但是，这并不适用于所有情况；下面详细说明了一些值得注意的例外文件。
etc/name_to_major
此文件将设备名称与主设备号进行匹配；每个设备都具有唯一的主设备号非常关键。最好从一开始就区分祖先文件和父文件－只需记住该名称很重要，而主设 备号可能会有所变化。应该删除父文件中已删除的旧设备，但 是如果您不确定，则也可以将其保留，因为它们通常是无害的。应为新设备添加未使用过的主设备号 （如果可用，请从差异中选择一个编号）。决不能更改现有项的编号，除非您确实了解所进行的操作。如果您不确定所更改的内容，则可直接参阅 工作区中文件的历史记录（如 usr/src/uts/{intel|sparc}/os/name_to_major）。
完成之后，就可以通过运行以下命令对更改进行健全性检查：
% sort -k1,1 /etc/name_to_major | sort -uc -k1,1
% sort -k2n /etc/name_to_major | sort -uc -k2n
这些命令将分别报告第一个重复的设备名称和重复的最小主设备号。任何一个命令都会指示在重新引导前必须更正的问题。如果没有输出，则表示已全部设置。请注意，在重新引导后内核也会就此类冲突向您发出警告，但 是可能已为时太晚。
etc/security/*_attr
类操作脚本通常会将这些文件无序放置，因此父文件和子文件版本可能会差异很大。对于这些文件，上述快捷方式无效，但是如果祖先文件与父文件的差异较为普通，则适合使用快捷方式。
通常，仅需检查新冲突。
创建区域时，各区域的内容是从全局区域复制的。为确保所有区域在执行 BFU 后仍可操作，必须使区域内容与全局区域中的内容保持一致。为此，在更新全局区域后，BFU 将依次更新各区域；但是，由于各区域的配置文件可能与全局区域的配置文件不同，因此各区域都具有各自的 BFU 冲突管理目录。不过，无法仅对单个区域执行 BFU。BFU 将影响整个系统，包括所有区域。如果要测试某区域中用户空间的更改，则需要将文件从原始区域中手动复制到该区域。
在对系统执行 BFU 之前，最好关闭所有区域。这将确保可能安装的文件违反的相关性不会破坏区域。
在对包含全局区域以外的区域的系统执行 BFU 后，首先需要解决全局区域的冲突，然后解决其余区域的冲突，最后才能重新引导系统。解决区域中BFU冲突的方式与针对全局区域冲突解决方式完全相同，但在很多情况下不需要手动合并文件内容。相反，您可能会发现文件应与全局区域中的文件相同，并且只需将其复制即可。解决所有区域中的冲突后，必须重新引 导系统，然后才能重新引导任一区域。
Sun 具有许多用于 ON 的测试套件。不过，这些套件尚不可用；请检查 中的汇总信息。