원문 보기: https://dawoum.duckdns.org/wiki/Debian_Linux_System_Recovery
이 글은 개인 사용자에 한정된 글입니다!!
일반 사용자는 운영 시스템을 망가뜨릴 가능성이 높지 않습니다. 보통, 게임을 하거나, 문서를 만들거나, 영화를 보거나, 음악을 듣거나, 등의 작업으로 시스템을 망가뜨릴 가능성은 거의 없다고 볼 수 있습니다.
하지만 운영 시스템을 설치한 사람은, 일반 사용자를 포함해서, 시스템에 관한 전체 권한을 갖게 됩니다. 이 말은 어떤 사용자라도 언제든지 시스템을 망가뜨릴 수 있다는 의미입니다.
보통, 초보자 시절에는 하는 행위가 얼마나 위험한지 모르기도 하지만 특별한 자료도 없기 때문에, 망가지면 새로 설치하지! 라는 생각으로 위험한 행위를 시도합니다.
어쨌든, 시간이 지나면서 어느 정도 지식을 갖게 되면, 시스템을 망가뜨릴 가능성은 적어지지만, 그래도 시스템에 적용해 놓은 설정을 잊어버리거나, 명령어 실수를 하거나, 잘못된 설정을 적용하거나, 등으로 시스템은 언제든지 망가질 수 있습니다. 명령어 실수와 관련하여, 쉘을 바꿈으로써 거의 실수를 줄일 수 있습니다. 사용자에게 친절한 쉘로 이전해 보십시오!
예를 들어, Debian/Upgrading Debian 11 to Debian 12를 보면, 이전에 설정을 잊어버림으로써 제대로 업그레이드가 이루어지지 않아서 문제가 발생합니다.
다음으로 TuxClocker와 관련된 작업을 하면서 커널 컴파일을 새롭게 한 후에 인지할 수 없는 이유로 부팅이 되지 않는 경우도 있습니다.
따라서, 적어도 시스템이 망가졌을 때, 고치는 방법 정도는 알아둘 필요가 있습니다.
소개
최근 몇 일 내에 몇 가지 이유로 시스템을 복구해야 할 일이 생겼습니다.
처음은 TuxClocker를 조작하다, 커널 컴파일 후에 그래픽 카드 모듈을 불러오지 못하는 희한한 경험을 하게 되었습니다. 이전에 같은 설정으로 모듈로 작성된 커널에서는 여전히 부팅이 잘 되어서 의문이 남습니다. 다행히 다른 커널로 부팅이 되어서, 커널 컴파일 옵션을 조절해서 해결했습니다.
다음으로, netplan으로 변경한 후에, wired connection이 사라져서, 사실 없어도 되지만, 그것을 그놈 설정에 보이도록 만드느라 설정을 조작한 후에, 부팅 중에 한 개의 서비스에서 더 이상 진행되지 않는 문제로 리커버리를 사용했습니다. 그 서비스가 부팅 중에 자동으로 중지될 때까지 2분하고도 10초가 걸린다는 것을 나중에 확인했습니다. 어쨌든, 설정에 따라 해당 서비스는 필요하지 않기 때문에 서비스를 중지함으로써 해결을 보았습니다.
사실, 시스템 설정의 변경으로 부팅이 되지 않는 경우는 극히 드뭅니다. 어쨌든, 부팅이 되지 않으면, 어떤 형태로든 디스크에 접근을 해야 부팅이 가능하도록 만들 수 있기 때문에, 어느 정도는 전반적인 사항을 확인해 둘 필요가 있습니다.
문제가 무엇인가?
리눅스 운영 시스템을 복구하려고 할 때, 첫 번째 단계는 문제의 본질과 원인을 파악하는 것입니다.
어떤 운영 시스템은 사용 중에 갑자기 치명적 오류가 발생하면서 시스템을 사용하지 못하는 경우가 있지만, 리눅스 시스템은 사용하는 중에 갑자기 오류가 발생하는 경우는 매우 드뭅니다. 아마도 하드웨어에 문제가 발생하지 않는 경우에는 그런 경험을 하기가 쉽지 않습니다.
반면에, 리눅스 시스템은 운영 시스템의 바닥인 커널 자체를 사용자가 컴파일할 수 있기 때문에, 대부분의 문제는 사용자의 실수로 인해서 발생한다고 볼 수 있습니다. 물론 일부 배포판 패키지 관리자의 실수로 발생하는 경우도 있지만 경험하기 쉽지 않습니다.
어쨌든, 시스템이 올바르게 동작하지 않는 것으로 보이면, 우선적으로 시스템 로그를 확인할 수 있습니다.
로그를 보기 위해, dmesg, journalctl, 등의 명령을 사용할 수 있고, 명령에 익숙치 않을 때에는 /var/log 아래에 있는 kern.log, syslog, 등의 파일을 직접 열어서 내용을 확인할 수도 있습니다.
한편, 터미널에서 나타나는 이런 명령은 다른 리눅스 명령어의 도움으로 원하는 내용을 찾아야 하고, 편집기에서도 검색을 통해서 원인을 찾을 수 있지만, 문제는 어떤 것을 찾아야 할지 알 수가 없다는 것입니다. 더구나, 로그의 내용은 사용자에게 결코 친절하지 않습니다.
이때에는 좀 더 친절하게 내용을 정리해 주는 프로그램의 도움을 받을 필요가 있고, 그놈 데스크탑 아래에서 Logs (gnome-logs) GUI 프로그램을 이용할 수 있습니다. 대안적으로 Qjournalctl과 같은 GUI 프로그램을 사용할 수도 있습니다.
이런 것들은 시스템이 살아 있을 때, 문제를 인식하는 데 도움이 됩니다.
반면에, 부팅과 관련된 문제가 발생하면, 시스템 내부로 들어가기가 쉽지 않기 때문에, 이런 로그에 접근하기가 힘듭니다.
부팅 관련된 문제는 어떤 작업 후에 당시에는 발현되지 않다가, 재시작 후에 해당 설정이 적용됨으로써 발생할 수 있습니다.
이때에는 지난 작업 중에 시스템과 관련된 작업, 예를 들어, 패키지 업데이트, 시스템 설정 변경, 등을 했는지 기억해 내는 것이 중요합니다.
만약 그런 사실이 없다고 판단되면, 자동으로 시스템을 조작하는 작업은 없는지 생각해 보아야 합니다. 따라서, 시스템 자동 업데이트와 같은 설정은 위험한 상황에 놓일 수 있기 때문에, 업데이트 알림 정도로 변경해서 사용하시기 바랍니다.
아무 일도 안했는데 갑자기 부팅이 되지 않는 경우는 없습니다. 단지 기억을 못할 뿐입니다!
추가적으로, 요즘은 부팅 로그를 보이지 않고, 스플래시 화면 아래에 감추는 배포판들이 있는데, 문제를 파악하는 데 전혀 도움이 되지 않기 때문에 미리 제거해 두는 것이 좋습니다. 부팅이 되지 않더라도, 어는 지점에서 문제가 발생하는지 확인하는 것이 중요합니다!
/etc/default/grub 파일의 내용을 확인하셔서 작업하십시오:
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX=""
위에서 처럼, splash, quiet를 제거하시고, 다른 옵션이 있을 때에는 신중히 판단하시기 바랍니다. 검색을 하십시오!
또 다른 설정 중에 하나는 여기저기서 부팅 시간을 줄인다고 GRUB_HIDDEN_TIMEOUT=0으로 만들어서 사용하라고 권고하지만, 이런 식이면 문제가 생겼을 때, 리커버리 모드로 진입하지 못하기 때문에, 3 정도로 변경하시기 바랍니다.
- sudo update-grub
리커버리 모드와 커널 보관
시스템 부팅 중에 커널 패닉이 발생하는 경우를 제외하고, 파일 시스템에 문제가 있거나, 특정 서비스가 문제가 발생해서 시스템 부팅을 완료하지 못할 수 있습니다.
이런 경우에는 리커버리 모드로 진입해서 문제를 바로 잡을 가능성이 있습니다.
그럽 화면이 올라오면, Advanced... 누르고 커널 이름 끝에 (Recovery...)가 있는 것으로 이동해서 리커버리 모드로 진입할 수 있습니다.
리커버리 모드는 부팅이 필요한 최소한의 경로로 부팅을 진행하기 때문에 해당 경로 중에 있는 것에 문제가 발생하지 않으면, 대체로 진입이 가능합니다.
추가적으로, 커널 컴파일이 잘못되는 등으로 인해, 특정 커널에서 부팅에 실패하는 경우가 있습니다.
이런 상황을 피하려면, 적어도 시스템에 몇 개의 커널을 보관할 필요가 있습니다. 특히, 커널 컴파일을 해서 사용하고 있다면, 커널에 문제가 없다고 판단되는 시점까지는 이전에 부팅이 잘 되는 적어도 몇 개의 커널은 보관하고 있어야 합니다.
데비안에서도 현재 6.x 커널을 제공하지만, 5.x 커널도 제공하기 때문에, 배포판에서 제공하는 2개 정도의 커널을 보관할 필요가 있습니다.
커널 컴파일을 해서 사용하고 있다면, 이전 안정 커널의 마지막으로 컴파일한 버전은 보관할 필요가 있습니다.
이런 상황에서, 시스템에는 적어도 3~4개의 커널은 기본적으로 보관하는 것이 좋고 많을 때에는 수십 개의 다른 커널이 존재하기도 합니다.
보통 2개월마다 커널 보조 버전의 숫자가 1 증가하므로, 커널 컴파일을 지속적으로 하고 있다면, 2달 정도 후에 설치된 커널을 정리할 필요가 있습니다.
라이브 USB
먼저, 부트 로더에 문제가 생기면, 커널에 접근하지 못하는 경우가 생길 수 있습니다. 또는 커널 패닉이 발생하면, 대체로 모든 커널에서 커널 패닉이 발생할 수 있습니다.
이때에는 일반적으로 리커버리 모드로 진입할 수 없기 때문에, 다른 미디어를 통해 부팅을 해서 문제를 바로 잡기 위해 시도할 수 있습니다.
요즘은 배포판에서 제공하는 라이브 이미지를 USB에 구워서 사용하는 것이 공통적입니다. 이때, 여러 운영 시스템에 대응하기 위해 Ventoy 같은 도구를 사용할 필요가 있습니다.
한편, 시스템에 발생한 문제의 정도에 따라, 단순히 해당 디스크를 마운트해서 파일을 수정함으로써 끝나는 경우도 있지만, 대체로 커널을 다시 설치하는 등의 시스템을 조작해야 할 수 있습니다. 이때에는 Chroot를 이용할 수 있습니다.
라이브 USB는 적어도 중요한 데이터를 특정 디스크로 복사할 수 있는 환경을 제공하기 때문에 마련해 둘 필요가 있습니다.
추가적으로, 부트 로더에 문제가 생길 경우에는 그럽 명령 줄이 출력되는데, 명령 줄에서 커널 위치와 이름을 지정함으로써 부팅이 될 수도 있습니다. GNU GRUB에서 확인하십시오.
시스템 백업과 개인 데이터 백업
어떤 경우에서 시스템을 백업해서 이전 상태로 되돌릴 수 있습니다. 예를 들어, 최신 기술은 파일 시스템 자체에서 시스템 백업을 지원하거나, 어떤 도구는 특정 시점에서 시스템 전체를 이미지로 만들 수도 있습니다.
반대 급부로, 이런 도구들이 모든 상황에 대응할 수 있는 것도 아니지만, 너무 많은 쓰기 작업을 함에 있습니다. 요즘 많이 사용하는 저장 장치, SSD는 쓰기 작업에 제한이 있고, 따라서 이런 도구를 사용하는 것이 꺼려지는 것도 사실입니다. 용도에 따라 다르겠지만, 리눅스는 생각보다 쓰기 작업을 많이 하는 것으로 추정됩니다. Gigabyte-AORUS-NVMe-Gen4-SSD를 참조하십시오.
특히, 개인의 능력이 일정 수준에 이르면, 시스템을 망가뜨릴 가능성이 극히 적어지고, 대체로 복구가 가능하기 때문에 이런 도구를 사용할 일이 거의 없습니다.
따라서, 시스템 복구에 어려움을 느낀다면, 이런 도구를 이용해 볼 수는 있습니다. 그러나, 이런 도구에 전적으로 의존하면 결국 일정 수준에서 개인의 능력이 발전하지 못하기 때문에, 계속적으로 도구에 의존할 수 밖에 없습니다.
사실, 시스템 복구는 처음에는 두려움을 느낄 수 있지만, 리커버리나 라이브 모드에서 Chroot로 한 두번 정도만 경험이 쌓이면 그냥 컴퓨터를 사용하는 것과 다르지 않습니다. 이런 명령은 자주 사용하지 않기 때문에, 그 절차를 잊어버리기도 하며, 인터넷으로 찾아서 명령을 전달할 수 있습니다.
주의: 개인 데이터 관리와 혼동해서는 안됩니다! 중요한 개인 데이터는 두 번 이상 백업본을 다른 드라이브에 저장해 둘 필요가 있습니다. 개인 사용자의 입장에서 파티션 정책을 따로 세울 필요는 없지만, 개인 데이터 백업을 위해 저장 장치는 여러 개 가질 필요는 있습니다. 시스템 파일들은 미러에 늘려 있지만, 개인 데이터는 유일하게 나만 가지고 있음을 명심하십시오!
문제 해결
문제의 원인을 파악하면, 대체로 문제를 해결할 수 있습니다.
보통, 해결책은 로그가 있으면, 로그의 전체 또는 일부를 인터넷으로 검색함으로써 해결책을 찾을 수 있습니다. 로그가 없더라도, 문제가 되는 부분이나 상황을 검색함으로써 해결책을 찾을 수 있습니다.
이때, 대체로 검색을 영어로 해야 좋은 결과를 얻을 수 있을 것입니다. 한글로 작성된 리눅스 관련 글이 영어에 비해 터무니 없을 정도로 적기 때문이기도 하지만, 로그 결과에 한글이 없기 때문이기도 합니다.
문제의 원인이 도저히 파악되지 않고, 중요한 데이터를 백업한 후에는, 그냥 다시 설치하는 것도 방법 중 하나입니다.
하지만, 리눅스 데이터가 거의 없고 뭔지 잘 모르던 시절을 제외하고 시스템이 반 이상 망가져도, 배포판마다 다르겠지만, 원인을 파악하면 포멧이라는 과정만은 피하는 방법이 있었습니다. 최근 십 몇 년 내에는 심각한 복구 상황이 없어서 현재도 유효한지는 의문입니다.
사실, 이런 과정은 그냥 다시 설치하는 것보다 훨씬 오래 걸리기도 하지만, 경험이 매우 중요합니다!
