LINUX) Boot 디렉토리 삭제시 복구하는 방법

Introduction

 

리눅스 서버를 운영하다 보면 아주 가끔이지만 Boot 영역의 Mount Point인 "/boot" 디렉토리의 내용을 실수로 삭제하거나 일부 손상이 되어 정상적으로 부팅이 되지 않는 경우가 종종 있습니다.

 

이럴 경우는 iso에 있는 Boot 영역을 복사해줘서 살립니다.

운영중인 서버의 Boot 영역을 tar로 묶어서 전송해도 상관은 없지만 권장하는 방법은 아닙니다.

 

 

이 역시 문제점은 존재합니다. 기존에 운영중인 커널 이미지가 순정이 아닌 개인적인 설정이 들어간 이미지인 경우 운영자가 해당 정보에 대한 History를 모르면 그대로 원복 시키는 것은 힘듭니다. 

 

 

 

 

Boot 디렉토리 복구 방법 - LAB

 

이 서버는 정상적으로 작동하고 있는 서버입니다.

 

[root@lilo boot]# pwd ; ls -l /boot total 112092 -rw-r--r--. 1 root root   153591 Oct 20  2020 config-3.10.0-1160.el7.x86_64 drwxr-xr-x. 2 root root       27 Jul  9 00:50 grub drwxr-xr-x. 5 root root       79 Jul  9 01:06 grub2 -rw-------. 1 root root 62126712 Jul  9 00:41 initramfs-0-rescue-a11b8925b852814da6a981780cc7e428.img -rw-------. 1 root root 21475586 Jul  9 00:45 initramfs-3.10.0-1160.el7.x86_64.img -rw-------. 1 root root 13535124 Jul  9 01:12 initramfs-3.10.0-1160.el7.x86_64kdump.img -rw-r--r--. 1 root root   320648 Oct 20  2020 symvers-3.10.0-1160.el7.x86_64.gz -rw-------. 1 root root  3616707 Oct 20  2020 System.map-3.10.0-1160.el7.x86_64 -rwxr-xr-x. 1 root root  6769256 Jul  9 00:41 vmlinuz-0-rescue-a11b8925b852814da6a981780cc7e428 -rwxr-xr-x. 1 root root  6769256 Oct 20  2020 vmlinuz-3.10.0-1160.el7.x86_64

 

위의 상황을 재현하기 위해 "/boot" 디렉토리의 내용을 삭제하고 서버를 재기동합니다.

 

[root@lilo boot]# rm -rf /boot/* ; ls -l ; reboot total 0 Connection to 192.168.56.100 closed by remote host. Connection to 192.168.56.100 closed.

 

서버를 재기동하면 아래와 같은 화면이 등장합니다. Grub 부트로더에 대한 파일이 없으니 해당 에러가 뜹니다. 

 

 

 

이제 서버에 미디어(ISO)를 넣어준 후 재기동을 해서 Rescue Mode로 진입합니다.

 

 

 

재기동 후 "Trouble Shooting"이라는 탭으로 진입후 "Rescue a CentOS system"에서 Enter를 누릅니다.

Rescue Mode는 복구 모드입니다.

 

 

 

Rescue에 진입되었고 아래의 멘트가 나오면 Shell에서 계속 작업을 할 것이기 때문에 "1"을 입력 후 Enter를 누릅니다.

 

 

 

현재 디렉토리는 "ISO"의 위치이므로 현재 "/" 위치가 아닌 이 서버의 "/"를 "/" 영역으로 사용하기 위해 "chroot"를 사용합니다.

bash shell로 진입이 완료되면 root 유저로 전환합니다.

 

sh-4.2#  chroot /mnt/sysimage
bash-4.2# su -

 

 

 

사용중인 서버가 "Local Yum Repository"가 잡혀있을 경우에는 yum 명령을 이용해 더 쉽게 작업할 수 있습니다.

이 글에서는 2가지의 방법 모두 다 소개합니다.

 

먼저, yum을 이용한 Kernel 재설치입니다.

 

[root@localhost ~]# yum reinstall kernel

 

 

 

다음은, ISO 파일에 있는 Package 디렉토리안의 RPM 파일을 이용한 재설치입니다.

 

 

먼저, ISO를 임시 공간에 Mount 시킨후 Packages 디렉토리로 이동합니다.

 

[root@localhost ~]# mount /dev/sr0 /mnt           (ISO 마운트)
[root@localhost ~]# cd /mnt/Pacakages

 

 

이제 Package를 설치합니다.

이미 Kernel 관련 RPM이 설치되어 있던 상황이므로 "--force" 옵션을 입력해서 강제로 설치합니다.

 

[root@localhost ~]# rpm -ivh --force kernel-3.10.0-957.el7.x86_64.rpm
[root@localhost ~]# rpm -ivh --force grub2-2.02-0.76.el7.centos.x86_64.rpm
[root@localhost ~]# rpm -ivh --force centos-logos-70.0.6-3.el7.centos.noarch.rpm

 

 

이제 Package를 쓸 일이 없으므로 Mount를 해제합니다.

 

[root@localhost ~]# umount /mnt

 

 

 

이제 "grub"을 설치해야 되는데 "/boot" 영역이 어디로 잡혀있는지 확인하기 위해 아래의 명령을 입력합니다.

 

[root@localhost ~]# df

 

"/dev/sda"에 있는 것을 확인할 수 있습니다.

 

 

 

grub을 설치합니다.

 

[root@localhost ~]# grub2-install /dev/sda

 

 

에러 없이 설치가 잘 되었습니다. 꽤 재밌는 부분을 볼 수가 있습니다. "Installing for i386-pc platform" 로그입니다.

Boot 영역을 날린후 재기동 했을 때 본 에러 문구에서 찾을 수 없는 것을 설치하고 있다는 로그입니다.

 

 

 

또 확인해 볼 수 있는 것은 "grub.cfg"라는 설정 파일이 없다는 것입니다. 이 설정 파일이 없으면 당연히 재부팅해도 먹통이 되겠죠?

 

 

 

 

"grub.cfg"를 생성합니다.

 

[root@localhost ~]# grub2-mkconfig -o /boot/grub2/grub.cfg

 

 

커널관련된 이미지를 찾아서 내용을 알아서 잘 작성했다는 로그입니다. 이 이미지가 없으면 작성도 실패하겠죠?

 

 

 

 

 

이제 재부팅합니다.

 

[root@localhost ~]# exit
sh-4.2#  exit
bash-4.2# exit

 

 

만약 "Reached target Shutdown"에서 행이 걸린다면 Virtual Box는 VM 자체를 재기동하고 BareMetal은 서버 자체를 재기동하는 방향을 가집니다.

 

 

 

이 글은 Trouble Shooting이지 절대로 서버에 이런 실수를 하지 않기를 바랍니다.