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


 


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 손상시 복구하기


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


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


bs512로 하면 파티션 정보까지 모두 손상되므로 테스트 서버 외에는 절대 실행하면 안된다. 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 Onlyremount 시킨다음 체크를 실행한다.


 


#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이 뜨면서 커널패닉이 발생할 것이다. 이럴때는 파일 시스템을 체크해서 복구해야 한다. 평소에 부팅할 때 보여지는 메세지들을 잘 분석하고 이해해두자. 리눅스 시스템을 이해하고 트러블슈팅을 하는데 많은 도움을 준다.

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

댓글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다