beautifulsoups.dev
Published on

Azure VM 부팅 실패? Boot Diagnostics로 5분 복구

Authors

Azure VM이 갑자기 부팅 실패(boot failure) 상태로 빠지면 보통 다음 증상으로 시작합니다.

  • 포털에서 VM 상태는 Running인데 SSH/RDP 접속이 안 됨
  • Booting... 화면에서 멈춘 것처럼 보이거나, 커널 패닉/파일시스템 오류로 재부팅 반복
  • 최근 커널 업데이트, fstab 수정, 디스크 마운트 변경, cloud-init 변경 이후 발생

이때 가장 먼저 해야 할 일은 “네트워크 문제인지, OS 부팅 문제인지”를 5분 안에 분리하는 것입니다. 네트워크 문제(예: NSG/UDR/DNS)면 Boot Diagnostics를 봐도 답이 없고, 반대로 OS 부팅 문제면 네트워크를 아무리 뒤져도 해결이 안 됩니다.

네트워크 진단 체크가 필요하다면 아래 글도 같이 참고하세요.

이 글은 OS 부팅 단계에서 막힌 케이스를 전제로, Boot Diagnostics(부트 진단) 만으로 원인 파악 → 즉시 복구까지 가는 루트를 실전 위주로 정리합니다.

Boot Diagnostics가 “부팅 실패”에서 가장 빠른 이유

Azure의 Boot Diagnostics는 VM 에이전트나 네트워크 접속 없이도 다음을 제공합니다.

  • 부팅 스크린샷: Hyper-V 콘솔 화면 캡처
  • 시리얼 콘솔 로그(Serial console output): 커널/부트로더/클라우드-이닛 출력

즉, SSH가 죽어도 부팅 시점 로그로 “어디서 멈췄는지”를 바로 확인할 수 있습니다. 특히 Linux에서 다음 유형을 1~2분 내로 분류할 수 있습니다.

  • GRUB/부트로더 단계에서 멈춤
  • initramfs / root filesystem 마운트 실패
  • fstab 오류로 emergency mode 진입
  • 디스크/파티션 UUID 변경으로 root 디바이스 탐색 실패
  • cloud-init이 네트워크/패키지 단계에서 무한 대기
  • 커널 패닉/드라이버 문제

0) 먼저 “Boot Diagnostics 활성화 여부”부터 확인

포털에서 VM → Boot diagnostics로 들어가면 보통 2가지 모드 중 하나입니다.

  • Managed storage: Azure가 관리하는 스토리지에 진단 로그 저장(권장)
  • Custom storage account: 사용자가 지정한 Storage Account에 저장

부팅 장애 상황에서는 “커스텀 스토리지 계정”이 방화벽/프라이빗 엔드포인트 정책 등으로 막혀 로그 업로드가 실패할 수도 있습니다. 가능하면 Managed storage로 바꿔두면 장애 시점에 진단 데이터가 더 잘 남습니다.

> 팁: Boot Diagnostics가 꺼져 있었다면 켜고 VM을 재시작해야 스크린샷/로그가 쌓입니다.

1) 스크린샷으로 1차 분기: 부트로더 vs 커널 vs 로그인

Boot Diagnostics의 스크린샷을 보면 대략 아래 중 어디인지가 바로 보입니다.

A. GRUB 화면/부트로더에서 멈춤

  • grub> 프롬프트
  • No bootable device
  • EFI 관련 오류

이 경우 OS 레벨 복구보다 부트 파티션/부팅 레코드/UEFI 설정 쪽 이슈일 가능성이 큽니다. 커널 업데이트 중단, /boot 용량 부족, 잘못된 grub.cfg 등이 원인일 수 있습니다.

B. 커널 부팅 중 멈춤 또는 커널 패닉

  • Kernel panic - not syncing
  • VFS: Unable to mount root fs
  • dracut-initqueue timeout

대부분 root filesystem 마운트 실패 또는 initramfs 문제입니다.

C. 로그인 프롬프트까지 왔는데 접속만 안 됨

스크린샷에 login: 이 보이면 OS는 부팅이 끝난 겁니다. 이때는 OS 내부 네트워크/sshd 문제거나, 더 흔하게는 NSG/UDR/DNS 문제입니다(위 내부 링크 참고).

2) 시리얼 로그로 “정확히 어디서 멈췄는지” 잡기

Boot Diagnostics에서 Serial log를 열어 마지막 수십 줄을 봅니다. 아래는 자주 나오는 패턴과 바로 이어지는 복구 방향입니다.

패턴 1: fstab 오류로 emergency mode

로그 예시(대표 패턴):

[  OK  ] Started File System Check on /dev/disk/by-uuid/....
[FAILED] Failed to mount /data.
Dependency failed for Local File Systems.
You are in emergency mode. After logging in, type "journalctl -xb" ...

의미:

  • /etc/fstab에 있는 디스크/UUID가 바뀌었거나
  • 해당 디스크가 분리/손상되었거나
  • 네트워크 파일시스템(NFS 등)이 부팅 시점에 안 올라오는데 nofail 옵션이 없음

즉시 복구 전략:

  • 문제 마운트 항목을 임시로 비활성화(주석 처리)하거나
  • nofail,x-systemd.device-timeout=...로 부팅을 막지 않게 변경

패턴 2: root fs 마운트 실패 (initramfs/dracut)

dracu-initqueue[xxx]: Warning: dracut-initqueue timeout
Warning: /dev/disk/by-uuid/.... does not exist
Dropping to debug shell.

의미:

  • OS 디스크 파티션 UUID 변경
  • initramfs에 필요한 드라이버/모듈 누락
  • 디스크 자체 인식 실패

이 경우는 VM 내부로 들어가 수정이 어렵기 때문에, 보통 OS 디스크를 다른 복구 VM에 붙여 오프라인 수정이 가장 빠릅니다.

패턴 3: cloud-init이 특정 단계에서 멈춤

cloud-init[xxx]: ... waiting for network to be configured
cloud-init[xxx]: ...

의미:

  • netplan/NetworkManager 설정이 꼬였거나
  • cloud-init 데이터 소스/사용자 데이터가 부팅을 블로킹

해결은 cloud-init 설정을 오프라인으로 수정하거나, 문제되는 user-data를 제거하는 방식이 일반적입니다.

3) 5분 복구 루트: “OS 디스크 스왑(오프라인 수정)”

SSH가 안 되고 부팅도 안 되면, 현장에서 가장 성공률 높은 방법은 아래입니다.

  1. 문제 VM을 Stop (deallocate)
  2. 문제 VM의 OS 디스크를 분리
  3. 정상 복구용 VM(Rescue VM)을 하나 띄운 뒤
  4. 분리한 OS 디스크를 데이터 디스크로 Attach
  5. Rescue VM에서 마운트 후 설정 수정
  6. 원래 VM에 OS 디스크를 다시 붙이고 부팅

이 과정은 포털에서도 되지만, 반복 작업이라면 Azure CLI가 훨씬 빠릅니다.

Azure CLI 예시: OS 디스크 분리/부착 흐름

> 아래는 이해를 돕기 위한 뼈대 코드입니다. 실제 환경에 맞게 리소스명/디스크명/VM명을 바꾸세요.

# 1) 문제 VM 중지(할당 해제)
az vm deallocate -g rg-prod -n vm-broken

# 2) OS 디스크 이름 확인
az vm show -g rg-prod -n vm-broken --query "storageProfile.osDisk.name" -o tsv

# 3) OS 디스크 ID 확인
OS_DISK_ID=$(az disk show -g rg-prod -n vm-broken-osdisk --query id -o tsv)

# 4) 복구 VM에 데이터 디스크로 attach
az vm disk attach -g rg-prod --vm-name vm-rescue --disk $OS_DISK_ID --name broken-osdisk

Rescue VM에서 디스크가 /dev/sdc 같은 형태로 보이면 파티션을 확인하고 마운트합니다.

lsblk
sudo mkdir -p /mnt/broken
sudo mount /dev/sdc2 /mnt/broken   # 예: root 파티션이 2번인 경우

# fstab 확인
sudo sed -n '1,200p' /mnt/broken/etc/fstab

fstab로 부팅이 막힌 경우: 가장 빠른 응급처치

  • 실패하는 마운트 라인을 주석 처리하거나
  • nofail 옵션을 추가해 부팅 블로킹을 제거합니다.
# 예: /data 마운트가 문제라면 주석 처리
sudo cp /mnt/broken/etc/fstab /mnt/broken/etc/fstab.bak
sudo sed -i 's|^UUID=xxxx-xxxx  /data|#UUID=xxxx-xxxx  /data|g' /mnt/broken/etc/fstab

수정 후 언마운트:

sudo umount /mnt/broken

그리고 원래 VM에서 OS 디스크를 다시 사용하도록 되돌립니다(환경에 따라 detach/attach 또는 VM 재생성이 필요할 수 있음).

4) Boot Diagnostics로 “복구 후 재발 방지”까지 마무리

부팅이 살아났다면, 같은 유형의 장애가 재발하지 않게 아래를 점검합니다.

/etc/fstab 안전장치

  • 외부/보조 디스크 마운트는 기본적으로 nofail 고려
  • 네트워크 파일시스템은 x-systemd.automount, x-systemd.device-timeout=30 등으로 부팅 블로킹 최소화

예시:

UUID=...  /data  ext4  defaults,nofail,x-systemd.device-timeout=30  0  2

/boot 용량 및 커널 업데이트 정책

  • /boot가 꽉 차면 커널/GRUB 업데이트가 중간 실패하면서 부팅 불능이 될 수 있습니다.
  • 정기적으로 오래된 커널을 정리하고, 자동 업데이트 정책을 운영 환경에 맞게 조정하세요.

진단 로그 보존 정책

  • Boot Diagnostics는 장애 순간에 가장 가치가 큽니다.
  • 가능하면 Managed storage를 사용하고, 운영 표준에 포함시키세요.

5) 자주 묻는 케이스별 “빠른 판단표”

  • 스크린샷에 login: 보임 → OS 부팅 성공. NSG/UDR/DNS/sshd 쪽 점검
  • You are in emergency mode → fstab/마운트 실패 확률 높음. 오프라인 수정이 빠름
  • VFS: Unable to mount root fs / dracut-initqueue timeout → root 디바이스 탐색 실패. 디스크/UUID/드라이버 확인
  • No bootable device → 부트 파티션/부트로더/UEFI 설정 문제. 스냅샷/백업 여부부터 확인

결론: “부팅 실패”는 Boot Diagnostics로 절반은 끝난다

Azure VM 부팅 실패는 겉으로 보면 “접속이 안 된다”로 뭉뚱그려지지만, Boot Diagnostics 한 번이면 부트로더/커널/파일시스템/클라우드-이닛 중 어디가 문제인지가 즉시 갈립니다.

  • 스크린샷으로 부팅 단계 분기
  • 시리얼 로그로 실패 지점 특정
  • 접속 불가라면 OS 디스크 오프라인 수정으로 5분 복구 루트 확보

운영 환경에서는 Boot Diagnostics를 기본 활성화하고, fstab/업데이트 정책에 안전장치를 넣는 것만으로도 “갑작스런 부팅 불능”의 평균 복구 시간을 크게 줄일 수 있습니다.

Discuss on Twitter • View on GitHub