AIX系统经过市场检验，多年来运行在小型机平台上发挥着重要作用，不过很多小型机从业人员或多或少的都遭遇过AIX 启动出现问题，0517和0518 熟悉吗？每当代码走到这里的时候真心不忍直视，本文用相对简洁的方式来归纳总结AIX整个启动过程，及典型问题的处理。现在就让我们来了解一下AIX Boot 背后的那些事。

一、启动介绍

首先附上一张AIX启动的流程图：

经典的RS6000机器（MCA）结构系统硬件自检分两个阶段：内置设备自检阶段（BIST）和加电自检阶段（POST），

对于PCI的机器，则由单独的加电自检（POST）完成硬件检查。

经过硬件检查，系统就尝试加载引导逻辑卷（BLV：Boot Logical Volume），并在内存中形成RAM，并把控制权交给BLV，但由于内存中没有加载任何LVM（logic volume manager，LVM）的驱动，因此系统必须在不适用LVM的情况下正确找到BLV数据在硬盘上的位置。正确的BLV的地址信息（包括偏移量和长度）保存在引导磁盘的第一个物理扇区（这个扇区有512字节的块）上，这个扇区称之为引导记录（Boot Record）。

概念介绍：

AIX 启动过程当中涉及不少专业名词，这里做一下梳理解释。

1．RAMFS：

RAMFS是引导镜像的一部分，完全常驻内存，而且包含很多能让引导继续的程序。在RAM文件系统中运行的init进程实际上是ssh（simple shell）程序，这个程序通过调用rc.boot脚本来控制系统引导过程，rc.boot脚本第一步决定操作系统从哪个设备上引导，决定引导的设备应该在RAM文件系统中的配置（rc.boot脚本找到引导设备以后，从RAM文件系统中掉用相应的程序来进行配置

2．ROS：

系统只读存储器（system read only storage,ROS)。它是独立于操作系统的，相当于pc中的bios，它的作用就是定位和加载引导代码

3．IPL：

引导代码也就是引导程序（initial program loading， IPL），IPL定位BLV

4．BLV：

引导逻辑卷有时候也叫引导镜像，由AIX kernel，RC.BOOT,精简版 ODM, 和BOOT命令组成

5．AIX kernel：

AIX内核总是从BLV加载。/unix(软连接到/usr/lib/boot/unix_mp或unix_up)是一份内核副本，这个版本被用于构建hd4文件系统（也就是根文件系统）。在系统引导时，从hd4文件系统读取内核镜像

6．RC.BOOT：

rc.boot是一个shell命令文件，它是配置系统的脚本，在系统引导期间，init进程要执行这个脚本三次

基本上IBM 小型机的从业者大多都接触过或了解过AIX系统启动过程，其中比较官方的文档内容可以参考如下链接：

https://www.ibm.com/developerworks/cn/aix/redbooks/test191-1/

https://www.ibm.com/developerworks/cn/aix/redbooks/test222/boot-process/test222-bootprocess1.html

https://www.ibm.com/developerworks/cn/aix/redbooks/test222/boot-process/test222-bootprocess2.html

官方文档从系统启动的多个方面做了介绍，并且把在启动过程当中经常遇到的典型问题进行了归纳和梳理，尤其是那些让我们印象深刻的启动代码，不知道给多少人带来过深刻的记忆，挥之不去。多少喜怒哀乐陪伴着IT 人一路成长过来。

官方文档虽然内容详尽和充实，但从头读到尾很多时候给人一种信息量真大的感觉，为了更加深刻和全面的了解AIX 的启动过程，社区高手们用他们的经验和智慧为后续的从业者指点迷津，下面我们就用相对比较简洁一点的方式来归纳总结一下AIX整个启动过程，给大家一个整体感，对于每一个小的部分，有兴趣的可以深入研究。

IBM的小型机从加电到AIX系统启动完毕，可以分为几个阶段：

一、ROS内核初始化阶段

1、机器自检

2、ROS初始化载入程序（IPL）寻找引导设备，读取MBR内容。

3、将MBR指定引导逻辑卷（BLV）装入内存，创建RAM文件系统。

4、控制权交给RAM文件系统，初始化内核。

5、内核运行init程序，调用rc.boot脚本的第1个引导阶段（即执行rc.boot 1）。

二、基本设备配置阶段

rc.boot的第1个阶段创建ODM数据库，初始化逻辑卷管理器（LVM），激活根卷组，安装根文件系统。

三、系统引导阶段

1、init进程执行rc.boot的第2个阶段，安装文件系统，启动页面调度，将RAM文件系统的ODM数据库拷贝到硬盘中。

2、引导过程从RAM文件系统转移到硬盘上的根文件系统。

3、将控制权交给硬盘文件系统中的init进程，init进程执行/etc/inittab脚本。

4、/etc/inittab脚本调用/sbin/rc.boot的第3个阶段，及启动其他的进程来引导系统。

参考链接：http://www.aixchina.net/club/thread-75801-1-1.html

如果更加深入的了解AIX 启动过程，大家可以多读读 /sbin/rc.boot 和 /usr/sbin/bosboot 两个脚本文件，尤其是rc.boot 文件，详细介绍了在使用哪种方式启动时的系统调用，会有助于大家深入了解AIX 启动原理，系统启动的过程可以使用alog –t boot –o 查看

二、启动方式

AIX启动的方式主要有四种：

光盘，磁带，网络，磁盘

我们针对以上几种方式具体用于怎么样的一个场景在这里做一个简单的介绍，主要是结合日常运维工作场景。

光盘： 系统安装，系统异常维护，DIAG，系统异常恢复

磁带： 系统异常恢复

网络： 系统安装，系统异常维护，DIAG，系统异常恢复

磁盘： 系统正常启动

随着知识和工作手段的丰富，主要采取的方式有磁带和NIM 方式进行备份恢复工作，磁带和网络这两种方式相对于光盘来说比较灵活，由于容量和光驱故障率高，现在已经很少使用光盘用于系统的备份和恢复，很多时候只是作为应急措施而已。

有关NIM 的使用可以参考如下链接：

http://www.aixchina.net/Document/detail/tid/221927

http://www.aixchina.net/club/thread-115907-1-1.html

三、AIX 异常启动梳理

在日常运维当中，我们经常会遇到AIX不能启动问题，问题原因可谓是五花八门，下面我们就梳理一下：

1.ROOTVG异常

Rootvg 异常可谓问题多多，比如hd5丢失，rm –rf 删除核心文件，文件系统毁坏等

2.AIX 分区配置文件异常

使用hmc 或ivm 管理小型机时，由于设置配置文件启动模式，资源，配置文件不匹配等

3.启动列表丢失

Hd5丢失，或者rootvg 中两个磁盘mirrorvg 后没有修改bootlist，其中一个磁盘故障等

4.光盘版本不兼容

安装系统新硬件不支持老版本的系统，或者使用不低版本去维护高版本的os 等

5.硬件

由于硬件的问题，分区始终不能到standby状态，只有维修或更换备件后方可继续分区激活的步骤。

6.外因

风大，灰尘太多，没有盖盖子，温度高，坡度大等等，因为IBM 小型机对环境等诸多条件要求严格，所以在日常维护当中需要在这些方面多多注意，一个正确的操作流程可以避免诸多异常。

四、那些令人印象深刻的代码及相应修复方法

IBM 小型机的IPL流程如下：当系统加电后，自动进入IPL流程，IPL流程包括4个步骤:

1.Service Processor的初始化，始于系统加电，直到OK显示在机柜上的显示面板上为止。这个步骤会显示9XXX或9XXX Checkpoints代码。

2.由Service Processor引导的硬件初始化，始于按下机柜上的白色电源开关。这个步骤会显示9XXX Checkpoints。”91FF”是最后的代码，标志着第３步的开始。

3.系统固件的初始化，一个系统处理器接管控制并继续初始化系统资源，这个步骤会显示EXXX。”E105”是最后的代码，标志着第4步骤AIX启动的开始。在这个过程中还会显示各种位置码（位置码代表着系统的每一个部分）。

4.AIX启动，当AIX开始启动时，显示面板上的代码为0XXX，同时位置码会出现在第二行。当AIX的登录窗口出现在控制台上时，第4步骤结束，同时显示面板上再无任何信息显示。

今天我们就来聊聊在AIX启动过程当中，让我们印象深刻的代码和相应的修复办法：

0518

常见原因：

1.网络问题 系统启动中中断一下，然后就好了，检查网络网关

2.文件系统mnt问题 

3.安装过程中介质问题 

4.系统版本和机器不匹配，建议检查机器兼容性列表

5.启动过程中 hd5 文件损坏等

0517

常见原因：

一般是文件系统存在问题

IBM 官网有专门针对0517和0518 的处理办法，凸显了它在日常运维中的典型性，参考链接：

http://www-01.ibm.com/support/docview.wss?uid=isg3T1000131

201

常见原因：

启动镜像损坏

常规办法：

1.按照“访问无法启动的系统”中所描述的过程来访问您的 rootvg。

2.检查 / and /tmp 文件系统。如果它们几乎满了，那么创建更多的空间。

3.使用 lslv -m hd5 命令来确定启动磁盘。

4.使用 bosboot -a -d /dev/hdiskn 重建启动镜像，其中 n 是包含启动逻辑卷的磁盘的编号。

5.在错误日志中检查 CHECKSTOP 错误。如果找到了这样的错误，它很可能表示硬件的故障。

6.关闭并重新启动系统。

223-229

常见原因：

无效启动列表

常规办法：

1.将键模式切换到 Service（或者 F5，对于那些没有键盘锁的系统），并打开计算机的电源。

2.如果显示正常继续，则将键模式切换到 Normal 并继续第3步。如果没有得到提示，则进入第 4 步。

3.当出现登录提示符时，登录并按照“bootlist 命令”中所描述的过程来更改启动列表。然后继续执行第 7 步。

4.按照“访问无法启动的系统”中所描述的过程来访问您的 rootvg，并继续执行第 5 步。

5.使用 lslv -m hd5 命令来确定启动磁盘。

6.按照“bootlist 命令”中所描述的过程来更改启动列表。

7.关闭并重新启动您的系统。

551、555 和 557

常见原因：

损坏的文件系统、损坏的 JFS 日志等等

常规办法：

1. 在装入任何文件系统（“Volume Group Information”屏幕中的选项 2）之前，按照“访问无法启动的系统”中所描述的过程来访问 rootvg。

2. 验证并修改文件系统，如下所示：

3. 使用如下命令再次格式化 JFS 日志： /usr/sbin/logform /dev/hd8

4. 使用 lslv -m hd5 获得启动磁盘。

5. 使用下面的命令重新创建启动镜像： bosboot -a -d /dev/hdiskn 其中，n 是包含启动逻辑卷的磁盘的编号。

552、554 和 556

常见原因：

损坏的超级块和损坏的自定义 ODM 数据库

常规办法：

1.重复 LED 551、555 和 557 中的步骤 1 到 2。

2.如果 fsck 显示 block 8 被破坏，那么说明文件系统的超级块遭到破坏，并且需要对其进行修复。输入下面的命令：

其中，n 是该文件系统的编号。

3.使用如下的命令重新构建 JFS 日志：

/usr/sbin/logform /dev/hd8

4.如果这样做可以解决问题，那么就停止；否则，继续执行第 5 步。

5.您的 ODM 数据库遭到破坏。重新启动您的系统，在“Volume Group Information”屏幕中，使用选项 2 按照“访问无法启动的系统”中所描述的过程来访问 rootvg。

6.装入根文件系统和 usr 文件系统，如下所示：

7.将系统配置复制到备份目录：

8.复制 RAM 文件系统的配置，如下所示： cp /etc/objrepos/Cu* /mnt/etc/objrepos

9.使用 umount all 命令卸载所有的文件系统。

10.使用 lslv -m hd5 命令来确定启动磁盘。

11.使用下面的命令保存干净的 ODM 到启动逻辑卷： savebase -d/dev/hdiskn 其中，n 是包含启动逻辑卷的磁盘的编号。

12.重新启动，如果系统无法引导，则重新安装 BOS。

553

常见原因：

/etc/inittab 文件损坏

常规办法：

按照“访问无法启动的系统”中所描述的过程来访问所有已装入的文件系统的 rootvg。

2.使用 df 命令，检查 /、/var 和 /tmp 中的空闲空间。

3.检查 /etc/inittab 文件，如果存在一个空的 inittab 文件、inittab 文件缺失，或者在 inittab 文件中存在错误的条目，则纠正 inittab 问题。

4.检查下列文件的问题：

5.关闭系统，并重新启动。

0549

常见原因：

系统产生dump没有合适位置放置完成。

常规办法：

1.启动系统，可以使用串口登录，安装移动dump到适当位置。

2.启动系统进入维护模式扩大/var 文件系统

0569

常见原因：

后端连接光纤存储检测异常

常规办法：

拔掉光纤启动

*有关具体到每个code 的含义，可以IBM 官网搜索 AIX IPL Progress Code,当然大家也可以参考如下链接：http://www.aixchina.net/Document/detail/tid/6067

五、Bosboot 相关问题

在执行bosboot命令的时候有时会有报错，这个时候请不要忽略，这个时候如果你reboot 系统，等待你的可能是无尽的煎熬。所以在bosboot 执行有报错的时候需要首先处理完毕，再考虑reboot 的操作。

Bosboot 执行出错常见的问题有如下几个方面：

1.无效的启动设备

2.hd5 在指定的设备上不存在

3.savebase命令执行failed

4.Boot disk is part of rootvg , but not according to the lspv command output

本文一个小案例，在os rootvg 有两块磁盘，在执行bosboot 或者savebase 命令有所报错时后的一个参考解决办法。

检查启动列表：

检查AIX认为可以启动的设备是否在你的启动列表当中：

如果ipl_varyon –I 命令输出的有为NO状态的hdisk信息，有可能你先前执行chpv –c hdisk0 清楚了启动信息。

这个时候就需要执行

添加启动列表：

如果hd5异常或者不存在这需要新建hd5，参考如下：

查看ipldevice信息是否正确

ipldevice 是一个链接文件，指向启动设备，要求 主和次设备号一致，如果不一致需要删除现有ipldevice文件，重新做链接文件

先确定引导设备（/ 文件系统所在磁盘）

在执行bosboot的时候会调用savebase命令，而savebase命令需要把信息存储在ODM库当中，所以经常在系统做过硬件migrate或者alt_disk相关操作后，经常会报savebase fail 方面的错误信息。诸如lspv 命令和lsvg –p rootvg命令显示有冲突，修复操作参考如下：

然后

最后同步odm库

检查，此时在savebase –v 进行检查是否可以指向成功。诸如：

六、应对措施

犹如错误可以避免，误差只能减少的道理是一样的。系统运维亦是这个道理，常在河边站哪有不湿鞋，所以故障并不可怕，可怕的是你没有办法。那么有什么办法可以让故障带来的损失最小呢，我们又有那些措施可以采取，平常应该如何准备这方面的内容呢。这个话题铺开说太大，那么我们就针对AIX 日常运维来说，在整体和细节上都要有考虑。

一句话：有备无患

整体方向：

由于现在的业务系统实时性要求使得基础平台的高可用，连续可用的标准是越来越高，很多情况下SLA 3个9已经不能满足需求了，要求更高的4个9，或者更高。虽然IBM 小型机一直以来一直以高可用的特性著称，但是很多场景下，单机已经跟不上时代了，就连IBM的大机也不是说保证100%可用。 所以在当今环境下，应该更多考虑高可用集群，分布式等先进的工作方式，各个层次都有所冗余，有所备份，扩容扩展和替换。

细节方向：

针对于具体的细节方面，我们当然有很多工作可以做，诸如以下几个方面：

1.使用powerha 搭建高可用集群

2.搭建nim server 完成日常系统部署，软件分发，故障诊断

3.使用磁带完成日常的OS备份恢复

4.准备生产系统版本一致的光盘，系统异常维护使用

5.积累常见问题的处理办法，形成文档

6.Hmc 配置文件等的备份，防止配置的丢失

7.准备一些常见故障备件，如硬盘，电源等

8.使用hmc管理，可以通过ssh登录hmc，然后使用vtmenu 登录管理系统，避免java和浏览器带来的管理问题

等等，诸如此类工作还有很多，大家可以参照公司的情况参考执行。

通过对AIX 系统启动过程和在启动过程中常见问题的梳理，可以使我们对整个过程有一个清晰的认识，在日常工作中可以有针对性的进行加强和准备，让每次系统重启可以平滑度过，在遇到系统启动异常时可以少许的不那么意外和紧张，尽量做到有备无患。

长按二维码关注公众号