POWER SYSTEMS FOR AIX III · 2015-04-21 · 과 목 명 Power Systems for AIX III: Advanced...

POWER SYSTEMS FOR AIX III :

ADVANCED ADMINISTRATION AND PROBLEM DETERMINATION

UNIT 6. SYSTEM INITIALIZATION: RC.BOOT AND INITTAB

유니원 아이앤씨(주)

시스템 기술 지원 팀

이 현 수

문서정보

과 목 명 Power Systems for AIX III: Advanced Administration and Problem Determination

단 원 명 Unit 6. System initialization: rc.boot and inittab

수강 장소 MIRHENGE 교육센터

수강 기간 2014-09-01 ~ 2014-09-05 작성일 2014-10-14

작 성 자 이 현 수 최종수정일 2014-10-17

재개정 이력

일자 내용 수정인 버전

문서배포 이력

발신자 수신자 배포목적 일자 비고


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 2 / 60

Content

1. 개요 .............................................................................................................................................................................................. 4

1.1. 단원 설명 ...................................................................................................................................................................... 4

1.2. 단원 목표 ...................................................................................................................................................................... 4

2. 시스템 소프트웨어 개요 .................................................................................................................................................... 5

2.1. 부팅 순서 ...................................................................................................................................................................... 5

2.1.1. AIX 커널 수행 ................................................................................................................................................ 5

3. rc.boot 1 ..................................................................................................................................................................................... 6

3.1. rc.boot 1단계 동작 ................................................................................................................................................... 6

4. rc.boot 2 ..................................................................................................................................................................................... 7

4.1. rc.boot 2단계 동작(1/2) .......................................................................................................................................... 7

4.2. RAMFS의 특별한 루트 문법 ................................................................................................................................ 8

4.3. rc.boot 2단계 동작(2/2) .......................................................................................................................................... 9

4.4. 마지막 단계 .............................................................................................................................................................. 10

5. rc.boot 3 .................................................................................................................................................................................. 11

5.1. rc.boot 3단계 동작(1/2) ....................................................................................................................................... 11

5.2. rc.boot 3단계 동작(2/2) ....................................................................................................................................... 12

6. rc.boot 요약 ........................................................................................................................................................................... 14

7. 손상된 파일 시스템과 로그 수리(fixing) ................................................................................................................. 15

8. 구성 관리자 ........................................................................................................................................................................... 16

8.1. 구성 관리자 호출 시점 ....................................................................................................................................... 16

8.2. 자동 구성 ................................................................................................................................................................... 16

8.3. 새로운 장치 지원 설치 ....................................................................................................................................... 16

8.4. 방법 정의 ................................................................................................................................................................... 16

8.5. 구성 방법 단계 ....................................................................................................................................................... 16

8.6. 구성 순서 ................................................................................................................................................................... 17

9. Config_Rules 객체 클래스 .............................................................................................................................................. 18

9.1. 소개 .............................................................................................................................................................................. 18

9.2. 1 단계(Phase 1) ....................................................................................................................................................... 18

9.3. 2 단계(Phase 2) ....................................................................................................................................................... 18

9.4. 3 단계(Phase 3) ....................................................................................................................................................... 18

9.5. 순차 번호(Sequence number) .......................................................................................................................... 18

9.6. 부팅 마스크(Boot mask) ..................................................................................................................................... 19

10. alog를 사용하는 부트 로그에서 cfgmgr 출력 ................................................................................................... 20

10.1. 부트 로그 ................................................................................................................................................................ 20


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 3 / 60

11. /etc/inittab file ................................................................................................................................................................... 21

11.1. 목적 ............................................................................................................................................................................ 21

11.2. 변경 ............................................................................................................................................................................ 21

11.3. 보기 ............................................................................................................................................................................ 21

11.4. telinit와 실행단계(run levels).......................................................................................................................... 22

12. 부팅 장애 관리 ................................................................................................................................................................. 23

12.1. 소개 ............................................................................................................................................................................ 23

12.2. 부트리스트 손상? ................................................................................................................................................ 23

12.3. /etc/inittab 손상? /etc/environment 손상? ............................................................................................. 23

12.4. 부트 논리 볼륨 또는 부트 기록 손상? .................................................................................................... 24

12.5. JFS 로그 또는 JFS2 로그 손상? ................................................................................................................... 24

12.6. 슈퍼블록(Superblock) 손상?........................................................................................................................... 24

12.7. rootvg 잠김? .......................................................................................................................................................... 24

12.8. ODM 파일 손실? ................................................................................................................................................. 25

12.9. /usr 또는 /var 올리기(mount) 실패 ........................................................................................................... 25

13. 실습......................................................................................................................................................................................... 26

13.1. 손상된 논리볼륨 로그 복구 ........................................................................................................................... 26

13.1.1. rootvg의 파일시스템 유형 확인 ...................................................................................................... 26

13.1.2. 논리볼륨 로그 손상 유발 ................................................................................................................... 26

13.1.3. LPAR 상태 확인 ....................................................................................................................................... 27

13.1.4. LPAR 종료 ................................................................................................................................................... 29

13.1.5. SMS 모드를 통한 NIM 부팅 ............................................................................................................. 30

13.1.6. 유지관리 모드 .......................................................................................................................................... 44

13.1.7. 복구하기 ...................................................................................................................................................... 49

13.2. 부팅 실패 분석 및 해결 .................................................................................................................................. 56

13.2.1. 유지관리 모드 .......................................................................................................................................... 56

13.2.2. inittab 복구 ................................................................................................................................................ 58


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 4 / 60

1. 개요

1.1. 단원 설명

부팅 과정의 마지막 단계와 시스템 장치 구성 설정의 개요를 설명한다.

일반적인 부팅 장애들을 묘사하고 부팅 문제를 수정하기 위해 부팅 애러들을 어떻게 분석

하는지 설명한다.

1.2. 단원 목표

− 부트 이미지 로딩에서부터 부팅 완료까지 시스템 초기화 과정 확인

− 부팅 과정 동안 장치들이 어떻게 구성 설정 되는지 확인

− 부팅 문제를 분석하고 해결


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 5 / 60

2. 시스템 소프트웨어 개요

[그림 2-1] 부팅 과정(AIX 커널 로딩 후)

2.1. 부팅 순서

[그림 2-1]은 부트 이미지에서 AIX 커널이 올라온 이후의 부팅 과정을 보여준다.

2.1.1. AIX 커널 수행

AIX 커널이 제어를 얻으면 [표 2-1]과 같은 과정을 수행한다.

순 번 동 작

1

커널은 제공된 부트 이미지의 정보를 사용하여 메모리에 있는 RAM 파일시스템을 복

원한다. 이 단계에서 rootvg는 사용이 불가능하다. 따라서 커널은 RAM 파일시스템에

서 제공하는 명령어로 작업을 수행한다. 즉, 이 RAM 파일시스템을 작은 AIX 운영체제

라고 볼 수 있다.

2 커널이 RAM 파일 시스템(루트 파일 시스템이 아님)에서 제공되는 init 프로세스를 시

작한다. init 프로세스는 부트 스크립트인 rc.boot를 실행한다.

3 rc.boot는 부트 프로세스를 제어한다. 1단계(rc.boot 1이라 칭함)에서 기본 장치들이 구

성된다. 2번째 단계(rc.boot 2라고 칭함)에서 rootvg가 활성화된다.

4 rc.boot 2의 끝에 rootvg가 활성화된 후, 커널은 RAM 파일시스템을 rootvg 파일 시스

템으로 덮어 올린다. 부트 이미지의 init은 루트파일시스템 hd4의 init으로 대체된다.

5 init은 /etc/inittab 파일을 처리한다. rc.boot은 3번째(rc.boot 3이라 칭함)로 호출되고

남아있는 모든 장치들을 구성한다.

[표 2-1] 커널 수행 과정


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 6 / 60

3. rc.boot 1

3.1. rc.boot 1단계 동작

RAM 파일시스템 에서 init

프로세스가 시작되고 rc.boot

1 스크립트를 실행한다. 어떠

한 이유에서든(예를 들면 손상

된 부트 논리 볼륨) init이 실

패하면 LED에 c06이 출력된다.

부트 논리 볼륨에서 대부분의

결함은 디바이스 드라이버가

없는 것이다. 이것은 필요한

드라이버를 포함한 부트 이미

지를 다시 만듦으로써 해결할

수 있다.

[표 3-1]은 rc.boot 1이 호출

되었을 때 실행되는 과정이다.

순 번 동 작

1

부트 이미지에서 RAM 파일시스템으로 ODM을 복사하는 restbase 명령이 호출된다.

이 단계 이후, ODM은 RAM 파일시스템 안에서 사용 가능하다. restbase가 성공적으로

완료되면 LED에는 510(DEV CFG 1 START)이 나타나고 그렇지 않으면 548(RESTBASE

FAILED)이 나타난다.

2

restbase가 성공적으로 끝나면 구성 관리자인 cfgmgr이 -f(first)옵션으로 동작한다.

cfgmgr은 Config_Rules 객체 클래스에서 읽고 phase=1 아래에 저장된 모든 방법들을

실행한다. 1단계 구성 방법들은 시스템에 있는 기본 장치의 구성을 수행하여 rootvg가

다음 rc.boot 단계에서 활성화될 수 있게 한다.

3

기본 장치들은 rootvg에 접근하기 위해 필요한 모든 장치들이다. 만약 rootvg가

hdisk0에 저장되어 있다면, 마더보드(motherboard)에서부터 디스크에 이르기까지 존재

하는 모든 장치들은 rootvg에 접근할 수 있도록 순서에 맞게 구성 되어야만 한다.

4

rc.boot 1의 막바지에 시스템은 bootinfo -b를 호출함으로써 마지막 부트 장치

(/dev/ipldevice 연결을 설립하기 위해 사용되는)를 결정한다. LED는 553(PHASE 1

COMPLETE)에 뒤이어 511(DEV CFG 1 END)를 보여준다.

[표 3-1] rc.boot 1 호출 시 과정

[그림 3-1] rc.boot 1 과정


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 7 / 60

4. rc.boot 2

4.1. rc.boot 2단계 동작(1/2)

[그림 4-1] rc.boot 2 과정-1

두 번째로 실행되는 rc.boot는 변수 값으로 2가 넘어간다. LED는 551(VARYON_IPLDEV)이

표시된다. [표 4-1]은 이 부팅 단계를 나타낸다.

순 번 동 작

1

rootvg는 varyonvg 명령을 통해 다뤄질 수 있는 상태로 변화한다. 만약 ipl_varyon이

성공적으로 완료되면, LED에 517(MOUNT ROOT)이 표시된다. 반면, 부팅과정이 멈췄을

경우 다음과 같이 표시된다.

− 552(IPLVARYON ERROR)

− 554(UNKNOWN BOOT DISK)

− 556(LVM_QUERY ERROR)

2 루트파일시스템 hd4는 fsck로 확인된다. -f 옵션은 마지막으로 종료하는 동안 깔끔하게

분리되지 않은 파일시스템을 확인한다는 것을 의미한다. 이것은 부팅 수행을 행상시킨


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 8 / 60

다. 확인이 실패할 경우, LED는 555(FSCK ERROR)를 표시한다.

3

그 후, /dev/hd4는 RAM 파일시스템의 root(/)에 직접적으로 올라온다. 만약 실패할 경

우(예를 들면 손상된 JFS 로그 등에 의해) LED는 557(ROOT MNT FAILED)를 표시하고

부팅 과정은 정지된다.

4 다음으로 /dev/hd2가 확인되고 올라온다. 실패하면 LED에 518(/USR MOUNT FAILED)

가 표시되고 부팅이 멈춘다.

5

/var 파일시스템이 확인되고 올라온다. copycore 명령이 덤프 유무를 확인하기 때문이

필요하다. 페이징 공간 장치에서 덤프가 존재한다면, 덤프 장치인 /dev/hd6로부터 기

본 디렉토리인 /var/adm/ras로 복사한다. 그 후, /var/은 분리된다. 만약 /var을 올리지

못하면 LED에는 518(/VAR MOUNT FAILED)이 표시되고 부팅이 멈춘다.

6 주 페이징 공간 /dev/hd6가 사용할 수 있게 된다.

[표 4-1] rc.boot 2 호출 시 과정-1

4.2. RAMFS의 특별한 루트 문법

디스크 기반 루트파일시스템이 RAMFS위로 올라오고 나면 rc.boot에서 RAMFS 파일로 접

근하기 위해 특별한 문법이 사용된다.

− RAMFS 파일들은 /../ 접두사를 사용하여 접근된다. 예를 들어, RAMFS의 fsck 명령에

접근(/usr 파일시스템이 올라오기 전)하려면, rc.boot는 /../usr/sbin/fsck를 사용한다.

− 디스크 기반 파일들은 일반적인 AIX 파일 문법을 사용하여 접근된다. 예를 들어, 디

스크의 fsck 명령에 접근(/usr 파일시스템이 올라온 이후)하려면, rc.boot는

/usr/sbin/fsck를 사용한다.

참고로 이 문법은 오직 부팅과정이 진행되는 동안에만 작동한다. 만약 CD-ROM을 사용하

여 유지관리 모드로 부팅하고 루트파일시스템을 수동으로 올릴 필요가 있을 때 /mnt와 같은

다른 디렉토리로 올리지 않으면 RAMFS 파일들에 접근할 수 없게 된다.


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 9 / 60



페이징 공간 /dev/hd6가 사용 가능하게 된 후, rc.boot 2에서 [표 4-2]의 작업들이 실행된다.

순 번 동 작

1

이 단계를 이해하기 위해서는 다음 두 가지를 기억해야 한다.

− /dev/hd4는 RAM 파일시스템의 루트(/)에 올라온다.

− rc.boot 1에서 cfgmgr이 호출되고 모든 기본 장치들이 구성된다. 이 구성설정

데이터는 RAM 파일시스템의 ODM에 기록된다.

이제 mergedev가 호출되고 모든 RAM파일시스템의 /dev 파일이 디스크로 복사된다.

2 RAM 파일시스템 ODM의 사용자 정의된 모든 ODM 파일들이 디스크로 복사된다. 이

단계에서 두 개의 ODM(hd5와 hd4)이 동기화된다.

3 /var 파일시스템(hd9var)이 올라온다.

4

부팅과정의 모든 메시지들이 특별한 파일에 복사된다. 이 파일을 보려면 alog 명령을

사용해야만 한다.

# alog -t boot -o

이 단계에서는 콘솔이 사용 불가능하므로 모든 부팅 정보는 이 파일에 수집된다.


rc.boot 2가 완료되면 rootvg의 /, /usr, /var 파일시스템이 활성화 된다.


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 10 / 60

4.4. 마지막 단계

이 단계에서 AIX 커널은 RAM파일시스템을 제거(미사용 메모리 공간으로 돌림)하고 rootvg

의 루트(/)파일시스템으로부터 init 프로세스를 시작한다.


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 11 / 60

5. rc.boot 3



LED에 553(BOOT PHASE 1 COMPLETE)이 나타남으로써 rc.boot 2단계가 완료되었다면,

rc.boot 3단계가 시작되었다는 것을 추측해 볼 수 있다. 이 부팅 단계에서 /etc/init 프로세스

가 시작된다. init은 /etc/inittab 파일을 읽고 한 줄씩 명령을 실행한다. rc.boot는 3번째로 실

행되고 마지막 부팅 단계를 나타내는 변수 값 3이 넘어간다.

rc.boot 3은 [표 5-1]의 작업들을 실행한다.

순 번 동 작

1 /tmp 파일시스템이 확인되고 올라온다.

2

rootvg가 syncvg rootvg에 의해 동기화된다. 만약 rootvg가 비정상 파티션(예를 들면

rootvg의 일부 디스크가 비활성)을 포함하고 있다면, 이 파티션들은 갱신되고 동기화

되어야 한다. syncvg는 후순위 작업(background job)으로 시작된다.


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 12 / 60

3

구성 관리자가 다시 호출된다. 키 스위치(key switch)나 부팅 모드가 일반이라면,

cfgmgr은 -p2(2단계) 옵션과 함께 호출된다. 만약 키 스위치나 부트 모드가 서비스라

면, cfgmgr은 -p3(3단계) 옵션과 함께 호출된다.

4 구성 관리자는 ODM 객체 Config_Rules에서 읽고 2단계나 3단계의 모든 방법들을 실

행한다. 기본 장치가 아닌 남아있는 모든 장치들이 이 단계에서 구성된다.

5

cfgcon에 의해서 콘솔이 구성된다. 콘솔 유형에 따라 다음 숫자들이 출력된다.

− c31 : 아직 콘솔 구성 안됨. 콘솔 선택 명령 제공.

− c32 : lft(그래픽 출력) 터미널 콘솔

− c33 : tty 콘솔

− c34 : 콘솔은 디스크의 파일임

만약 CDE가 /etc/inittab에 명시되어 있다면, CDE는 시작될 것이고 부팅 시 콘솔에 그

래픽이 나타난다.

6 부트 논리 볼륨의 ODM이 루트(/)파일시스템과의 동기화를 위해 savebase가 호출된다.





작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 13 / 60

ODM이 다시 동기화 된 후, [표 5-2] 작업이 진행된다.

순 번 동 작

1

syncd 데몬이 시작된다. 디스크에 기록되는 모든 데이터가 디스크에 기록되기 전 메모

리 캐시에 먼저 저장된다. syncd 데몬은 캐시 데이터를 60초마다 디스크에 기록한다.

또 다른 데몬 프로세스인 errdemon 데몬이 시작된다. 이 프로세스는 어플리케이션 에

러 발생 시 커널이 에러 로그를 기록하도록 한다.

2 LED 출력이 꺼진다.

3 /etc/nologin 파일이 존재한다면 제거된다. 만약 시스템 관리자가 이 파일을 생성한다

면, AIX 장비에 접속(login)이 불가능해 진다. 부팅과정 동안 /etc/nologin은 제거된다.

4

CuDv에 장치가 존재하지 않는다는 표시(chgstatus=3)가 있으면, 콘솔에 메시지가 출

력된다. 예를 들어, 시스템이 부팅되는 동안 외부 장치에 전원이 들어와 있지 않다면

발생하게 된다.

5 마지막 메시지인 System initialization completed가 콘솔에 기록되고 rc.boot3이 끝난

다. init 프로세스는 /etc/inittab의 다음 명령을 실행한다.



작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 14 / 60

6. rc.boot 요약

명 령 실 행 주요 활동 Config_Rules 단계

rc.boot 1

RAM 파일시스템

(/dev/ram0)

restbase

cfgmgr -f 1

rc.boot 2

ipl_varyon

/, /usr, /var 파일시스템 올림

ODM 파일 복사

rc.boot 3 디스크의 rootvg

/tmp 올림

cfgmgr -p2 또는 cfgmgr -p3

savebase

2=일반

3=서비스

[표 6-1] rc.boot 요약

rc.boot 1 동안 모든 기본 장치들이 구성된다. 이것은 Config_Rules의 모든 1단계 방법들을

실행하는 cfgmgr -f에 의해 완료된다.

rc.boot 2 동안 rootvg가 변화된다. RAM 파일시스템의 모든 /dev 파일들과 사용자 정의된

ODM 파일들이 디스크로 합쳐진다.

rc.boot 3 동안 cfgmgr -p에 의해 남아있는 모든 장치들이 구성된다. 구성관리자는

Config_Rules 객체를 읽어서 해당 방법들을 실행한다. ODM을 동기화하기 위해 부트논리볼륨

ODM을 디스크에 기록하는 savebase가 호출된다.


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 15 / 60

7. 손상된 파일 시스템과 로그 수리(fixing)

손상된 JFS 또는 JFS2 로그를 수리하기 위해 유지관리 모드로 부팅하고 rootvg에 접근하지만

파일시스템은 올리지 않는다. 유지관리 쉘에서 logform 명령을 입력하고 이 JFS나 JFS2 로그를

사용하는 모든 파일시스템을 확인한다.

JFS 경우 JFS2 경우

# logform -V jfs /dev/hd8 # logform -V jfs2 /dev/hd8

# fsck -y -V jfs /dev/hd1 # fsck -y -V jfs2 /dev/hd1




# fsck -y -V jfs /dev/hd9var # fsck -y -V jfs2 /dev/hd9var

# fsck -y -V jfs /dev/hd10opt # fsck -y -V jfs2 /dev/hd10opt

# fsck -y -V jfs /dev/hd11admin # fsck -y -V jfs2 /dev/hd11admin

exit exit

[표 7-1] JFS 또는 JFS2 복구

logform 명령은 JFS 트랜잭션 로그를 초기화 하고 JFS 트랜잭션을 파괴하기 때문에 데이터

손실을 초래한다. 장비는 JFS 로그가 복구된 후에 부팅될 것이다.

손상된 JFS 로그는 일반적으로 시스템 충돌이나 관리자에 의해 강제 종료될 때 발생한다.

JFS 로그 복구는 프로세스가 완료되어 디스크가 갱신되는 것을 보장하지도 보여주지도 않는

다. 무엇이 진행 중이고 무엇이 다시 시도할 필요가 있는지, 어떤 것이 완료 되었는지에 대하여

알아내는 것은 트랜잭션 로그를 사용하는 어플리케이션의 몫이다.


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 16 / 60

8. 구성 관리자

8.1. 구성 관리자 호출 시점

시스템이 부팅되는 동안 구성관리자는 구성

설정 데이터베이스에 정보가 저장된 장치뿐만

아니라 감지되는 모든 장치들을 구성하기 위해

호출된다. cfgmgr 명령을 직접 호출하여 특별한

장치 구성도 가능하다.

8.2. 자동 구성

많은 장치들이 구성 관리자에 의해 자동으로

감지된다. 그러기 위해서는 사전정의 장치 객체

클래스에 장치 항목들이 존재해야 한다. 구성

관리자는 장치 상태를 관리(장치 정의 또는 활

성화 등)하기 위해 PdDv의 방법들을 사용한다.

8.3. 새로운 장치 지원 설치

cfgmgr은 새로운 장치 지원을 설치할 때 사용할 수 있다. 만약 cfgmgr을 -i 옵션과 함께

호출하면, 명령은 각각의 새로 감지된 장치에 대해서 장치 소프트웨어 지원을 설치하려고 시

도한다.

mkdev와 같은 고수준 장치 명령어는 방법들을 호출하여 사용자로 하여금 장치 속성을 추

가, 삭제, 출력, 변경할 수 있게 해준다.

8.4. 방법 정의

정의 방법을 통해 장치가 정의될 때, 장치유형에 관한 사전정의 데이터베이스의 정보는 장

치의 상세정보를 생성하기 위해 사용된다. 상세 정보는 사용자정의 데이터베이스에 저장된다.

8.5. 구성 방법 단계

장치를 구성하는 과정은 종종 장치에 특화되어 있다. 커널 장치에 구성하는 방법은 반드시

다음 3가지를 따른다.

− 커널에 장치 드라이버 올리기

− 드라이버로 장치를 설명하는 장치 종속 정보 전달

− /dev 디렉토리안에 장치에 대한 특별한 파일 생성

물론 논리 볼륨이나 볼륨 그룹과 같은 많은 장치들이 물리적 장치가 아니다. 이들을 모조

장치(pseudodevices)라고 한다. 이러한 유형의 장치들에 대한 구성 상태는 중요하지 않다. 하

지만 여전히 구성된 장치라고 간단히 표시하는 구성 방법이 있으며, 모조장치에 부착된 다른

[그림 8-1] 구성관리자


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 17 / 60

장치가 있는지 확인하기 위해서 좀 더 복잡한 작업을 수행하는 구성 방법도 있다.

8.6. 구성 순서

구성 프로세스는 장치가 부착되기 전에 정의되거나 구성되는 것을 요구한다. 시스템이 부

팅될 때, 구성 관리자는 계층 구조로 시스템을 구성한다. 가장 먼저 마더보드가 구성되고, 버

스, 부착된 어댑터들이 구성되며 마지막으로 어댑터에 연결된 장치들이 구성된다. 그 후, 구

성관리자는 필요한 모조장치들(볼륨 그룹, 논리 볼륨 등)을 구성한다.


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 18 / 60

9. Config_Rules 객체 클래스

9.1. 소개

Config_Rules ODM 객체 클래스는 부

팅 과정 동안 cfgmgr에 의해 사용된다.

phase 속성은 각각의 방법이 언제 호출

될지를 결정한다.

9.2. 1 단계(Phase 1)

cfgmgr -f가 호출되면 phase=1의 모든

방법들이 실행된다. 시작된 첫 번째 방법

은 모든 기본 장치의 구성에 책임이 있

는 /etc/methods/defsys이다. 두 번째 방

법인 /usr/lib/methods/deflvm은 논리볼

륨 장치 드라이버(logical volume device

driver : LVDD)를 AIX 커널에 올린다.

만약 rootvg가 활성화 되기 전을 의미

하는 rc.boot 1에서 구성되어야만 하는

장치가 있다면, phase 1 구성 방법을

Config_Rules에 둘 필요가 있다. bosboot

는 그 다음에 요구된다.

9.3. 2 단계(Phase 2)

cfgmgr -p2가 호출되면 phase=2의 모

든 방법들이 실행된다. PCI 장비가 일반

부트이거나 키 스위치가 일반 위치일 때,

rc.boot의 세 번째 단계이다. seq 속성은

실행 순서를 제어한다. 낮은 값일수록 높

은 우선순위이다.

9.4. 3 단계(Phase 3)

cfgmgr -p3이 호출되면 phase=3의 모든 방법들이 실행된다. 키 스위치가 서비스 위치이거

나 PCI 시스템이 서비스 부팅일 경우의 세 번째 rc.boot 단계이다.

9.5. 순차 번호(Sequence number)

각각의 구성 방법은 순차 번호와 연관되어 있다. 특정 단계의 방법들이 실행될 때, cfgmgr

[그림 9-1] Config_Rules 예


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 19 / 60

은 순차 번호 순으로 방법들을 정렬한다. 방법들은 순차 번호가 작은 순으로 하나씩 호출된

다. 순차 번호가 0인 방법은 다른 모든 방법들이 호출된 이후에 마지막으로 호출된다.

9.6. 부팅 마스크(Boot mask)

각각의 구성 방법은 부팅마스크와 관련되어있다.

− boot_mask가 0일 경우 모든 부팅 유형에 규칙이 적용된다.

− boot_mask가 0이 아니라면, 특정 부팅 유형에만 규칙이 적용된다. 예를 들어, 만약

boot_mask = DISK_BOOT 라면, 규칙은 디스크로 부팅시에만 사용될 것이고,

NETWORK_BOOT일 경우에는 네트워크를 통한 부팅 시에만 적용될 것이다.


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 20 / 60

10. alog를 사용하는 부트 로그에서 cfgmgr 출력

[그림 10-1] 부트 로그의 예

10.1. 부트 로그

부트 단계 동안 콘솔이 사용 불가능하므로 부트 메시지들은 기본으로 설정되어있는

/var/adm/ras/bootlog라는 특별한 파일에 수집된다. [그림 10-1]과 같이 alog 명령을 사용하여

이 파일의 목록을 볼 수 있다. [그림 10-1]은 명령어 출력의 예를 보여준다.

만약 부팅에 문제가 있다면, 부팅 오류 메시지를 담고 있는 alog 부트 파일을 확인하는 것

이 좋다. cfgmgr의 모든 출력은 부트 로그에 보여질 뿐만 아니라 rc.boot 스크립트에 의해 만

들어진 다른 정보들까지 볼 수 있다.

AIX 5L V5.1에서 기본으로 설정되어 있는 부트 로그 파일은 AIX 5L의 모든 시스템 부트 출

력을 저장하기에는 너무 작은 크기이다(8 KB). AIX 5L V5.2의 기본 부트로그 크기는 32 KB이고

AIX 5L V5.3 이후에는 128 KB이다. 만약 부트로그의 크기를 256 KB로 늘리고 싶다면 [그림

10-2]와 같이 입력한다.

[그림 10-2] 부트로그 크기 변경


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 21 / 60

11. /etc/inittab file

[그림 11-1] inittab 파일 내용의 예

11.1. 목적

/etc/inittab 파일은 init 프로세스에 관한 정보를 제공한다. 부팅 과정에서 남아있는 모든

장치를 구성하기 위해 어떻게 rc.boot 스크립트가 inittab 파일 밖에서 실행되는지를 주목한다.

11.2. 변경

/etc/inittab 파일을 변경하기 위해 편집기를 사용해서는 안 된다. /etc/inittab에서의 작은

실수는 장비를 부팅될 수 없게 만든다. 편집기 대신 /etc/inittab 파일을 수정하려면 mkitab,

chitab, rmitab 명령을 사용한다. 이 명령어들의 장점은 항상 손상되지 않은 /etc/inittab 파일

을 보장한다는 것이다. 만약 장비가 부팅 과정에서 553의 LED 출력과 함께 정지했다면, 대부

분 /etc/inittab 파일이 손상된 것이다. LED의 553코드는 대부분 inittab 수행 중에 에러가 발

생하면 나타난다.

[그림 11-2] inittab 파일 변경 방법의 예

11.3. 보기

lsitab 명령은 /etc/inittab 파일을 볼 수 있게 해준다.


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 22 / 60

[그림 11-3] inittab 파일 보기의 예

만약 /etc/initab 파일의 전체 내용을 보려면 [그림 11-1]과 같이 lsitab -a 명령을 사용한다.

11.4. telinit와 실행단계(run levels)

init 데몬에 신호를 보내기 위해 telinit 명령을 사용한다.

− init데몬이 /etc/inittab을 다시 읽음

→ # telinit q

− init데몬이 다른 실행단계로 환경을 재설정함

→ # telinit n (n : 실행 단계)

− 현재 실행단계 확인

→ # who -r


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 23 / 60

12. 부팅 장애 관리

12.1. 소개

증상 또는 LED 코드 원 인 조 치

AA060011

메시지: Can’t find OS Image

부트리스트 손상

BLV 손상

SMS 부팅, 부트리스트 갱신.

유지관리 모드 부팅, rootvg 접

근. BLV 재생성.

# bosboot -ad /dev/hdiskX

551, 555, 557

파일시스템 또는 로그 손상 저널 로그 재건 및 fsck 파일시

스템.

rootvg 잠김(551 경우) rootvg 잠금 해제.

(chvg -u rootvg)

552, 554, 556 파일시스템 슈퍼블록 손상

ODM 손상

저널 로그 재건 및 fsck 파일시

스템.

또는 두 번째 슈퍼블록으로 복구

실패 시, mksysb 복구.

553 /etc/inittab 손상

/etc/environment 손상

rootvg 접근. /etc/inittab 확인.

(손실 또는 손상?)

/etc/environment 확인.

523 ~ 534 ODM 파일 손실 ODM 파일 손실 또는 접근불가.

시스템백업에서 손실파일 복원.

517, 518 파일시스템 올리기 실패

(/usr, /var, /tmp)

/etc/filesystem 확인.

네트워크(원격일 경우), 파일시스

템(fsck), 하드웨어 확인.

[표 12-1] AIX 소프트웨어 부팅 중 발생하는 일반적인 부팅 장애

12.2. 부트리스트 손상?

만약 부트리스트가 손상되면 시스템은 부팅할 수 없다. 이 경우 해결하는 것은 쉽다. SMS

로 부팅 후, 올바른 부트 장치를 선택한다. 부트 기록(boot records)을 가진 하드디스크만 선

택 가능한 부트 장치로 나타난다는 것을 명심해야 한다.

12.3. /etc/inittab 손상? /etc/environment 손상?

553 LED 코드는 일반적으로 /etc/inittab 파일의 손상을 나타내지만, 가끔 /etc/environment

가 손상된 경우에도 553 LED가 나타난다. 이 문제를 해결하기 위해서는 유지관리 모드로 부

팅 후, 두 파일을 확인한다. mksysb를 사용하여 백업 테이프로부터 복원하는 것도 고려한다.


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 24 / 60

12.4. 부트 논리 볼륨 또는 부트 기록 손상?

그래도 장비가 부팅되지 않는다면, 그 다음으로 부트 논리 볼륨을 확인한다. 손상된 부트

논리 볼륨을 수리하기 위해서 유지관리 모드로 부팅한 후, bosboot 명령을 사용한다.

# bosboot -ad /dev/hdisk0

12.5. JFS 로그 또는 JFS2 로그 손상?

손상된 JFS나 JFS2 로그를 수정하려면, 유지관리 모드로 부팅 후, rootvg에 접근하지만 파일

시스템은 올리지 않는다. 유지관리 쉘에서 logform 명령을 실행하고 JFS나 JFS2 로그를 사용

하는 모든 파일 시스템을 확인한다. rootvg가 어떤 파일시스템 유형을 갖고 있는지 잊지 않아

야 한다.

logform 명령은 새로운 JFS 트랜잭션 로그로 초기화 하고 이것은 JFS 트랜잭션을 파괴하기

때문에 데이터 손실을 유발한다. 장비는 JFS로그가 복구된 후, 부팅될 것이다.

12.6. 슈퍼블록(Superblock) 손상?

rootvg 파일시스템의 슈퍼블록을 확인하는 또 다른 방법이 있다. 만약 유지관리 모드로 부

팅했는데 ‘Not an AIX file system’이나 ‘Not a recognized file system type’와 같은 오류 메시지

를 받았다면, 아마도 파일시스템의 슈퍼블록이 손상된 것이라고 볼 수 있다.

각각의 파일시스템은 두 개의 슈퍼블록을 갖고 있다. fsck를 실행하면 자동으로 백업 슈퍼

블록에서 주요 슈퍼블록으로 복사하여 주요 슈퍼블록을 복구한다. [표 12-2]는 이것을 수동으

로 진행하는 과정이다.

유 형 조 치

JFS

주요 슈퍼블록은 논리 블록 1에 있으며 복사본은 논리 블록 31에 있다. 블록 31에서

블록 1로 슈퍼블록을 수동으로 복사하기 위해서 다음 명령을 입력한다.

# dd count=1 bs=4k skip=31 seek=1 if=/dev/hd4 of=/dev/hd4

JFS2

JFS와 위치가 다르다. 백업 슈퍼블록으로부터 주요 슈퍼블록을 수동 복구하기 위해서

는 다음 명령을 입력한다.

# dd count=1 bs=4k skip=15 seek=8 if=/dev/hd4 of=/dev/hd4

참고 위 방법으로 안되면 파일시스템을 복구한다.

[표 12-2] 슈퍼블록 수동 복구

12.7. rootvg 잠김?

많은 LVM 명령어들은 동시에 다른 명령어들이 작업하는 것을 막기 위해 ODM을 잠금 상

태로 만든다. 명령어의 충돌에 의해 ODM이 잠금 상태로 남아있게 되면 시스템이 정지된다.

rootvg의 잠금을 해제하기 위해, 유지관리 모드로 부팅하고 파일 시스템과 함께 rootvg에


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 25 / 60

접근한다. 그 후, rootvg의 잠금을 해제하기 위해 다음 명령어를 입력한다.

# chvg -u rootvg

12.8. ODM 파일 손실?

LED 코드가 523에서 534 사이를 나타낸다면, 장비의 ODM 파일이 손실된 것이다. 손실된

파일을 복구하기 위해 시스템의 mksysb 테이프를 사용한다.

12.9. /usr 또는 /var 올리기(mount) 실패

LED의 518 코드는 /usr이나 /var 파일시스템을 올릴 수 없다는 것을 나타낸다. /usr이 네트

워크로 올라온다면, 네트워크 연결을 확인한다. /usr이나 /var이 내부적으로 올라온다면, fsck를

사용하여 파일 시스템의 일관성을 확인한다. 그래도 도움이 안된다면, 진단 CD를 사용하여

하드웨어 진단을 수행한다.


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 26 / 60

13. 실습

13.1. 손상된 논리볼륨 로그 복구

생성되거나 갱신된 파일 또는 디렉토리들은 i-노드와 함께 저장되고 파일 시스템의 슈퍼블

록은 먼저 메모리에 들어간다. 대부분의 쓰기 요청은 시스템 성능 향상을 위해 메모리에서

먼저 다뤄진다. 그 후, syncd 데몬(매 60초마다)이나 더러운 메모리 페이지의 임계 값 초과(예

를 들면 16 KB 변경 마다) 때문에 데이터가 디스크에 기록된다.

데이터가 디스크에 기록되기 직전, JFS 파일시스템에서의 이러한 변화(슈퍼블록, i-노드, 자

유 데이터 블록의 리스트 등)는 논리볼륨 로그에 기록된다. 기본적으로 rootvg는 논리볼륨 로

그 /dev/hd8을 사용한다. 변경사항이 디스크에 기록될 때, JFS 트랜잭션들은 논리볼륨 로그로

부터 제거된다. 이것은 파일시스템의 무결성을 보장한다. 파일시스템 변경이 디스크에 기록될

때까지 변경사항들은 논리볼륨 로그에 기록되고 유지된다.

13.1.1. rootvg의 파일시스템 유형 확인

rootvg 파일시스템이 JFS인지 JFS2인지 확인한다. 이 정보는 나중에 다시 필요하다.

[그림 13-1] rootvg 파일시스템 유형

13.1.2. 논리볼륨 로그 손상 유발

다음 내용과 같은 스크립트를 생성한다.


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 27 / 60

[그림 13-2] 논리볼륨 로그 손상 스크립트

이제 위에서 만든 손상 스크립트를 실행한다. 이 프로그램은 대략 30초 정도 소요된다. 그

리고 장비를 정지시킨다. Halt Completed라는 메시지가 나타나면 HMC 웹 브라우저로 이동한

다.

[그림 13-3] 스크립트 실행 결과

13.1.3. LPAR 상태 확인

LPAR를 다중 사용자 모드로 활성화 해보도록 한다. 우선 해당 파티션을 선택한다. 작은

메뉴 아이콘이 나타나면, 클릭하여 하위 메뉴 중에서 조작(Operations)의 활성화(Activate)를

선택한다.


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 28 / 60

[그림 13-4] LPAR 활성-1

논리 파티션 활성창이 나타나면 ‘단말기 창 또는 콘솔 세션 열기(Open a terminal

window or console session)’에 체크한다. 그리고 ‘확인(OK)’를 클릭한다.


그러면 콘솔 창이 열리면서 부팅이 시작된다. 하지만 부팅이 완료되지 않고 HMC의 참조

코드는 557에서 바뀌지 않는다. 557 참조코드는 /dev/hd4(root 파일시스템)를 올릴 수 없다

는 것이다.


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 29 / 60


13.1.4. LPAR 종료

다시 해당 파티션을 선택하여 메뉴 중에서 조작(Operations) 밑의 시스템 종료(Shutdown)

을 선택한다.

[그림 13-7] LPAR 종료-1

파티션 종료 창이 나타나면 ‘즉시(Immediate)’를 선택 후 확인(OK)를 누른다.


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 30 / 60

[그림 13-8] LPAR 종료-2

13.1.5. SMS 모드를 통한 NIM 부팅

파티션이 비활성화 되면, 장비를 다시 활성화 한다.



작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 31 / 60

콘솔 창에 다음과 같은 화면이 나오면 재빨리 ‘1 =SMS Menu’를 선택한다(LPAR 활성 시,

고급 항목에서도 선택가능).

[그림 13-10] SMS 선택


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 32 / 60

SMS의 메뉴가 나타나면 2번 ‘Setup Remote IPL’ 항목을 선택한다.

[그림 13-11] SMS 작업-1


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 33 / 60

사용 가능한 어댑터를 선택한다.

[그림 13-12] SMS 작업-2


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 34 / 60

IP 설정을 위해 1번 ‘IP Parameters’를 선택한다.

[그림 13-13] SMS 작업-3


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 35 / 60

사용할 IP 값을 입력해 준다.

[그림 13-14] SMS 작업-4


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 36 / 60

서버와의 통신 상태를 확인하기 위해 ping 테스트를 한번 해준다.

[그림 13-15] SMS 작업-5


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 37 / 60

설정 정보를 다시 한번 확인 후, 1을 입력하여 ‘Execute Ping Test’를 실행한다.

[그림 13-16] SMS 작업-6

ping 테스트가 성공하였는지 확인한다.

[그림 13-17] SMS 작업-7


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 38 / 60

처음 메뉴로 돌아와서 5번 ‘Select Boot Options’를 선택한다.

[그림 13-18] SMS 작업-8


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 39 / 60

1번 ‘Select Install/Boot Device’ 항목을 선택한다.

[그림 13-19] SMS 작업-9


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 40 / 60

NIM을 통해 부팅할 것이므로 6번 ‘Network’ 장치 유형을 선택한다.

[그림 13-20] SMS 작업-10


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 41 / 60

사용할 장치를 선택한다.

[그림 13-21] SMS 작업-11


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 42 / 60

진행할 작업을 선택한다. 2번 ‘Normal Mode Boot’를 선택한다.

[그림 13-22] SMS 작업-12


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 43 / 60

SMS 종료를 묻는 문구가 나오면 1번 ‘Yes’를 선택해서 종료한다.

[그림 13-23] SMS 작업-13


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 44 / 60

tftp를 통해 전송이 완료되면 NIM 서버를 이용해 부팅이 완료된다.

[그림 13-24] NIM 부팅 과정

13.1.6. 유지관리 모드

시스템 콘솔을 정의한다.

[그림 13-25] 콘솔 정의

유지관리에서 사용할 언어를 선택한다.

[그림 13-25] 언어 정의


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 45 / 60

유지관리 모드의 메뉴로 들어온 후, 파일시스템을 올리지 않고 rootvg에 접근해야 한다.

왜냐하면 논리 볼륨 로그가 손상되었으므로 rootvg의 파일시스템을 올릴 수 없기 때문이다.

따라서 1번 ‘Access a Root Volume Group’ 항목을 먼저 선택하여 들어간다.

만약 매체를 이용하여 부팅했다면 ‘Welcome to the Base Operating System Installation

and Maintenance’ 문구를 볼 수 있다. 이럴 땐, ‘Start Maintenance Mode for System

Recovery’ 항목을 선택하여 들어가면 유지관리 모드의 메뉴를 볼 수 있다.

[그림 13-26] 유지관리 모드의 작업-1


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 46 / 60

경고 메시지가 나오면 0을 입력하여 계속 진행한다.



작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 47 / 60

문제가 발생한 볼륨 그룹을 선택한다.



작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 48 / 60

2번 ‘Access this Volume Group and start a shell before mounting filesystems’를 선택하여

파일시스템을 올리지 않고 볼륨 그룹에 접근한다.



작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 49 / 60

rootvg에 변화가 생기는 동안 에러 메시지들이 나타나면서 문제에 대한 더 많은 단서들

을 제공해 준다.


13.1.7. 복구하기

논리 볼륨 저널 로그의 구성 방식을 새로 만든다. /dev/hd8을 사용하는 모든 파일시스템

에 대해서 확인한다. 현재 rootvg의 파일 시스템 유형이 JFS2이므로 이에 맞는 명령어를 입

력한다.

가장 먼저 logform 명령을 입력한다.

[그림 13-31] 복구과정-1


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 50 / 60

hd1에 대해서 fsck를 실행한다.

[그림 13-32] 복구과정-2


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 51 / 60


[그림 13-33] 복구과정-3


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 52 / 60


[그림 13-34] 복구과정-4


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 53 / 60


[그림 13-35] 복구과정-5


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 54 / 60

hd9var에 대해서 fsck를 실행한다.

[그림 13-36] 복구과정-6


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 55 / 60

hd10opt에 대해서 fsck를 실행한다.

[그림 13-37] 복구과정-7


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 56 / 60

hd11admin에 대해서 fsck를 실행한다.

[그림 13-38] 복구과정-8

모두 완료되었으면 시스템을 다시 시작한다.

[그림 13-39] 복구과정-9

만약 부팅이 실패한다면, HMC의 참조코드를 확인한다. 같은 코드가 나타나면 위 과정을

다시 진행한다. 새로운 참조코드(553)가 나타나면 다음 과정인 ’13.2. 부팅 실패 분석 및 해

결’ 을 진행한다.

[그림 13-40] 복구과정-10

13.2. 부팅 실패 분석 및 해결

13.2.1. 유지관리 모드

시스템이 참조코드 553 값을 보이면서 정지했다. 이것은 손상된 /etc/inittab와 관련이 있


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 57 / 60

다.

발생 가능한 또 다른 증상은 실행 단계(run level)를 묻는 AIX 시스템 콘솔이 나타나는 것

이다. 다중 사용자 실행 단계(multi-user run level)인 2를 응답할 경우, 시스템은 아무런 메

시지나 에러 코드 없이 멈출 것이다.

이와 같은 상황에서 가장 먼저 할 일은 시스템을 유지관리 모드로 부팅하는 것이다. 이

를 위해서 13.1 과정과 같이 NIM을 이용하여 유지관리 모드로 부팅한다. 우선 시스템을

SMS 모드로 진입한다.(13.1. 과정과 동일)

[그림 13-41] SMS 부팅

SMS 모드로 진입하였다면, 다음으로는 NIM 서버를 이용해 시스템을 유지관리 모드로

부팅한다.(13.1. 과정과 동일)

[그림 13-42] NIM 서버를 이용하여 부팅


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 58 / 60

유지관리 모드로 부팅 후, 문제가 있는 볼륨 그룹에 접근하는 방법을 선택하기 전까지는

13.1. 과정과 동일하다.


이번에는 rootvg에 접근 시 파일시스템도 함께 올리는 방법을 선택한다. 앞서 13.1 과정에

서 파일시스템을 모두 복구하였기 때문에 정상적으로 올라올 것이다. 지금은 inittab파일이 손

상되어서 부팅이 실패하는 것이므로 파일시스템을 함께 올려야 한다.

1번 ‘Access this Volume Group and start a shell’을 선택한다.


13.2.2. inittab 복구

쉘로 진입하였다면, 부팅 실패를 야기한 손상된 파일을 찾아서 조사한다. 이때 TERM 변

수값을 lft 또는 vt320으로 설정한다. 그렇지 않으면 vi나 SMIT가 유지관리 쉘 에서 정상적

으로 동작하지 않을 것이다.

[그림 13-45] TERM 변경


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 59 / 60

/etc/inittab 파일이 손상된 것이므로 이 파일을 vi에디터를 통해 열어본다.

[그림 13-46] inittab 열기

inittab 파일을 살펴보면 13.실습의 처음 실행했던 스크립트에 의해 콜론이 모두 세미콜

론으로 바뀐 것을 볼 수 있다. 따라서 ‘:%s/;/:/g’를 이용하여 세미콜론을 다시 콜론으로 바

꿔준다.

[그림 13-47] inittab 수정


작성자 : 이 현 수 최종수정일 : 2014-10-17

페이지 60 / 60

inittab 파일을 정상적으로 수정을 완료하였다면, 저장 후 나온다. 그 후, 시스템을 다시

시작한다.

[그림 13-48] 시스템 다시 시작

시스템이 정상적으로 부팅된다면 모두 복구된 것이다. HMC에서도 오류코드가 없으며, 콘

솔 창에서도 정상적으로 로그인 창이 나타난다.

[그림 13-49] 복구 완료

POWER SYSTEMS FOR AIX III · 2015-04-21 · 과 목 명 Power Systems for AIX III: Advanced...

Documents

Transcript of POWER SYSTEMS FOR AIX III · 2015-04-21 · 과 목 명 Power Systems for AIX III: Advanced...