beautifulsoups.dev
Published on

Azure VM 부팅불가? Boot Diagnostics로 복구

Authors

운영 중인 Azure VM이 갑자기 부팅되지 않으면 가장 먼저 드는 생각은 “SSH나 RDP로 들어가서 로그를 보자”지만, 부팅 단계에서 멈춘 VM은 원격 접속 자체가 불가능합니다. 이때 Azure가 제공하는 Boot Diagnostics는 “VM 내부로 들어가지 못하는 상황”에서도 초기 부팅 상태를 확인할 수 있는 거의 유일한 단서입니다.

이 글에서는 Boot Diagnostics로 증상 분류를 하고, Serial Console과 복구용 VM에 OS 디스크를 붙여 오프라인 수정하는 방식으로 복구하는 실전 흐름을 정리합니다. 리눅스 기준으로 설명하되, Windows도 유사한 구조로 적용할 수 있습니다.

Boot Diagnostics가 제공하는 것

Boot Diagnostics는 VM 부팅 과정에서 Azure 호스트가 수집하는 다음 정보를 제공합니다.

  • 스크린샷: 콘솔 화면을 캡처한 이미지
  • 직렬 콘솔 로그(Serial console output): 커널/부트로더 단계에서 출력되는 텍스트 로그
  • (환경에 따라) 부팅 진단 스토리지: Managed storage 또는 Storage Account에 로그가 저장

이 정보가 중요한 이유는, VM이 네트워크를 올리기 전 단계(커널 패닉, initramfs, 부트로더, 파일시스템 마운트 실패 등)에서 멈춰도 흔적이 남기 때문입니다.

1단계: 증상 분류 체크리스트

Azure Portal에서 VM을 열고 다음 순서로 확인합니다.

  1. Boot diagnostics 메뉴에서 스크린샷 확인
  2. 같은 화면에서 Serial log 확인
  3. Serial console 사용 가능 여부 확인(리눅스는 대체로 유용)

스크린샷/로그를 보고 아래처럼 분류하면 복구 루트가 빨라집니다.

A. 커널 패닉 또는 initramfs 드롭

로그에 다음과 유사한 패턴이 보이면 커널/드라이버/루트 디스크 인식 문제가 많습니다.

  • Kernel panic - not syncing
  • VFS: Unable to mount root fs
  • dracut-initqueue timeout
  • ALERT! UUID=... does not exist. Dropping to a shell!

주요 원인

  • fstab에 잘못된 UUID 또는 디바이스 경로
  • 커널 업데이트 후 initramfs 꼬임
  • 디스크/파티션 구조 변경 후 부트로더 설정 불일치

B. 파일시스템 마운트 실패 또는 fsck 요구

  • EXT4-fs error
  • XFS (sdaX): Corruption detected
  • Entering emergency mode

주요 원인

  • 비정상 종료로 파일시스템 저널 손상
  • 디스크 용량 100%로 인한 부팅 서비스 실패

C. 부팅은 되는데 SSH/RDP만 안 됨

부팅 스크린샷이 로그인 프롬프트까지 도달했거나, 로그가 정상인데 접속만 안 된다면 네트워크/방화벽/에이전트 문제일 수 있습니다.

  • NSG 인바운드 규칙
  • NIC/라우팅
  • sshd 설정 오류 또는 cloud-init 실패
  • OS 방화벽(예: firewalld, ufw)

이 케이스는 Boot Diagnostics로 “부팅 자체는 성공”임을 확인한 뒤 네트워크 계층을 점검하는 흐름이 좋습니다.

2단계: Serial Console로 즉시 복구 시도(가능한 경우)

Serial Console이 활성화되어 있고, VM이 커널까지 올라오면 원격 접속 없이도 최소한의 조치를 할 수 있습니다.

Serial Console 사전 조건

  • 부팅 진단 활성화
  • OS가 시리얼 콘솔 출력/로그인을 허용
  • Azure의 Serial Console 기능이 해당 이미지/정책에서 차단되지 않음

대표 복구: fstab 오타로 emergency mode 진입

Serial Console에서 root 또는 sudo 가능한 계정으로 진입한 뒤:

sudo -i
journalctl -xb | tail -n 200

# fstab 확인
cat /etc/fstab

# UUID 확인
blkid

/etc/fstab의 UUID가 실제 blkid 결과와 다르면 수정합니다.

sudo vi /etc/fstab

수정 후 재부팅:

sudo reboot

대표 복구: 디스크 100%로 서비스 실패

부팅은 되지만 서비스가 연쇄 실패하는 경우, 시리얼 콘솔에서 용량부터 확인합니다.

df -h
sudo du -xhd1 /var | sort -h

로그 폭증이 원인이면 로그 로테이션/정리도 함께 고려해야 합니다. 운영 환경에서 logrotate가 멈춰 디스크가 가득 차 부팅 후 서비스가 죽는 케이스가 흔합니다. 관련 체크리스트는 리눅스 logrotate가 안 돎? 권한·SELinux 점검도 참고하면 좋습니다.

3단계: 오프라인 복구(가장 확실한 방법)

Serial Console로 해결이 안 되거나, VM이 커널 단계 이전에서 멈춘다면 OS 디스크를 분리해 다른 VM에 붙여 수정하는 방식이 가장 성공률이 높습니다.

핵심 아이디어는 단순합니다.

  • 문제 VM을 정지(Stop)
  • OS 디스크(Managed Disk)를 분리
  • 정상 VM(복구 VM)에 데이터 디스크로 Attach
  • 마운트해서 설정/부트로더/파일시스템을 고친 뒤
  • 다시 원래 VM에 OS 디스크로 연결

안전 절차 요약

  1. 문제 VM Stop(Deallocate 권장)
  2. OS 디스크 스냅샷 생성(실패 대비)
  3. 복구 VM 준비(동일 리전/가급적 동일 OS 계열)
  4. OS 디스크를 복구 VM에 데이터 디스크로 연결
  5. 복구 VM에서 마운트 후 수정
  6. 언마운트 및 디스크 분리
  7. 원래 VM에 OS 디스크로 재연결 후 부팅

Azure CLI 예시: 스냅샷 생성

아래는 Managed Disk 스냅샷을 만드는 예시입니다.

RG="my-rg"
DISK_NAME="problemvm_OsDisk_1_abcdef"
SNAP_NAME="problemvm-osdisk-snap-20260224"

az snapshot create \
  --resource-group "$RG" \
  --name "$SNAP_NAME" \
  --source "$DISK_NAME"

복구 VM에서 디스크 마운트

복구 VM에서 새로 붙은 디스크를 확인합니다.

lsblk
sudo fdisk -l

예를 들어 파티션이 /dev/sdc2에 루트 파일시스템이 있다면:

sudo mkdir -p /mnt/rescue
sudo mount /dev/sdc2 /mnt/rescue

# 부트 파티션이 별도면 같이 마운트
sudo mkdir -p /mnt/rescue/boot
sudo mount /dev/sdc1 /mnt/rescue/boot

이제 /mnt/rescue 아래가 “문제 VM의 루트”입니다.

4단계: 자주 터지는 원인별 오프라인 수정법

4-1. fstab 잘못된 UUID/디바이스 경로

오프라인에서 fstab를 열고 UUID를 맞춥니다.

sudo cat /mnt/rescue/etc/fstab
sudo blkid /dev/sdc*

sudo vi /mnt/rescue/etc/fstab

가능하면 /dev/sdX 같은 가변 경로 대신 UUID를 쓰되, UUID가 실제와 일치하는지 항상 확인합니다.

4-2. 파일시스템 손상: fsck 또는 xfs_repair

마운트 해제 후 복구 도구를 실행하는 편이 안전합니다.

sudo umount /mnt/rescue

# ext4 예시
sudo fsck -f -y /dev/sdc2

# 다시 마운트
sudo mount /dev/sdc2 /mnt/rescue

XFS라면:

sudo umount /mnt/rescue
sudo xfs_repair /dev/sdc2
sudo mount /dev/sdc2 /mnt/rescue

4-3. 부트로더/커널 업데이트 꼬임

부트 관련 이슈는 chroot로 들어가 패키지 재설치/부트로더 재구성이 필요할 수 있습니다.

chroot를 위한 기본 마운트:

sudo mount --bind /dev /mnt/rescue/dev
sudo mount --bind /proc /mnt/rescue/proc
sudo mount --bind /sys /mnt/rescue/sys

sudo chroot /mnt/rescue /bin/bash

Debian/Ubuntu 계열 예시(커널/GRUB 재설치):

apt update
apt install --reinstall grub-pc
update-grub

RHEL/CentOS 계열은 grub2-mkconfig나 dracut 재생성이 필요할 수 있습니다.

dracut -f
grub2-mkconfig -o /boot/grub2/grub.cfg

작업 후 exit로 빠져나오고, 바인드 마운트를 해제합니다.

exit
sudo umount /mnt/rescue/dev /mnt/rescue/proc /mnt/rescue/sys
sudo umount /mnt/rescue/boot || true
sudo umount /mnt/rescue

5단계: 다시 부팅하기 전 점검 포인트

  • 스냅샷이 있는지(롤백 경로)
  • 디스크가 깨끗하게 언마운트되었는지
  • 원래 VM에 OS 디스크가 제대로 연결되었는지
  • 부팅 진단을 켠 상태로 재부팅하여 동일 증상이 재현되는지 확인

재부팅 후에도 장애가 반복되면, Boot Diagnostics 로그를 기반으로 “부팅 단계가 어디까지 진행되는지”를 다시 확인하고, 수정한 항목이 실제로 반영되었는지(예: 올바른 파티션을 고쳤는지, /boot 별도 구성인데 루트만 수정한 건 아닌지)부터 재점검하는 것이 좋습니다.

운영 관점: 재발 방지 체크리스트

부팅 불능은 한 번 복구해도 재발하면 더 큰 사고로 이어집니다. 아래 항목을 같이 정리해두면 좋습니다.

  • 정기 스냅샷 정책(일 단위 또는 배포 전)
  • 커널/부트로더 업데이트는 변경 관리 하에 수행
  • 디스크 사용량 알람(특히 /var/log, /tmp)
  • cloud-init/에이전트 업데이트 시 롤백 플랜
  • 부팅 진단 항상 활성화(최소 비용으로 큰 효과)

운영 자동화 스크립트를 작성할 때는 실패 시 중간 상태가 남지 않게 방어적으로 코딩해야 합니다. 특히 bash에서 set -euo pipefail을 사용하면 복구 스크립트가 의도치 않게 중단되는 함정이 있으니, 자동화 시에는 예외 처리를 명확히 하세요. 관련 내용은 bash set -euo pipefail 함정과 안전한 예외처리를 참고할 수 있습니다.

마무리

Azure VM 부팅 불능은 “접속이 안 되니 아무것도 못 한다”로 느껴지기 쉽지만, 실제로는 Boot Diagnostics만 제대로 보면 원인의 절반은 분류가 끝납니다. 그 다음은 두 갈래입니다.

  • Serial Console로 빠르게 설정을 되돌릴 수 있으면 즉시 복구
  • 안 되면 OS 디스크를 오프라인으로 붙여 수정하는 정석 루트

중요한 건, 복구 과정에서 실수를 줄이기 위해 스냅샷을 먼저 만들고, 변경을 최소화하며, Boot Diagnostics로 “부팅이 어디까지 왔는지”를 계속 확인하는 것입니다. 이렇게 하면 재부팅 가능한 상태로 되돌리는 데 걸리는 시간을 크게 줄일 수 있습니다.

Discuss on Twitter • View on GitHub