우분투 서버 비상 모드 부팅: 단계별 복구 가이드

예시 시나리오: Casey는 재부팅 후 비상 모드로 전환되는 가상의 Ubuntu Server VM을 관리하고 있습니다. 이 문제는 선택적 데이터 볼륨 마운트를 추가한 직후에 발생했습니다 /etc/fstab. Casey는 콘솔에는 접근할 수 있지만 SSH 세션은 없습니다. 마운트 변경은 단서일 뿐 확정된 원인은 아닙니다. 비상 모드는 여러 번의 부팅 실패 후에 발생할 수 있으므로 Casey는 변경 작업을 하기 전에 현재 시스템의 로그를 확인합니다. 아래 터미널 패널은 실제 복구 또는 테스트가 아닌, 대표적인 레이아웃과 자리 표시자 출력입니다.

비상 모드란 무엇인가

systemd를 사용하는 Ubuntu Server 설치에서, `special-target` 명령어는 emergency.target메인 콘솔에서 최소한의 셸을 시작합니다. 이 명령어는 rescue.target필수 서비스만 포함된 기본 시스템과 시스템 마운트를 실행하는 `special-target` 명령어보다 기능이 제한적입니다. 비상 모드 진입 경로에 따라 루트 파일 시스템이 이미 읽기 전용 또는 읽기/쓰기 모드로 마운트되어 있을 수 있습니다. 이러한 상태를 가정하기 전에 반드시 확인하십시오. 자세한 내용은 systemd special-target 문서를 참조하십시오 .

먼저 프롬프트를 구분하세요. systemd 비상 셸은 일반적으로 "비상 모드에 오신 것을 환영합니다!"라는 메시지를 표시하고 유지 보수를 위해 루트 암호를 요청할 수 있습니다. BusyBox 프롬프트(예: )는 (initramfs)부팅이 아직 설치된 루트 파일 시스템으로 전환되지 않았음을 의미합니다. grub>또는 grub rescue>프롬프트는 부트로더 문제입니다. 이러한 프롬프트는 각각 다른 복구 경로를 필요로 합니다. 루트 계정이 잠겨 있거나 서버가 원격인 경우 호스팅 제공업체의 시리얼/VNC 콘솔 또는 복구 환경을 사용하세요. 일반적으로 이 단계에서는 SSH를 사용할 수 없습니다. 보고된 오류를 이해하고 해결하기 전까지는 Ctrl+D를 눌러 계속 진행하지 마세요.

단계별 구조

1. 콘솔 접근 권한을 유지하고 정확한 오류 내용을 기록하십시오.

비상 콘솔에 머무르세요. 마지막으로 실패한 마운트 또는 서비스 이름과 프롬프트 위에 출력된 장치 경로 또는 UUID를 기록해 두세요. Casey의 최근 fstab수정 사항을 확인해 보는 것이 좋지만, 모든 실패한 줄을 주석 처리하거나 "비상"이라는 단어만 보고 복구 명령을 실행하지 마세요. 시스템이 가상 머신인 경우, 복구 및 다음 재부팅 동안 공급자 콘솔을 열어 두세요.

2. 현재 부팅 기록과 실패한 장치를 읽습니다.

비상 셸에서 다음 명령을 실행하십시오.

journalctl -xb -p err --no-pager
systemctl --failed --no-pager

-b저널 쿼리를 해당 부팅 시점으로 제한하고 -p err오류 우선순위 이상을 필터링합니다. 단순히 "종속성 실패" 메시지의 마지막 연쇄 반응이 아니라, 관련 있는 첫 번째 오류를 찾으십시오. 마운트 장치가 실패한 경우, 이스케이프 처리된 장치 이름과 대상 경로를 기록하십시오. 서비스가 실패한 경우, 해당 서비스가 마운트 누락의 원인인지 결과인지 확인하십시오. Ubuntu journalctl(1)설명서 에는 부팅 및 장치 필터링에 대한 내용이 나와 있습니다.

3. 루트 마운트 및 사용 가능한 공간을 확인하십시오.

파일을 편집하거나 복구를 시도하기 전에 루트 파일 시스템이 어떻게 마운트되었는지, 시스템에 블록이나 inode가 부족하지 않은지 확인하십시오.

findmnt -no SOURCE,FSTYPE,OPTIONS /
df -h /
df -i /

findmnt출력 에서 ro는 읽기 전용을, 는 rw읽기/쓰기 가능을 의미합니다. 루트 파티션이 읽기 전용인 경우는 복구 과정의 일부로 의도적으로 설정될 수도 있고, 파일 시스템 문제를 반영할 수도 있습니다. 커널 로그에 I/O 또는 파일 시스템 오류가 보고되는 경우 즉시 읽기/쓰기 가능으로 강제 재마운트하지 마십시오. 파일 시스템 용량 초과 또는 inode 테이블 고갈로 인해 관련 없는 서비스 및 마운트가 실패할 수도 있습니다. 마운트된 파일 시스템을 검사하는 방법은 Ubuntu findmnt(8)설명서를 참조하십시오.

4. /etc/fstab기기 식별자를 검증하고 확인합니다.

Casey가 최근에 변경되었으므로 /etc/fstab구문과 참조된 장치가 존재하는지 여부를 모두 확인하십시오.

findmnt --verify --verbose
lsblk -f
blkid

findmnt --verify --verbosefstab 항목의 구문 분석 및 사용성 문제를 확인합니다. 의심스러운 행의 모든 ​​항목을 또는 UUID=에 표시된 UUID와 비교합니다 . 마운트 지점, 파일 시스템 유형 및 옵션도 확인합니다. 다른 디스크에서 복사한 UUID, 연결되지 않은 장치 또는 잘못된 옵션으로 인해 필수 마운트가 완료되지 않을 수 있습니다. 파티션 이름을 추측하지 마십시오. 장치 이름은 부팅할 때마다 변경될 수 있습니다.lsblk -fblkid/dev/sda1

5. 확인된 마운트 문제만 수정하십시오.

루트 파일 시스템에 쓰기 권한이 있고 fstab 검사에서 잘못된 행이 발견되면 편집하기 전에 백업을 만드십시오.

cp -a /etc/fstab /etc/fstab.before-rescue
nano /etc/fstab

의도한 장치를 확인한 후에만 UUID 또는 기타 필드를 수정하십시오. 마운트가 실제로 선택 사항이고 해당 볼륨이 없더라도 서버가 부팅되어야 하는 경우, systemd를 인식하는 fstab 줄을 사용하여 nofail유한한 장치 대기 시간을 설정할 수 있습니다. 예를 들어 다음과 같습니다.

UUID=VERIFIED-UUID /srv/archive ext4 defaults,nofail,x-systemd.device-timeout=10s 0 2

자리 표시자를 실제 UUID로 바꾸고 실제 파일 시스템 유형을 사용하십시오. nofail루트, 부팅 또는 시스템이나 응용 프로그램이 올바르게 작동하는 데 필요한 다른 파일 시스템에는 추가하지 마십시오. 옵션을 사용하면 nofail마운트가 실패하더라도 부팅이 진행되므로 종속 서비스는 여전히 처리해야 할 수 있습니다. Ubuntu systemd mount-unit 설명서 에서 이러한 fstab 옵션에 대한 자세한 내용을 확인할 수 있습니다.

편집 후 마운트를 시도하기 전에 다시 한번 유효성을 검사하십시오.

findmnt --verify --verbose
systemctl daemon-reload
mount /srv/archive

마지막 명령에서 실제 마운트 지점을 사용하십시오. 그래도 오류가 발생하면 새 오류 메시지를 읽고 디스크가 제대로 연결되어 있고 정상인지 확인하십시오. 루트 파일 시스템이 읽기 전용인 경우, 변경 사항을 무턱대고 강제로 적용하지 마십시오. 공급자 복구 환경이나 부팅 가능한 Ubuntu 미디어를 사용하여 설치된 시스템을 안전하게 검사하고 편집하십시오.

6. 서비스 실패는 저널에 실패 원인이 기록되어 있는 경우에만 조사하십시오.

비상 모드라고 해서 모든 서비스 오류가 부팅 중단을 유발하는 것은 아닙니다. 관련 오류에 서비스 이름이 언급되면 해당 서비스를 숨기거나 비활성화하는 대신 해당 서비스와 로그를 검사하십시오.

systemctl status example.service --no-pager
journalctl -u example.service -b --no-pager

정확한 장치 이름으로 바꾸십시오 example.service. 구성 파일, 실행 파일, 자격 증명 또는 필요한 마운트가 누락되었는지 확인하십시오. 오류가 Casey의 데이터 볼륨 누락과 관련된 경우, 먼저 해당 마운트를 수정하고 서비스를 다시 평가하십시오. 필수 서비스를 비활성화하면 서버를 사용할 수 없게 되면서 증상이 숨겨질 수 있습니다.

7. 파일 시스템 오류를 오프라인 복구 작업으로 처리하십시오.

커널 저널에 파일 시스템 손상 또는 스토리지 I/O 오류가 보고되면 가능한 한 쓰기 작업을 중지하고 복구하기 전에 백업 또는 공급자 스냅샷을 보존하십시오. 명령어를 사용하여 정확한 장치 및 파일 시스템을 확인하십시오 lsblk -f. 루트 파일 시스템의 경우 공급자의 복구 시스템 또는 Ubuntu 복구/라이브 미디어로 부팅하여 대상 파티션이 마운트 해제되었는지 확인하고 해당 파일 시스템에 적합한 검사 도구를 사용하십시오. ext2/3/4의 경우 해당 도구는 입니다 e2fsck. XFS, Btrfs 및 기타 형식은 절차가 다릅니다.

마운트된 파일 시스템(읽기 전용 루트 디스크 포함)에서는 절대로 명령어를 실행 fsck하거나 검사하지 마십시오. 우분투 설명서 에서는 마운트된 파일 시스템을 검사하는 것은 일반적으로 안전하지 않으며 검사 결과가 유효하지 않다고 경고합니다. 디스크에서 반복적인 I/O 오류가 보고되는 경우, 복구를 반복적으로 시도하기보다는 데이터 복구 또는 스토리지 제공업체에 문의하는 것을 우선시해야 합니다.e2fscke2fsck(8)

8. 정상 부팅으로 돌아가서 결과를 확인하십시오.

확인된 원인을 해결한 후에는 콘솔에서 시스템을 재부팅하십시오.

systemctl reboot

우분투가 시작되면 구성된 기본 대상, 현재 시스템 상태, 실패한 장치 및 새 부팅 상태를 확인하십시오.

systemctl get-default
systemctl is-system-running
systemctl --failed --no-pager
journalctl -b -p err --no-pager
findmnt --verify --verbose

의도적으로 현재 부팅 상태를 유지하려는 경우, systemctl defaultsystemd에게 구성된 기본 대상을 시작하도록 요청합니다. 차단 오류가 해결된 후에만 사용하십시오. 잘못된 마운트 또는 손상된 파일 시스템을 복구하지는 않습니다. systemctl get-default구성된 기본 대상을 표시하고 systemctl is-system-runningsystemd가 현재 상태를 실행 중, 저하됨 또는 기타 상태로 간주하는지 여부를 보고합니다. 정상적인 복구란 예상되는 파일 시스템이 마운트되고, 필요한 서비스가 활성화되어 있으며, 재부팅 후 동일한 비상 상황이 재발하지 않는 것을 의미합니다.

프롬프트가 (initramfs)다음과 같으면

BusyBox initramfs에서 systemd emergency-shell 단계를 맹목적으로 적용하지 마십시오. initramfs 단계는 설치된 시스템으로 제어권을 넘기기 전에 실제 루트 파일 시스템을 찾아 마운트하려고 시도합니다. 정확한 오류를 기록하고, 예상되는 장치가 와 에 나타나는지 확인하고 /dev, /dev/disk/by-uuid부팅 명령줄의 root=값을 실제 루트 UUID와 비교하십시오. 디스크 또는 암호화/LVM 볼륨이 없는 경우 공급업체의 스토리지 및 복구 도구를 사용하여 조사하십시오. 누락된 장치를 확인하지 않고 initramfs를 재구축하거나 GRUB 매개변수를 변경하면 부팅 복구가 더 어려워질 수 있습니다.

Casey의 가상 VM에서 유용한 결과는 원인 검증과 범위가 좁은 수정입니다. 즉, 예상되는 선택적 볼륨을 복원하고, 확인된 식별자를 수정하거나, 워크로드가 실제로 허용하는 경우에만 선택적 볼륨으로 구성하는 것입니다. 그런 다음 복구 세션을 종료하기 전에 콘솔에서 다음 부팅을 확인합니다.