[Linux] 리눅스 응급 복구하기

리눅스 응급 복구하기
작성자 : 이 상 문 <moonyL@orgio.net>
작성일 : 2003. 5. 12

리눅스를 사용하다보면, 종종 부팅이 되지 않는 경우가 발생한다. 물론 사용만 잘한다면 이러한 경우가 발생하지 않겠지만, 적어도 필자의 경우에는 수십 번의 이러한 돌발 사항이 발생하고야 말았다. 처음엔 당황하기 시작하고, 결국엔 포기하고 리눅스를 새로 설치해야만 했다. 그러나, 대부분의 경우에는 새로이 리눅스를 설치할 필요가 없는 경우이다. 적어도 필자가 경험한 경우에 대해서는 이러한 울며 시간을 낭비하는 작업을 할 필요가 없는 경우만 경험했다. 그래서, 이 글에서는 이러한 상황에서는 어떻게 대처하면 될 지에 대해서 정리해 두고자 한다.

LILO의 복구
필자는 처음에  리눅스를 설치하고픈 마음에, 무턱대고 리눅스를 설치했다. 리눅스를 사용하는 기쁨에 며칠간은 이것에 푹 빠져지냈지만, 곧 불편함을 느끼기 시작했다. 윈도우에서 제공하는 여러가지 기능과 호환되지 않는 문서 형식, 또 화려한 게임들을 해볼 수가 없었기 때문이다. 그래서 하드 디스크의 남은 파티션을 이용해서 윈도우를 설치하기 시작했다. 그런데, '아앗~!!' 이라는 비명을 지를 수 밖엔 없었다. 컴퓨터를 리부팅했을 때, 바로 윈도우만 뜰 뿐, 리눅스를 부팅할 수 있는 화면이 뜨지 않았기 때문이다. 개인주의적인 윈도우는 리눅스의 LILO처럼 다른 OS를 멀티 부팅할 수 있도록 하는 기능을 제공하지 않는다는 것을 이제서야 알았다. 노심초사 이것저것 뒤져보며 방법을 강구했다. 그 결과, 리눅스의 부팅 디스크를 이용해야 한다는 것을 알았다. 그런데, 게으른 성격의 필자가 부팅 디스크를 만들어 뒀을리가 없었다. 리눅스를 부팅을 할 수 있는 방법이라곤, 배포용으로 제공되는 리눅스 CD 밖엔... 그러나, 이것이 해결책이다. CD를 넣고 부팅해보자. '설치를 하기 위해선, linux 라는 명령을 치세요.' 뭐 대충 이런 식의 말이 나타나고, 화면에는 프롬프트 상태가 되어있을 것이다. 이것이 바로 리눅스 부트 명령 프롬프트인 것이다. 이것을 이용하면, 이전에 깔려 있던 하드 디스크 파티션을 루트 디렉토리로 해서 부팅을 할 수 있다. 프롬프트 창에서 다음과 같은 명령을 입력한다.

boot : vmliuz root=/dev/hda2
vmlinuz 라는 것은 리눅스 커널 이미지를 의미한다. 경험적으로, 필자가 예상하기로는 CD 내에 들어있는 리눅스 커널 이미지인 것 같다. root=/dev/hda2 라는 것은 하드디스크의 파티션으로 잡은 두번째 영역을 루트 파일 시스템으로 지정한다는 의미이다. 리눅스가 설치되어 있는 파티션은 사용자에 따라 다를 수 있다. 어디에 깔았는지 모르겠다면, 현재 필자가 가지고 있는 지식으론, 막노가다 방법밖엔 없다. hda2의 숫자를 1에서 차례로 증가시키면서 테스트해보기 바란다. ^^;; 아무튼, 이렇게 해서 부팅이 시작이 되면, LILO의 복구는 이제 게임 끝이라고 볼 수 있다.

리눅스가 부팅이 되면, 예전의 사용하던 리눅스 그대로 부팅이 된다. 물론, 부팅에 사용했던 리눅스 이미지 자체가 현재 하드 디스크에 저장되어있는 리눅스 이미지와는 다르기 때문에, 몇 가지 장치가 사용되지 않는 그런 상황은 발생할 수 있다. 그렇지만, LILO만 복구해주면, 원래 커널 이미지로 부팅할 수 있기 때문에, 별 문제가 되지 않는다. LILO만 복구하고 다시 리부팅만 하면 된다. LILO에 대한 설정은 /etc/lilo.conf 에 있다. 여기서 윈도우와 리눅스를 멀티부팅을 할 수 있도록 해주려면 몇 가지 추가적인 내용이 필요하다. 물론 윈도우를 설치하고, 리눅스를 설치했다면 이 정보는 자동으로 생성되어 있을 것이다. 필자가 사용하고 있는 설정 파일의 내용을 공개하면 다음과 같다.

prompt
timeout=50
default=DOS
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
message=/boot/message
lba32

image=/boot/vmlinuz-2.4.19
        label=linux
        root=/dev/hda5

other=/dev/hda1
        optional
        label=DOS
LILO 설정 파일에 대해서 자세히 알고 싶은 사람은 관련 자료들을 참고하기 바란다. 여기에서는 이것에 대한 내용은 설명하지 않는다. 우리가 주의깊게 봐야할 내용은 빨간색으로 표시된 부분이다. 추가만 해주면 된다. 참고로 default 인자는 LILO 부팅 시에 기본적으로 선택되는 라벨을 결정해주는 것이다. 위의 설정 파일에서는 linux라는 라벨과 DOS라는 라벨이 사용되었으며, 기본적으로는 DOS가 선택된다. 부팅 시에 가만히 두면, 그냥 윈도우로 부팅을 하게 된다는 의미이다.

이제 마지막으로, 하드디스크의 MBR이라는 영역에 LILO가 들어갈 수 있도록 업데이트해 준다. 이 작업은 단지 한 단어만 입력해서 실행해주면 된다.

lilo
이렇게 하면 LILO를 복구할 수 있다. LILO가 깨져서 리눅스가 부팅이 안 되는 경우에는 이 방법을 꼭 써보도록 하자.

환경 설정 파일의 복구
이 경우는 필자도 상당히 황당하게 생각이 되었다. 리눅스가 정상적으로 종료되지 않았을 경우엔 다음 부팅 시에 하드 디스크의 내용을 확인하고, 복구하는 작업(fsck를 수행한다. 아마도 file system check 의 약자인듯...)을 수행한다. 그런데, 일치가 되지 않는 부분이 발견되었다는 메시지를 보이면서, /etc/mtab 이라는 파일을 삭제해버리는 것이었다. 그리고, 나중에 알게 된 거지만 /etc/fstab 이라는 파일도 초기화시키는 엄청난 권력을 이 리눅스라는 놈이 시행하고 말았던 것이다. '별일 있겠어?' 하고 리눅스를 사용하다가 다시 부팅을 한 결과 파일 시스템에 대한 정보가 없어서 루트 파일 시스템을 찾지 못하는 결과가 생기고 말았다. 이 경우는 전자와는 달리 파일 시스템에 대한 환경 설정 파일이 잘못 되어서 부팅이 안 되는 경우이다. 그러므로, 전자와 같은 방법을 사용해서는 같은 에러 메시지를 띄우며, 부팅을 할 수가 없다. 프로그래밍을 하다가 백업도 안 해놓은 상황이었고 (역시 필자가 게으른 탓으로... ㅡㅡ;;) 정말 죽고 싶은 상황이었다. 그렇다고 파일 내용 자체가 남아있으니, 포기하고 새로 리눅스를 설치해야 한다는 생각은 들지 않았다. 혹시나 하는 마음에 리눅스 배포판 CD를 무작정 넣고, 부팅을 했다. '앗~!' 눈에 띄는 메뉴가 있었다. 그것은 바로 rescue 라는 메뉴이다. 참고로, 필자가 사용하는 리눅스는 한컴 리눅스이다. 다른 리눅스 배포판에서 이 기능을 제공한다는 보장은 할 수 없지만, 아마도 제공하리라 생각한다. 부트 프롬프트에서 다음과 같이 입력하고 부팅하기를 기다렸다.

boot : linux rescue
언어를 선택하고 (한글 지원하는 메뉴도 있었지만, 선택을 해보니 지원을 하지 않는다고 되어 있어서 그냥 영어로 선택했다. ㅡㅡ;;) 키보드 타입을 선택하니 (한글판 리눅스에서도 한글 키보드가 지원되지 않는다니... ㅡㅡ;;) 마지막 화면에서 시스템 파일 시스템이 /mnt/systemimage 라는 디렉토리에 마운트되었다는 메시지가 떴다. 바로 이것이다. 이것을 이용해서 설정 파일을 수정할 수가 있는 것이다. 다음 명령으로 마운트된 디렉토리를 접근해보면, 리눅스가 설치되었던 파티션의 내용들이 그대로 있음을 확인해볼 수 있다.

cd /mnt/systemimage
즉, 우리가 일반적으로 리눅스를 부팅했을 때 '/'로 사용하던 디렉토리가 '/mnt/systemimage' 라는 디렉토리에 마운트가 되어 있는 것이다. 재빨리 etc/fstab 파일을 확인해봤다. "이럴수가~!". 어떻게 된 것인지는 모르지만, 플로피와 CD에 대한 마운트 위치에 대한 설정을 제외하고는 모든 정보가 사라져버렸다. 그래서 루트 파일 시스템을 마운트하지 못해서 부팅 도중에 멈춰 버린 것이었다. 그래서 다음처럼 파티션에 대한 정보를 추가해주고 파일을 업데이트했다.

/dev/hda5                /        ext2 default 1 1
/dev/hda6                none        swap sw 0 0
/proc                /proc        proc none
...
떨리는 마음으로 재부팅을 실시했다. 역시나 성공적인 부팅을 ^^V. 가슴 뿌듯한 순간이었다. 혹시나 필자와 같은 경우를 겪고 있는 사람이라면 이 방법을 한번 시도해보기 바란다.

superblock 의 복구
두번째 경우와 비슷한 경우라고 볼 수 있기도 한데, 이것은 설정 파일이 문제가 아니라, 아마도 하드 디스크의 bad block 으로 인해서 파일 시스템의 superblock 이 사용하지 못하게 된 경우라고 생각된다. 부팅하다가 다음과 유사한 메시지가 뜬다.

can't read superblock
이런 메시지가 뜨면서, root 계정의 패스워드를 입력하면 복구 모드로 들어가게 된다. 처리할 수 있는 방법이 간단히 설명되는데, 필자의 경우에는 제대로 실행이 되지 않았다. 다음과 같은 처리 메시지이다.

fsck -b 8193 device
device는 당연히 /dev/hda5 일 것이고, 인자값으로 사용된 숫자값 입력이 잘못된 것이 아닐까 하는 의심이 생겼다. 더 이야기를 진행하기 전에 이 처리 방법에 대한 설명을 해야 할 것 같다. 리눅스에서 일반적으로 사용하는 ex2 파일 시스템에는 superblock이 손상되는 경우에 대비해서 일정 블럭별로 여분의 superblock 복사본을 만들어 놓는다. superblock이나 리눅스 파일 시스템에 대한 설명은 관련 자료를 찾아보기 바란다. 필자도 잘 모르거니와 이 글에서 설명할 부분은 아닌 것 같다. 이 superblock은 초기적으로는 1번 블럭을 이용하고, 이 첫번째 복사본의 위치가 일반적으로 8193 이라는 것이다. 즉, 8192 블럭을 주기로 superblock의 복사본을 지니고 있다는 얘기가 된다. 그러나, 필자의 예측이지만, 현재의 고용량의 하드 디스크에는 저 고전적인 값을 사용하지 않는 것 같다. 복사본을 엄청나게 많이 가지게 되어서 비효율적이기 때문이다. 아무튼, 여기저기 자료를 찾아보다가 [1]에서 블럭 정보를 알아낼 수 있는 방법을 찾았다. 다음과 같은 명령이다.

dumpe2fs device | more
물론 more 이라는 명령은 출력되는 부분이 너무 많아서 한 화면에 볼 수 없기 때문에 이용한다. 여기에서 Block per groups 라는 내용이 나타나는데, [1]과는 달리 필자의 컴퓨터에서는 다른 값이 나타나는 것을 확인할 수 있었다.

Blocks per groups : 8192 ([1]에서 제시한 값) --> Blocks per groups : 32768 (필자의 컴퓨터)
그렇다. 필자의 컴퓨터에서는 32768 블럭 단위로 superblock의 복사본을 가지고 있었기 때문에, 인자값을 잘못 입력한 것이었다. 그러나 한가지 더 시련이 있었다. 설명이 된 인자값이 8193 이었기 때문에, 당연히 32769를 사용해야 한다고 생각했다. 그러나, 역시 fsck는 불평을 쏟아내면서 실행이 되지 않았다. 다시 dumpe2fs의 결과값을 유심히 살펴보았다. 고맙게도 이 프로그램은 각 group에 대한 상세 정보를 표시해줬고 블럭이 0번부터 시작한다는 것을 알 수 있었다. 즉 두번째 블럭 그룹은 32768 번이 되는 것이다. 그래서 다음과 같이 입력을 해서 드디어 성공된 결과를 얻을 수 있었다.

fsck -b 32768 /dev/hda5
superblock이 문제가 될 경우에는 에러 메시지에서 제시하는 복구 방법을 시도해본 후, 제대로 되지 않을 경우에는 필자와 같은 방법을 이용해보기 바란다.