分析 Solaris 操作系统中的 patchadd 或 patchrm 故障
Enda O'Connor，2009 年 4 月
本文介绍了下列主题：
注意 ：本文包含对一些仅适用于 Solaris 10 操作系统的项目（例如，新的 bootblk）的引用。本文的其余部分以及随附的脚本均适用于 Solaris 8、Solaris 9 或 Solaris 10 操作系统。
在开始分析 patchadd 和 patchrm 会话未成功的根本原因之前，请务必收集足够的信息。本文档能够帮助 SPARC 或 x86 平台的 Solaris 操作系统用户执行此操作。本文档集中讨论了当经过修补的系统未正常重新引导，即系统进入循环状态或进入 OK 提示符（针对用于 SPARC 平台的 Solaris 操作系统）时应该怎么做。
本文概括了哪些文件的相关程度最高，从哪里找到这些文件，以及（根据用于应用修补程序的自动修补工具（如果有））从哪里找到这些工具的任何相关输出。因为与修补相关的问题可能有很多原因，所以本文档的主要目的并非是帮助进行实际故障分析，而是提供了一些通用的指导。
如果系统在重新引导后，无法回到所需的运行级别，或无法引导进入维护模式（即，如果系统进入 OK 提示符或进入循环状态），则必须首先从网络或 CD-ROM 引导系统并装入相关的文件系统，然后才能访问系统。
{1} ok
a. 首先，尝试捕获从系统开始重新引导到显示 OK 提示符期间的相关控制台输出。保存此输出，因为它可能对诊断实际的故障非常有用。
b. 此时，尝试确认是否可以不用通过从网络或介质引导（与从磁盘引导相对而言）而将问题解决。
c. 如果需要从介质引导到单用户模式并装入根文件系统，则有以下两个选项：
要从网络引导，请确保在引导服务器中正确配置了客户端，并且网络连接和配置无误（此非本文档讨论范围）。然后运行以下命令：
{1} ok boot net -s
要从 CD-ROM 引导，请运行以下命令:
{1} ok boot cdrom -s
a. 首先尝试从控制台捕获完整的故障输出。
b. 然后，对于 SPARC 系统，请进入 OK 提示符，并按照上面步骤 1 中的说明进行操作。
对于 x86 系统，您需要确保 BIOS 引导优先级允许系统先从网络或 CD-ROM 引导，而不是从硬盘引导。如果执行的是网络引导，请确保在引导服务器中正确配置了客户端。例如，如果您使用的是 DHCP，请确保客户端网络连接和配置无误；如果使用的是 NIS，请确保在 NIS 服务器中正确设置了客户端。
3. 在系统从 CD-ROM 或网络引导后，请按照 BigAdmin 文章 How to Remove a Solaris OS Patch While Booted From a Network or CD-ROM （在从网络或 CD-ROM 引导后，如何删除 Solaris 操作系统修补程序）中的说明装入所有要检查的相关文件系统。
在此阶段，我们将假定上面步骤 2 中的所有任务已经完成，并且已经在 /a 下装入系统。
注意 ：以下大多数数据是由 patchanalysis_gather.txt 脚本收集的，到终端的实际 patchadd 输出除外。这是 patchanalysis_gather.txt 脚本文件的源代码 。
1. 收集与 patchadd 和 patchrm 相关的日志文件。
如果仅通过 patchadd 实用程序完成 patchadd 会话，则只有将 pachadd 输出捕获到日志文件中，才可检索该数据。如果输出仍可用，可能只需从终端或控制台剪切并粘贴 patchadd 输出。请注意，您需要来自 patchadd 命令本身的实际输出 (STDOUT/STDERR)，而非 /var/sadm/patch/ 中由 patchadd 生成的日志文件。
强烈建议在修补过程中将所有的 patchadd 输出重定向到一个文件中，这样在以后需要检查时，就可以很容易检索输出。
例如，以下命令将 patchadd 的输出定向到一个日志文件中：
patchadd <PatchID> 2>&1|tee /opt/patchlogs/118833-36.$$
2. 在下面的示例中，我们将使用 /a 作为所有命令的前缀，因为我们假定已经从备用介质进行了引导，并且在 /a 下装入了根文件系统。
如果系统是使用 Traffic Light Patch (TLP) 工具进行的修补，则 TLP 输出将位于以下目录：
# ls /a/var/sadm/install_data/
PMGT:_TLP-Set_for_node_v4u-880c-muc07,_phase_GREEN,
_snapshot_2008-10-28_log
此数据由 patchanalysis_gather.txt 捕获。这些文件是包含 patchadd 输出的标准文本文件。每次运行 TLP 工具，都会生成一个文件。
3. 如果系统是使用 Sun Update Connection - Enterprise (UCE) 或者 Sun xVM Ops Center (xVMOC) 1.x 或 2.x 进行的修补，请验证 /a/var/opt/SUNWuce/agent 是否存在（用于确认使用的是 UCE、xVMOC 1.x，还是 xVMOC 2.x）。
如果 /a/var/opt/SUNWuce/agent 不存在，并且已验证正确装入了 /a/var（假定它未包含在根文件系统中），则系统未使用这些工具的任何一个进行修补。
4. 以下数据也是由 patchanalysis_gather.txt 捕获的。
如果 /a/var/opt/SUNWuce/agent 存在，请运行以下命令并注意输出以确定使用了哪些自动修补工具：
pkgparam -R /a -v SUNWucea VERSION
该输出表明已安装 UCE：VERSION='1.1.1-314'。
pkgparam -R /a -v SUNWscnconnmgt VERSION
该输出表明已安装 xVMOC 1.x：VERSION='1.0.0'。
该输出表明已安装 xVMOC 2.x：VERSION='2.0.0.820,REV=2009.01.26.07.57.17'。
知道使用了哪个工具非常有用，这样可以帮助消除该工具中的任何潜在问题，或在另一个系统上重新生成问题以确定潜在的问题。
前面提到的所有自动修补工具都会将其输出存储到 /a/var/opt/SUNWuce/agent/logs/ 中：
# ls -l /a/var/opt/SUNWuce/agent/logs/
total 33032
-rw-r--r-- 1 root root 5610478 Feb 20 17:12 error.log
-rw-r--r-- 1 root root 10485681 Feb 20 13:15 error.log.ad_bak
-rw-r--r-- 1 root root 94418 Feb 20 13:28 job.log
-rw-r--r-- 1 root root 15478 Feb 19 11:02 job_50007101.tgz
-rw-r--r-- 1 root root 11377 Feb 20 13:04 job_50011801.tgz
-rw-r--r-- 1 root root 12189 Feb 20 13:15 job_50012001.tgz
-rw-r--r-- 1 root root 12185 Feb 20 13:28 job_50012002.tgz
-rw------- 1 root root 323598 Feb 19 10:53 last_nco_file.xml
-rw-r--r-- 1 root root 30730 Feb 20 13:28 last_seeking.tgz
-rw-r--r-- 1 root root 16602 Feb 20 13:28 nco.log
-rw-r--r-- 1 root root 253666 Feb 20 13:28 resolve.log
-rw-r--r-- 1 root root 1434 Feb 20 09:29 uce_agent.log
# gzcat /a/var/opt/SUNWuce/agent/logs/job_50012002.tgz | tar tvf -
drwxr-xr-x 0/0 0 Feb 20 13:28 2009 va64-x4100a-muc07_job_500120
02/
-rwx------ 0/0 4466 Feb 20 13:28 2009 va64-x4100a-muc07_job_500120
02/Task.out
-rw-r--r-- 0/0 167297 Feb 20 13:28 2009 va64-x4100a-muc07_job_500120
2/copy_inventory
-rw-r--r-- 0/0 497 Feb 20 13:28 2009 va64-x4100a-muc07_job_500120
02/copy_basket
-rw-r--r-- 0/0 17 Feb 20 13:28 2009 va64-x4100a-muc07_job_500120
02/copy_policy
最重要的日志文件是 Task.out。它包含运行的 patchadd 命令的输出。但是，建议您将 /a/var/opt/SUNWuce/agent/logs 中的所有文件复制到系统以外的地方，用于可能的进一步检查。同时还复制 ls -ltr of /a/var/opt/SUNWuce/agent/logs 的输出。此数据由 patchanalysis_gather.txt 捕获。
本节列出了值得捕获的相关数据，所有这些数据都是由 patchanalysis_gather 脚本收集的。
patchadd -R /a -ppkginfo -R /a -ppkginfo -R /adf -k /a 和在 /a 下的任何其他装入点/a/var/adm/messages*/a/var/sadm/system/admin/CLUSTER/a/var/sadm/install/contents（此文件会很大）/a/etc/system/a/etc/vfstab/a/release/a/var/sadm/system/logs/ 的目录内容/a/var/sadm/install_data/ 的目录内容
如果存在非全局区域，以下数据可能非常有用：
/a/etc/zones/*
此数据由 patchanalysis_gather.txt 捕获。
每个非全局区域中的以下目录都包含修补程序日志，并且可能含有用于分析任何非全局区域问题的数据。注意：patchanalysis_gather.txt 脚本目前不 收集此数据，因为此目录不可能包含与导致系统无法引导相关的任何数据。
<zonepath>/root/var/sadm/patch/*
在收集了前面的数据后，建议开始对 patchadd 输出进行检查。然后，还检查 patchadd 日志（从 /var/sadm/patch/*/log 收集）。
在这些日志中查找错误和警告，特别是 patchadd 输出中可能有对 pkgadd 失败的引用，并在 /var/tmp 中存储有后续的日志文件。
如果是这样，请从 /a/var/tmp 中检索该日志文件并对其进行检查，因为它非常有可能确定造成问题的原因。
此外，还检查 patchadd 输出以检测是否有修补程序级别的脚本（例如 prepatch 或 postpatch）出现故障或生成意外消息。将 patchadd 输出与修补程序成功应用的系统中的已知标准 patchadd 输出进行比较，并查找所有附加或省略的消息。
如果受影响的系统中存在非全局区域，请检查 patchadd 输出，以查找任何表明因存在非全局区域而导致问题的错误。这些错误可能会采用以下格式：
Failed to boot non-global zone <zone-name>
此消息表明相关非全局区域已停止，并且 patchadd 无法将受影响区域移动到用于软件维护的内部状态。如果出现这种情况，请收集 /a/etc/zones/*.xml 文件和 /a/etc/vfstab。通过这些文件，支持工程师至少可以在修补之前确定系统状态和区域配置。
如果 df -k 输出表明根文件系统或 /var 中的可用空间达到 100%，建议您联系 Sun 技术支持，因为可能需要手动执行一些步骤以恢复系统一致性，具体取决于安装的修补程序和修补程序安装失败的部分。
例如，在 137137-09 修补后执行期间，如果 /platform 中的可用空间达到 100%，则在重新引导时，系统很可能不会跳过 OK 提示符来引导，并且将会出现表明引导加载失败的错误。在这种情况下，如果能够恢复足够的空间以允许重建引导归档，则系统就可以轻易获救而免遭持久损坏。
因此，您可以看到，首先了解确切的问题非常重要，因为这可使您正确地决定需要采取何种措施。
问题 ：无法打开 /etc/path_to_inst。
要解决此问题，请运行 boot -ar，并且当提示您重建 /etc/patch_to_inst 时，选择 yes。
问题 ：引导块发生问题（特别是应用了内核更新修补程序 137137-09 的基于 SPARC 的 Solaris 10 系统）。通常，如果出现与下列任一错误相似的情况，则可以确定引导块出现了问题：
刚加载的文件似乎无法执行。引导加载失败。刚加载的文件似乎无法执行。
建议您与 Sun 技术支持联系并提供以下信息，以获取进一步的说明。您可以从 df -n /a | awk '{print $3}' 获取 $ROOTFSTYPE（如果在 ./a 中装入了根）：
ls -l /platform/`uname -m`/boot_archive
ls -l /platform/`uname -m`/lib/fs/$ROOTFSTYPE/bootblk
从用于 SPARC 平台的 Solaris 10 10/08 发行版起，或在应用了内核更新修补程序 137137-09 后，会安装新的 bootblk。这个新的 bootblk 使用 boot_archive 而不是加载 ufsboot 来引导系统，而在 Solaris 10 10/08 发行版之前的更新中或未应用 137137-09 时即采取加载方式引导系统。
因此，了解哪个 bootblk 合适非常重要。安装错误的 bootblk 可使系统无法引导，直到安装了正确的 bootblk。建议您从 Sun 技术支持处获取详细说明。
如果在构建 boot_archive 时，/platform 中的根文件系统空间不足，则可能会导致以下错误：
The file just loaded does not appear to be executable.
同样，如果发生这种情况，建议您联系 Sun 技术支持，因为需要对系统进行分析以确定释放空间和使用 bootadm 命令构建 boot_archive 的最佳长期解决方案。
请务必注意，当使用工具（如 installboot）从介质引导来安装引导块时，必须使用正确介质中的 installboot。要在应用了 137137-09 修补程序的系统上或在准备好运行 Solaris 10 10/08 操作系统的系统上安装 bootblk，您必须从 Solaris 10 10/08 或更高版本的介质引导，或必须使用装入的系统中的 installboot。
例如，如果系统从网络引导到 Solaris 5/08 映像，则必须运行：
#/a/usr/sbin/installboot
而不是运行：
#/usr/sbin/installboot
但是，如果系统从 Solaris 10 10/08 或更高版本的介质引导，则可以运行以下命令：
#/usr/sbin/installboot
因此，在从介质引导以对装入的系统进行修改时，必须谨慎使用系统实用程序。建议您使用当前可用的最新 Solaris 更新映像作为引导映像。
下面提供了一些其他资源：
Print-friendly Version
