서버, 네트웍이 날아갔다.

올해, 왜 이러는건지?
시작한지 한달도 안됐는데, 벌써 이렇게 저렇게 망가지고 날아가고 한게 몇번짼지..

이번엔 이제 막 설치해서 살살 꾸며가고 있던(?) 서버에서, 손가락 하나 까딱 잘 못 놀리는 바람에 네트웍 관련 프로그램들이 모두 지워져버렸다. (정확히는 ubuntu-server 꾸러미가 지워지면서 network 관련 꾸러미도 지워진 듯 하다.)

네트웍이 없으니, 뭘 어떻게 할 수가 없다.
아… 왜 이리 자꾸 시련이 오는건지.

이걸 해결하려면, 라이브 디스크로 부팅한 후 chroot 을 해야 하는 듯 한데.
안해본 건 아니지만.. 아아아아아!!

연휴에 할 일이 생겨버렸네.
아.. 젠장.


시간은 흘러..

살펴보니, 네트웍만 날아간게 아니고 거의 모두가 날아갔다.
정확하게, 내가 한 무모한(?) 행동은 이랬다.

tasksel 에서 xubuntu-desktop 을 설치한 뒤, 원하는대로 작동이 되지 않아, 다시 tasksel 을 실행한 뒤, xubuntu-desktop 을 체크 해제하고 진행했다.

헌데.. 뭔가가 상당히(?) 지워지는 상황을 보게됐고, 그 결과로 상당수 꾸러미가 날아가버렸다.
왜 이런 일이 일어났는지..
그 중에는 ubuntu-server 는 물론, 대부분의 꾸러미들이 포함돼 있었다.

진작 snapper 를 설치/설정 해놓는건데.
소 잃고 외양간 고치는 격이 됐지만, 어쨌든 이제라도 해놓으면 되겠지.

아무튼, 그건 그거고 이 난관을 어찌 극복해야할까?
본체로 직접 접속은 되지만, 네트웍 모듈까지 삭제됐기 때문에 할 수 있는게 아무 것도 없었다.
그렇다고 재설치를 하자니 그건 너무 무식한 짓이고.

하여, chroot 을 하는 방법을 택했다.
아래는 간단 정리. 기본 방법은 Btrfs 사용 우분투 서버 설치 때와 같다.


(고장난? 시스템) Mount/Bind

먼저 우분투 라이브 드라이브로 부팅한다. 내 생각엔, 어떤 라이브 이미지를 사용해도 별 무리가 없을 듯 하다. 우분투 GUI 를 사용하든, 서버를 사용하든, 아니면 심지어 레드햇 계열을 사용하든.

그러나, 얼마 전에 설치한 우분투 서버 드라이브가 그대로 남아있어서 그걸 사용했다.

우분투 서버 이미지로 부팅이 되면, 설치 초기 화면에서 Ctrl-Alt-F2 를 눌러 다른 터미널로 이동한다.

이제 여기서 내 시스템을 chroot 으로 새롭게 인식시켜야 한다.
먼저, lsblk -f 로 현재 디스크 상황을 알아낸다.

lsblk -f
sda                                                              
├─sda1 vfat                 <UUID>                            
├─sda2 ext4                 <UUID>                            
└─sda3 btrfs                <UUID>                            


btrfs 를 사용 중이고, set-default 를 했다면, 보다 정확한 설정을 위해 다음과 같이 마운트 한다.
Boot 파티션을 따로 만들었고, 기타 파티션을 만들지 않았다면, main(FS Root) 파티션은 sda3(또는 nvme0n1p3) 가 된다.

sudo mount /dev/sdaX /mnt -o subvolid=5

여기에 있는 @(root) 디렉토리를 /target 으로 bind 해주는 작업이 최 우선 순위가 된다. (모든 작업은 root 로 해야 한다.)

mount --bind /mnt/@ /target
mount --bind /mnt/@var /target/var
mount --bind /proc /target/proc  
mount --bind /dev /target/dev  
mount --bind /sys /target/sys

문제는 run 디렉토리다. 원 시스템에 있던 run. 위 상황이라면 /mnt/@/run. 이 디렉토리는 지금 아무런 의미가 없다. 따라서 지워도 무방하긴 한데, 지우지는 말고 이름을 바꾼다.

mv /mnt/@/run /mnt/@/run-old

그리고, 지금 라이브 부팅한 상황의 /run 을 /target 으로 바인드 한다.

mount --bind /run /target/run

다시 말해서, /proc, /dev, /sys, /run 은, 현재 부팅한 라이브 시스템에서 /target 으로 바인드 해준다.
또, 지금 상황에선 /boot 에 저장할 정보가 없어서 마운트를 해주지 않았는데, 만약 boot 와 efi 가 필요하다면, 그 파티션들도 마운트 해줘야 한다.

mount /dev/sda2 /target/boot
mount /dev/sda1 /target/boot/efi

**만약 위 작업 중 mount point 가 없다고 나오면, run 을 만들어 주고 나서 bind 한다.

이러면.. 준비 끝. (아마도? 뭔가 빼먹은게 있는 듯도 하지만..)
/home, /opt 등은 현 작업엔 전혀 쓸모가 없으므로 마운트하지 않아도 된다.

chroot 후 원상복구 작업

이제 /target 으로 chroot 해준다.

chroot /target

이러면, 원래 내 시스템으로 chroot 하게 된다. 이 방식은 ArchLinux 를 설치할 때는 반드시 밟아야 하는 과정이고, 고급(?) 리눅스 명령이기도 하다.

여기에서, 손상 여부를 확인한다. 내 경우, ubuntu-server 가 삭제돼 있었다.
따라서, 우선 이것을 설치해준다.

apt install ubuntu-server

여기서 한가지 확실하지 않은게.. 네트웍 관련 모듈이 복구가 되는지의 여부다.
이걸 어떻게 확인해야 하는지도 잘 모르겠고.
어쨌든, 이전에 받아놓은 r8168 꾸러미가 있었기에, 이걸 그냥 설치해줬다.

dpkg -i r8168-dkms_8.048.00-1_all.deb

또, open-ssh 서버도 삭제되어 있기에, 역시 설치했다.

apt install openssh-server

여기까지만 하면, 이제 네트웍이 살아났고, ssh 접속이 가능하게 된다.
나머지 작업은 원 시스템으로 부팅한 뒤, ssh 로 연결하여 완료하면 되겠다.

완료 작업

살펴보니, 웬만한 건 모두 삭제돼 있었다. 내가 설치했던 mc 까지도. 아마도 의존성 문제로 인해 줄줄이 같이 딸려나간 모양이다.
물론, 그럼에도 불구하고 설정파일들은 모두 남아있으니, 프로그램만 설치하면 상황은 원래대로 돌릴 수 있다.

mc 같은 건 별로 중요한 건 아닌데..
의외로, 커널 모듈까지 삭제가 되어 사운드가 재생되지 못하는 상황에 이르렀다. (이걸 찾아내느라 또 한동안 고생했다.)
구글 검색 끝에 이런 명령을 내려봤는데, 사운드 관련 모듈이 하나도 없음을 발견할 수 있었고, 따라서 모듈을 설치해야만 했다.

find /lib/modules/$(uname -r) | grep snd 
....

모듈 설치 작업은 아래와 같이 완료할 수 있었다.

sudo apt install linux-modules-extra-$(uname -r)

또, alsa-base 가 삭제됐는지는 지금 확인할 길이 없는데, 하는 김에 같이 설치해줬다.

sudo apt install alsa-base libasound2 alsa-utils alsa-tools

몇몇 남은 중요한 꾸러미들(apache, mariadb, mpd, nfs 등등) 을 설치하고 원 상태로 완전히 복구할 수 있었다.

** 커널 업그레이드가 안되더라??

글을 쓰고 나서 며칠 지난 오늘, 커널이 5.3.0-28 로 판올림 되었는데, 이 시스템은 어째 업그레이드 신호가 오질 않았다.
저장소에 확인을 해보니 새 커널이 틀림없이 올라와 있는데.. 왜??

아마도 의존성 문제일텐데, 아마도 linux-generic-hwe-18.04 꾸러미가 지난 번에 삭제됐기 때문인 듯 하다. (아마도 같이 설치가 되겠지만, 혹시 안되면 linux-headers-generic-hwe-18.04 도 설치.)
이 정도면 해결이 되겠지?? (제발..)

이 삽질(?)로 인해 몇가지 기교도 배웠고, 또, Snapper 의 필요성도 뼈저리게 깨달았다. 그걸 미리 설정해놨다면, 이런 헛짓거리는 안했을텐데..

그럼에도 불구하고, (다소 뜻이 다르기는 하지만) 실패는 성공의 어머니라 했듯, 이 바보같은 짓을 통해서도 많은 걸 배울 수 있었다. chroot 을 사용해서 성공했을 땐, 짜릿함도 있었다.

1년 전만 해도 이 상황에선 그냥 OS를 전체 재설치했었을 가능성이 높다.
그나마 우분투 서버를 Btrfs 로 설치하면서 chroot 을 사용해봤고(그 전에 Arch 설치 때도 미약하게나마 경험해봤지만), 이런 저런 경험이 겹쳐져서 이렇게 큰 무리없이 복구를 할 수 있지 않았을까?

게다가, 그래도 이런 저런 기록들을 잘 저장해놨던게(이 블로그의 의의가 바로 그거지!) 큰 도움이 됐다.

물론.. 제일 큰 도움은 구글 검색이지만.

이젠, Snapper 설정을 잘 해놓는 일만 남았다.

안녕하세요. 글 남겨주셔서 고맙습니다.