[리눅스]부트영역 복구하기

0053. [리눅스] 부트영역 복구하기

리눅스 부팅 과정과 커널 패닉 조치요령

1. 리눅스 부팅 과정 이해의 필요성

리눅스 부팅 시 커널패닉이나 파일시스템 에러 같은 경우를 만났을 때 어떻게 해야 할지 몰라 당황하는 경우가 있다. 리눅스 부팅 과정의 이해를 통해 이러한 에러 상황을 효과적으로 대처 할 수 있다.

2. 리눅스 부팅 과정의 이해

1) 전원 ON

2) BIOS 프로그램 실행 – CPU, MEMORY, VGA 같은 하드웨어에 대한 진단 테스트(POST)를 실행한다. 이상 발생시 비프 음을 내며 멈춘다. POST(Power On Self Test)과정이 이상없이 수행되면 부트디바이스의 MBR(하드 디스크의 첫 섹터,크기는 512 byte)에서 부트로더를 불러들인다.

3) 부트로더가 실행되면 레드햇계열에서는 보통 다음과 같은 메시지가 출력되며 GRUB(GRUB이 부트로더이다)이 실행된다. GRUB은 커널이미지를 메모리에 로드한다.

Booting Red Hat Enterprise Linux Server (2.6.18-8.el5) in 5 seconds...

4) 그 다음 커널에 의한 초기화가 실행되고 드라이버의 적재가 이루어 진다. 이 과정은 dmesg명령이나 /var/log/dmesg 파일에서 확인 할 수 있다. 보통 다음과 같은 것들을 확인 할 수 있다.

커널버전 표시

램 용량 표시

CPU관련 정보 표시

SELinux 상태 표시

Kernel command line 명령 확인

램디스크 할당 (initramfs)

하드드라이브와 파티션 확인

네트워크 카드 확인

파일시스템 활성화

스왑 활성화

5)커널과 드라이버가 로드된 다음에는 /sbin/init 프로세스가 부팅 과정을 마무리 한다. 이때 실행되는 순서를 간략하게나마 나열하면

/sbin/init à /etc/inittab à /etc/rc.d/rc.sysinit à 각 런 레벨 서비스 스크립트

--> /etc/rc.local à 로그인 프롬프트

로 나타낼 수 있다.

3. 각 과정 별 트러블슈팅

1) grub.conf 파일이 손상되거나 내용이 변경되었을때

증상

부팅시 GURB관련 메뉴가 나오지 않음

부팅시 GRUB 콘솔 상태로 바로 이동

mv /boot/grub/grub.conf /boot/grub/grub.conf_bak

해결방법

GRUB 콘솔 명령어로 사용하여 부팅

grub 환경설정파일 손상

root (hd0,0)

cat /etc/fstab

find /etc/fstab

kernel /vmlinuz-2.6.18-92.el5 ro root=/dev/sda7

initrd /initrd-2.6.18-92.el5.img

boot

부팅후 GRUB관련 설정을 점검하고 원인을 찾아 해결한다.

GRUB을 재 설치 한다.

2) MBR 손상시 복구하기

BIOS가 POST과정을 끝마치면 하드디스크의 첫번째 섹터를 읽어드린다. 이부분을 MBR이라고 한다. MBR에는 부트로더와 파티션 정보가 들어있다. 다음과 같은 명령어로 부트로더를 지울 수 있다.

dd if=/dev/zero of=/dev/sda bs=446 count=1

bs를 512로 하면 파티션 정보까지 모두 손상되므로 테스트 서버 외에는 절대 실행하면 안된다. GRUB(부트로더)는 446바이트이내에 설치 되어 있다.

이제 복구를 해보자.

1번 시디로 부팅

#linux rescue

#chroot /mnt/sysimage

#/sbin/grub

grub-install /dev/sda

find /grub/stage1

find /grub/grub.conf

혹은

#/sbin/grub

root (hd0,0)

setup (hd0)

위와같이 GRUB을 재설치하고 리부팅한다.

3) /etc/fstab 손상시

cat /proc/mounts

mount –o remount,rw /

cat /proc/mounts

vi /etc/fstab

에러난 부분 수정후 리부팅

4)/sbin/init 명령어 손상시

rm /sbin/init

/bin/sh: ro: No such file or directory

Kernel panic - not syncing: Attempted to kill init!

SysVinit-2.86-14.i386.rpm 재설치

# linux rescue

#chroot /mnt/sysimage

#ftp 222.239.223.108

#cd centos/5.2/CentOS

#mget Sys*

rpm -Uvh –force SysVinit-2.86-14.i386.rpm

rpm -Vf /sbin/init

chroot /mnt/sysimage

/bin/bash 파일 손상시 다음과 같은 에러 메시지가 나온다.

chroot: cannot run command '/bin/sh' : No such file or directory

#ftp 222.239.223.108

#cd centos/5.2/CentOS

#mget bash*

rpm -Uvh --force --root=/mnt/sysimage bash-*.rpm

기타

/etc/initab, /etc/rc.d/rc.sysinit à initscripts-8.45.19.1.EL-1.el5.centos

주의사항: 시스템을 새로 설치하는게 빠른지 아니면 복구하는게 빠른지 판단을 하여 가장 빠른 복구 프로세스를 수행한다. 자료 백업과 보존을 최우선으로 한다. 가장 안전한 방법을 고른다.

4. 파일 시스템 오류검사 및 복구 요령

파일 시스템이 손상되었을 때 부팅중 문제가 발생 할 수 있다. 파일 시스템이 손상 되었을때의 대표적인 증상은 아래와 같다.

1) 파티션이 Read Only로 마운트 되면서 파일이 생성되지 않는다.

2) 부팅 과정 중 Ctrl+D 입력을 요구 하면서 더 이상 진행이 되지 않는다.

3) 파일시스템이 손상되었을 경우 dmesg명령어나 /var/log/messages에 에러가 남는다.

이러한 상황이 발생 했을 때 fsck명령으로 쉽게 복구 할 수 있다. 다만 파일시스템을 복구할 때 몇 가지 주의 사항이 있는데 이를 지키지 않을 시 데이터를 날려버릴 위험이 있으므로 반드시 다음 주의 사항을 지키면서 복구를 해야 한다.

먼저 파일 시스템을 마운트 시킨 상태에서 복구를 해서는 안된다.

df –h

cat /proc/mounts

명령으로 손상된 파티션이 마운트 되어 있는지 확인한다.

마운트 되어 있으면 umount 시킨 상태에서 복구 명령을 실행 시켜야 한다.

그러면 / 파티션 같은 경우에는 어떻게 복구해야 할까? / 파티션을 umount 시킨다면 복구명령을 실행 할 수 없으니 이런 의문이 당연히 떠 오를 것이다. 이럴때는 다음과 같이 / 파티션을 Read Only로 remount 시킨다음 체크를 실행한다.

#cat /proc/mounts

/dev/root / ext3 rw,data=ordered 0 0

와 같은 줄이 보인다. 다음 명령으로 / 파티션을 Read Only로 마운트 시킬 수 있다.

#mount -o remount,ro /

/dev/root / ext3 ro,data=ordered 0 0

/var /usr 파티션 같은 경우 다음과 같은 에러를 내면서 umount가 되지 않을 수도 있다. /usr 파티션이 사용되고 있기 때문이다.

umount /usr

umount: /usr: device is busy

umount: /usr: device is busy

그러므로 가장 확실한 방법은 잠시 서비스를 내리고 다음과 같이 1번 시디를 이용해서 rescue모드로 부팅을 해서 복구하는 방법이다.

#linux rescue nomount

/dev/sda1 파티션이 ext3 파일 시스템을 사용 하고 있을 때 다음과 같은 명령어로 복구 시킬 수 있다.

#e2fsck –j ext3 –vy /dev/sda1

badblock이 생겼을 때는 -c옵션을 주면 badblock을 체크한다. 그러나 가능하면 badblock이 생겼을 경우 빠른 시간내에 하드를 교체하는 것이 최선이다.

또한 손상 정도가 심한 경우는 파일시스템을 복구해도 차후 같은 증상을 가져 올 수 있기 때문에 서비스를 올린다음 해당 디스크를 교체하는 것이 좋다.

superblock이 손상되었을 경우 다음과 같은 명령어로 복구 시킬 수 있다.

#dumpe2fs /dev/hda1

명령어로 해당 파티션이 정보를 본다. 슈퍼블럭을 확인하고 다음과 같이 복구한다.

#fsck -b 8193 /dev/hda1

슈퍼블럭은 여러 백업본이 있기 때문에 하나가 안되면 다음과 같이 다음 슈퍼블럭을 선택해서 복구하면 된다.
#fsck -b 32768 /dev/hda2

5. 커널패닉이 발생했을 때 위에서 설명한 부팅 과정중 어디에서 에러가 나는지 찾을 수 있어야 한다

그러면 더욱 쉽게 문제점을 해결 할 수 있다. 일단 서버가 돌아가고 있는 상태라면 서버에 리눅스를 처음으로 설치 할 때는 커널 패닉이 없었다는 말이다. 그 뒤에 변화된 환경에 의해 커널패닉이 발생한 것이다.

부팅 할때 발생하는 커널패닉 메세지를 잘 보면 이에 대한 힌트가 담겨 있다. 만약에 운영체제 설치시 하드 디스크 사타 드라이버나 기타 레이드 카드 드라이버를 설치했다면 커널을 업데이트 한 후에는 다시 설치해 줘야 할 것이다. 그렇지 않다면 업데이트된 커널로 부팅을 하면 커널이 드라이버를 적재하는 과정에서 하드디스크(root(hd0,0))를 인식하지 못해서 커널패닉이 발생 할 것이다. 이럴때는 제일 처음 설치할 때의 커널로 부팅을 해 보는 것도 방법이다. 하드디스크의 / 파티션이 손상을 당해서 마운트가 제대로 되지 않으면 mount fail이 뜨면서 커널패닉이 발생할 것이다. 이럴때는 파일 시스템을 체크해서 복구해야 한다. 평소에 부팅할 때 보여지는 메세지들을 잘 분석하고 이해해두자. 리눅스 시스템을 이해하고 트러블슈팅을 하는데 많은 도움을 준다.