aix系统启动关闭设备配置诊断.docx

aix系统启动关闭设备配置诊断.docx

《aix系统启动关闭设备配置诊断.docx》由会员分享，可在线阅读，更多相关《aix系统启动关闭设备配置诊断.docx（57页珍藏版）》请在冰点文库上搜索。

aix系统启动关闭设备配置诊断

§

以B80的ServiceGuide为蓝本翻译

第一章系统的启动与关闭（主要来源于培训教程）

POWERAIX系统启动程序

Bootstrapping：

POWERAIX系统启动程序称之为bootstrapping

Bootstrapping分为硬件初始化阶段和AIX核心初始化阶段

IBM称硬件初始化阶段为：

ROSIPL（readonlystorageinitialprogramload），亦称：

ROSinit、ROMinit，亦或称IPL、boot（IPL有370/390MVS或VM的影子，而boot在UNIX中比较常见）。

ROSIPL在执行完硬件初始化后，会到NVRAM中bootlist中查找AIX引导设备，再把引导设备中的bootimage或bootstrap核心加载到内存，进入AIX核心初始化阶段。

引导列表bootlist，也可以AIX系统中执行bootlist命令来定义：

#bootlist–mnormalhdisk0cd0rmt0

#bootlist–mentogateway=\

bserver=

client=cd0<>

根据引导清单的不同分为：

正常、服务、上一次开机这三种列表，且它们是分开存储的。

根据这点，不同的bootlist把POWERAIX

第二章典型的引导顺序（来自serviceguide）

在打开电源之后，SSC（SystemSupportControllerstartup）从服务处理器开始。

如果SSC不能与服务处理器通信，LCD显示4BA00000。

如果服务处理器未出席（不存在），LCD会显示4BA00001。

1．服务处理器自测试

服务处理器卡执行自测试和NVRAM初始化

LCD代码范围是E000-E07F

完成后LCD代码为OK

2．待命模式下的服务处理器

无论何时LCD代码显示OK、STBY或八位数字错误代码，就可以进入服务处理器菜单。

进入方式是在连接到串行口1上的ASCII终端上按回车键。

3．BIST

当电源开启时（即电源工关被按下时），服务处理器初始化CEC芯片上的BIST。

VPD数据被读出来，且CRC会被校验。

处理器兼容性测试被运行

LCD代码范围是E0A0-E0E1

4．系统初始化

在LCD代码E0E1之后，系统固件开始执行且初始化系统寄存器。

LCD代码范围是E1XX-E2XX。

5．内存测试

系统固件测试系统内存，并标识失败的内存卡和内存模块位置。

LCD代码范围是E3XX。

6．设备配置与测试

系统固件检测并找出系统中有哪些设备且对他们执行一个简单的测试。

系统固件显示测试过的设备名或设备图标。

在键盘名或键盘图标显示之后，用户可以通过按1键（ASCII终端）或F1键（图形终端）进入SMM菜单。

用户也能进入：

---5或F5启动独立诊断（CD）。

---6或F6启动在线诊断（磁盘）。

7．IPL引导代码

系统固件试图从bootlist中列出的设备中引导。

当E105（normalmodeboot）或E15B（servicemodeboot）出现在操作面板上时，说明控制传递给AIX了。

LCD代码范围是E105（自己根据B80机器上的试验得出：

从扬声器图标出现后的LCD代码为E105）

8．

9．POST

10．

LCD出现E1F1代码后，按1键很容易从ASCII终端进入SMS菜单。

第三章系统启动问题处理（本章来自sg246191_IBMCertificationStudyGuide-pSeriesAIXSystemAdministration.pdf第2章Systemstartupproblemhandling）

§三.1引导过程

在系统进行冷启动或热启动时，在系统就绪使用前，许多事件必须出现。

这些事件能被分成下面的阶段：

1．ROS核心初始化阶段

主要事件是ROSIPL搜索bootlist，找到bootimage，读之进内存，启动系统初始化过程。

2．基本设备配置阶段

在此阶段所有的设备被配置，查看命令cfgmgr的帮助信息

3．系统引导阶段

引导过程的这个阶段，所有的逻辑卷在线，页面被启动，且/etc/inittab文件被处理。

系统初始化（本节来自sg246199_IBMCertificationStudyGuide-pSeriesAIXSystemSupport.pdf中的3.1）

在系统启动期间，在预初始化进程安装完root文件之后，下面的事件顺序会发生：

1．Init命令作为启动进程的最后一步来运行的。

2．Init命令试图读取/etc/inittab文件

3．如果/etc/inittab文件存在，init命令试图在/etc/inittab文件中定位一个initdefault项。

a）如果initdefault项存在，init命令使用指定的runlevel作为初始系统runlevel。

b）如果initdefault项不存在，init命令需要用户从系统控制台（/dev/console）输入一个runlevel

c）如果用户输入S,s,M,或m作为runlevel，init命令进入维护runlevel。

这些是仅有的不需要正确格式化/etc/inittab文件的runlevel。

4．如果/etc/inittab文件不存在，init命令缺省地把系统置于维护runlevel

5．Init命令每60秒重读/etc/inittab文件，如果文件/etc/inittab自init命令最后一次读后发生更改，在文件/etc/inittab中的新命令会被执行。

/etc/inittab文件（本节来自sg246199_IBMCertificationStudyGuide-pSeriesAIXSystemSupport.pdf中的3.2）

/etc/inittab文件控制了初始化过程。

/etc/inittab文件提供脚本到init命令的任务中，作为常规进程的调度程序。

建立大多数init命令的进程的进程是/etc/getty线路进程，它初始化单独的终端线。

由init命令分派的其他进程典型地是daemons和外壳。

/etc/inittab文件由依赖于位置的项来组成，且有下面的格式：

Identifier:

RunLevel:

Action:

Command

每一行由换行符来划分。

换行符前面的反斜线指示下行是某一项的继行。

在/etc/inittab文件中的项数目没有限制（除了最大的项尺寸，它是1024个字符）。

每一项的域如下：

identifier是一个14个字符的域，它唯一标识一个对象

RunLevel这一项在这一runlevel下被处理

Runlevel有下面的属性：

●Runlevel有效地协调系统中的进程配置

●由init命令启动的每个进程被指派给它能存在的一个或多个runlevel。

●Runlevel由数字0到9来表现。

例如，如果系统在runlevel1，那么仅在runlevel域中为1的项被启动。

●当你请求init命令来更改runlevel，所有在runlevel域不匹配目标runlevel的进程接收一个警告信号（SIGTERM）。

在进程被kill信号（SIGKILL）强制终止之前有20秒的时间

●runlevel域能为进程定义多个runlevel，可以用任一从0到9的组合来选择多个runlevel。

如果未指定runlevel，进程被假定在所有runlevel中有效。

●在runlevel域中能出现三个其他的值，甚至不是真的runlevel：

a,b,和c。

在runlevel域中有这些字符的项仅当telinit命令要求它们运行时被处理（而不考虑系统当前的runlevel）。

对任一这些进程执行的请求不会更改当前的runlevel。

而且，当init命令改变runlevel时由a,b,c启动的命令进程不会被杀死。

它们仅当在/etc/inittab文件中它们的行在action域中被标记为off时会被杀死，它们的行完全地从/etc/inittab文件中被删除，或init命令进入单用户模式。

Action告诉init命令如何处理在进程域中指定的进程，下面的行为由init命令识别

Respawn如果进程不存在，启动进程。

不等待它的终止（继续扫描/etc/inittab文件）。

当它死后重启该进程。

如果进程存在，不进行任何动作，继续扫描/etc/inittab文件

Wait当init命令进入匹配项runlevel的runlevel，启动进程并等待它的终止。

所有对/etc/inittab文件的随后读将导致init命令忽略这一项。

Once当init命令进入一个与项的runlevel匹配的runlevel时，启动该进程，不等待终止。

当它死时，不重启这个进程。

当系统进入一个新的runlevel，且先前的runlevel进程仍然进行，不会被重启。

Boot仅在系统引导期间（也就是在系统启动时init命令读取/etc/inittab文件时）处理这些项。

启动这个进程，不等待它的终止，且当它死时，不重启这个进程。

Runlevel应该是缺省的，或它必须在引导时与init命令的runlevel匹配。

伴随系统的硬件重启，这个行为对于初始化功能是很有用的。

Bootwait在系统重启之后，首先处理从单用户过渡到多用户的init命令项。

启动该进程，等待它的终止，当它死时，不重启进程。

如果initdefault是2，在重启后正确运行进程。

Powerfail仅当init命令收到电源失败信号（SIGPWR）时，执行与这个项相关的进程。

Powerwait仅当init命令收到电源失败信号（SIGPWR）时，执行与这个项相关的进程，且等待直到它终止，才继续扫描/etc/inittab文件中的进程。

Off如果与该项相关的进程目前正在运行，发送警告信号（SIGTERM），且在用skill信号（SIGKILL）终止进程前等候20秒。

如果进程未运行，忽略这一项。

Ondemand与respawn的功能一致，除了这个行为应用于a,b,c值，不应用于runlevel外。

Initdefault具有这个行为的项仅当init命令最初调用时被扫描。

Init命令使用这个项，如果它存在，确定最初进入哪个runlevel。

取在runlevel域中指定的最高runlevel并使用它作为它的初始状态。

如果runlevel域是空的，它被解释为09：

因此，init命令进入runlevel9。

加之，如果init命令未在文件/etc/inittab中找到initdefault项，在引导时它从用户处请求一个初始的runlevel

Sysinit登录前init命令试图访问控制台之前这个类型的项会被执行。

这一项将仅用来初始化设备，init命令可能试图询问关于设备的runlevel问题。

这些项被执行且在继续前会等候。

Command执行一个外壳命令。

整个命令域用exec预处理。

任一合法的sh语法能出现在这个域中。

用#号可以插入注释。

Getty命令重写文件/etc/inittab中出现在它之前的任一命令的输出。

记录这些命令的输出到引导日志中，重导它们的输出到alog–tboot命令中。

当init正在处理inittab项时，stdin,stdout，和stderr文件描述符可能可不用。

写到stdout或stderr的任一项可能不能预知它们的工作情况，除非它们重定向它们的输到文件或/dev/console。

下面的命令是修改/etc/inittab文件中记录的唯一支持的方式：

chitab改变在文件/etc/inittab中的记录

lsitab列出在文件/etc/initab中的记录

mkitab添加记录到/etc/inittab

rmitab删除文件/etc/initab中的记录

/etc/inittab项中的顺序

●1-initdefault

●2-sysinit

●3-PowerfailureDetection（powerfail）

●4-Multiusercheck（rc）

●5-/etc/firstboot（fbcheck）

●6-SystemResourceController（srcmstr）

●7-StartTCP/IPdaemons（rctcpip）

●8-StartNFSdaemons（rcnfs）

●9-cron

●10-pbcleanup（piobe）

●11-gettyfortheconsole（cons）

SRC不得不在/etc/inittab文件的开始处启动起来，因为SRCdaemon需要启动其他的进程。

由于NFS需要TCP/IPdaemon正常运行，TCP/IPdaemon在NFSdaemon之前启动起来。

在文件/etc/inittab中的项依赖于从属关系来排序，意味着如果进程（process1）依赖于另一个进程（process2）才能正常操作，那么在/etc/inittab文件中进程process1要出现在进程process2之后。

Telinit命令（本节来自sg246199_IBMCertificationStudyGuide-pSeriesAIXSystemSupport.pdf中的3.2）

Telinit命令指引init进程（进程ID为1）的行为，通过获得一个参数或发信号给init进程来完成适应的行为。

一般而言，telinit命令把系统设在指定的runlevel。

下面的参数起指示用，telinit传递这些指示用参数给init进程。

0-9告诉init进程把系统置于runlevel0-9当中。

S,s,M,m告诉init进程进入维护模式

a,b,c告诉init进程仅诊断在文件/etc/inittab中runlevel域中为a,b,c的这些记录

Q，q告诉init进程来重新诊断整个/etc/initab文件

N发送一个信号来停止进程，以防止它被重启

§三.2开机顺序、LED、和声音信号

PCIRS/6000系统使用声音和图形来显示不同的引导过程阶段。

例如，一旦你打开系统，当处理器被找到且激活时会产生嘟嘟声；当系统内存检测完成时，PowerPC标识语被显示（或显示文本）；对于有有效地址的所有设备设备标识语会被显示。

在设备标识语显示完后，如果系统ROS未受到伤害，嘟嘟声会再次产生。

系统管理员使用这些指示器解决在启动过程他们可能遇到的问题

§三.3有用的命令

用来管理系统启动、关闭、和相关任务的命令在下面节中被讨论。

§三.3.1使用alog命令

alog命令能维护且管理日志。

它从标准输入中读，且写到标准输出。

且拷贝输出到固定大小的文件。

这个文件作为一个循环日志来处理。

如果文件满了，新的项目会覆盖最老的项目。

Rc.boot脚本直接通过alog命令重定向引导信息到文件/var/adm/ras/bootlog。

如果系统有什么错误，你能把系统引导到单用户模式（维护模式）且通过alog命令来访问这些日志以查看系统是在什么阶段失败的。

下面的rc.boot脚本的一部分显示了日志机制如何组成一体的。

#ErrorRecoveryifcustomizeddataiszero

[-f/no_sbase]&&{

echo"rc.boot:

executingsavebaserecoveryprocedures"\

>>/tmp/boot_log

X=`ODMDIR=/mnt/etc/objreposodmshowCuDv|\

fgreppopulation`

count=`echo$X|cut-f2-d''`

[$count-ne0]&&{

/usr/sbin/savebase-o/mnt/etc/objrepos

[$?

-ne0]&&loopled0x546

mount/var#sothatrebootcanlog

echo"savebaserecoveryreboot"\

>>/tmp/boot_log

cat/tmp/boot_log|alog-q-tboot

reboot

}

}

alog命令作用于由命令行指定的文件，或作用于alog配置数据库中定义的日志。

AIX日志能由SMIT或通过alog命令直接维护。

Alog命令的一般用法如下：

要显示一个日志文件的内容，输入下面的命令：

alog–fLogFile[-o]

把数据日志到指定的日志文件

你能使用下面的命令来更改用来日志行为的缺省文件

alog-fLogFile|[[-q][-sSize]]

显示指定日志类型的冗余值

冗余值指定了写到日志中信息的深度。

为了显示日志的冗余值，使用下面的命令：

alog–tLogType–v

改变指定日志类型的属性

通过使用下面的命令来使用不同的日志类型属性。

alog-C-tLogType[-fLogFile][-sSize][-wVerbosity]

显示指定日志类型的当前属性

在你能更改日志属性，推荐查看当前属性是什么。

使用下面的命令来显示当前日志类型的属性。

alog-L[-tLogType]

要查看引导日志，你也能使用SMIT或直接使用alog

查看引导日志

你能通过使用smittyalog_show来查看引导日志。

使用alog–L命令来查看定义在alog数据库中的日志。

Alog文件没并发控制能力，因此如果多个进程试图在同时写到一个文件，日志文件的内容可能不能预料。

加之，它是一个循环文件；当它的大小达到最大值时，它会被覆盖。

§三.3.2使用cfgmgr命令

在引导过程期间，系统不得不判断有什么资源它可以用。

例如，系统不得不判断系统正在使用什么样的总线类型，系统上接有什么类型的设备。

这些设备的配置由BOS命令cfgmgr来配置。

Cfgmgr命令配置设备且有选择地安装设备软件到系统上。

Cfgmgr命令的一般语法如下：

cfgmgr[-f|-s|-pPhase][-iDevice][-lName][-v]

被配置的设备是由配置规则对象类来控制的，它是设备配置数据库的一部分。

每一个配置规则指定了三个项目：

●要运行的可执行程序的完整路径名

●什么时候运行程序（与其他规则的关系）

●在哪个阶段运行程序

如果cfgmgr命令调用时没有阶段选项（如，没有-f,-s,-p标志），那么命令运行阶段2的规则。

要运行阶段3规则的唯一办法是使用-p标志。

如果cfgmgr命令调用时使用了-i标志，命令会试图为每个新检测到的设备自动安装设备软件，-i标志的设备变量指定了到哪里找到安装介质。

安装介质可以是硬件设备（诸如磁带或软盘驱动器），也可以是包含安装映象的一个目录，也可以是安装映象文件本身。

重点：

要保护配置数据库，cfgmgr命令是不可中断的。

在执行完成前停止这个命令能导致数据库破坏。

Cfgmgr命令仅配置在系统启动时打开电源和可自配置的设备，如SCSI驱动器或己在inittab文件中定义了的TTY。

如果你有一些设备在系统启动时未打开电源，系统不会让它们可用，除非你明确告诉它来配置它们，命令语法如下：

Cfgmgr–v

它将产生一个类似alog–o–tboot命令的输出

§三.3.3使用last命令

last命令通常用来显示文件/var/adm/wtmp中记录的所有先前的登录和注销。

当这些事件发生时文件/var/adm/wtmp收集登录和注销的记录，并保留下为，直至这些记录由acctcon1和acctcon2命令作为日报表程序的一部分处理时。

当timedaemontimed更改了系统时间，在/var/adm/wtmp中会有一项日志记录下来。

在更改之前具有日期/的启动项会被日志下来，在更改之后具有日期{的启动项也会被日志下来。

这样允许对跨时间更改的登录进行精确记帐。

命令的一般语法如下：

last[-fFileName][-Number][Name...][Terminal...]

lastrootconsole

last命令也能用来判断系统何时最后关机的。

命令语法如下：

#lastshutdown

§三.3.4使用bootlist命令

bootlist[{-mMode}[-r][-o][[-i]|[[-fFile][Device[Attr=Value...]...]]]

#bootlist–mnormal-o

fd0

cd0

hdisk0

引导设备选择

下表的命令约定可以用于你的bootlist中。

你添加到bootlist中的每个设备必须是Available状态。

否则，bootlist会失败，你会得到一个类似于下面的错误：

0514-210bootlist:

DevicexxxxxisnotintheAVAILABLEstate

§三.3.5使用uptime命令

如果你怀疑你的系统关闭或重启，你可以使用uptime命令来查。

Uptime命令显示系统起来多长时间了。

命令的常规语法如下：

#uptime

05:

10PMup6days,21:

45,13users,loadaverage4.00,3.00,0.00

uptime显示当前时间,系统起来了多长时间，在线用户数，和负载平均值，负载平均值是指最后5、10、或15分钟间隔内可运行的进程数。

Uptime命令的输出本质上是由w命令提供的标题行。

§三.3.6使用mpcfg命令

mpcfg命令允许root权限用户来管理服务信息，包括服务支持和诊断标志（-S和-f），调制解调器和站点配置，以及远程支持电话号码（-p标志）。

Mpcfg命令仅工作在MCA多处理器系统中。

对于IBM系统，包括theIBM7012ModelGSeries,theIBM7013ModelJSeries,andtheIBM7015ModelRSeries。

显示服务信息

要显示服务信息，你可以使用：

mpcfg–d{-f–m–p–S}

§三.3.7使用shutdown命令

系统关闭是由一个外壳脚本控制的，它会正确地准备系统的关闭和重启。

不正确的关闭可能在系统完整性上会导致不可预知的结果。

Shutdown命令的一般语法如下：

shutdown[-d][-F][-h][-i][-k][-m][-p][-r][-tmmddHHMM[yy]][-v][+Time[Message]]

添加应用程序到shutdown进程

有时，有必要正确地关闭所有的应用程序和其他的用户进程，而不使用kill命令来