리눅스 부팅 과정과 커널 패닉 조치요령
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이 뜨면서 커널패닉이 발생할 것이다. 이럴때는 파일 시스템을 체크해서 복구해야 한다. 평소에 부팅할 때 보여지는 메세지들을 잘 분석하고 이해해두자. 리눅스 시스템을 이해하고 트러블슈팅을 하는데 많은 도움을 준다.
링크: https://mapoo.net/os/oslinux/%EB%A6%AC%EB%88%85%EC%8A%A4-%EB%B6%80%ED%8C%85-%EA%B3%BC%EC%A0%95%EA%B3%BC-%EC%BB%A4%EB%84%90-%ED%8C%A8%EB%8B%89-%EC%A1%B0%EC%B9%98%EC%9A%94%EB%A0%B9/
