beautifulsoups.dev
Published on

Azure VM 부팅 실패, Boot diagnostics로 원인 찾고 복구

Authors

서버가 죽는 것보다 더 곤란한 순간은 서버가 ‘아예 부팅을 못 하는’ 상황입니다. SSH/RDP는 당연히 안 붙고, 에이전트도 올라오지 않으니 모니터링/로그 수집도 멈춥니다. 이때 Azure에서 가장 먼저 확인해야 하는 것이 Boot diagnostics입니다.

Boot diagnostics는 VM의 부팅 스크린샷과 시리얼 콘솔 로그를 제공해, 커널 패닉/부트로더 손상/파일시스템 오류/클라우드-이니트(cloud-init) 실패 같은 문제를 “원격 콘솔 없이”도 추적할 수 있게 합니다.

이 글에서는 Azure Portal/CLI를 기준으로 원인 파악 → 즉시 복구(재부팅/수리) → 오프라인 디스크 복구 → 최후의 수단(재배포/복원) 순서로 정리합니다.

1) Boot diagnostics가 제공하는 것과 한계

무엇을 얻을 수 있나

  • Screenshot: 부팅 단계에서 멈춘 화면(예: GRUB, initramfs, fsck 프롬프트, Windows 자동 복구 화면)
  • Serial console output: 커널/부트 서비스/클라우드-이니트 로그 등 텍스트 기반 로그
  • (환경에 따라) 부트 로그 파일 다운로드

한계

  • OS가 완전히 멈춰도 화면/시리얼에 아무것도 안 남는 경우가 있습니다(초기 부트로더 단계, 커널 로드 전 장애 등).
  • 암호화(BitLocker, dm-crypt/LUKS)나 커스텀 이미지 정책에 따라 오프라인 복구가 까다로울 수 있습니다.

2) 가장 먼저 할 일: 증상 분류(부팅 단계별)

Boot diagnostics 스크린샷/시리얼 로그로 “어디에서 멈췄는지”를 분류하면 복구 루트가 크게 단축됩니다.

A. GRUB/부트로더 단계에서 멈춤

  • 예: grub rescue>, no such partition, unknown filesystem
  • 원인 후보: 파티션 테이블/부트로더 손상, 디스크 장치 경로 변경, 부트 항목 잘못 수정

B. initramfs / dracut / emergency mode

  • 예: ALERT! /dev/sda2 does not exist, You are in emergency mode
  • 원인 후보: fstab 오류, 디스크 UUID 변경, LVM/RAID 인식 실패

C. 파일시스템 체크(fsck)에서 멈춤

  • 예: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY
  • 원인 후보: 비정상 종료로 인한 FS 손상, 디스크 오류

D. cloud-init/에이전트 단계에서 지연 또는 실패

  • 예: cloud-init이 네트워크/메타데이터에서 대기하다 타임아웃
  • 원인 후보: 네트워크(NSG/UDR) 변경, DNS 문제, IMDS 접근 실패

E. Windows 자동 복구/부팅 루프

  • 예: Preparing Automatic Repair, INACCESSIBLE_BOOT_DEVICE
  • 원인 후보: 드라이버/업데이트, BCD 손상, 디스크/컨트롤러 변경

3) Boot diagnostics 확인 방법(Portal/CLI)

Portal

  1. VM 선택
  2. Help 또는 Support + troubleshooting 섹션에서 Boot diagnostics
  3. Screenshot / Serial log 확인

Azure CLI

아래는 “부팅 진단 데이터”를 직접 내려받기 위한 실무 패턴입니다(스토리지 계정 기반 진단을 쓰는 경우가 많습니다).

# 1) VM의 인스턴스 뷰에서 부트 진단 URI/상태 확인
az vm get-instance-view \
  -g <rg> -n <vmname> \
  --query "instanceView.bootDiagnostics" -o json

# 2) 부트 진단이 저장되는 스토리지(또는 managed) 설정은 VM 진단 프로퍼티에서 확인
az vm show -g <rg> -n <vmname> \
  --query "diagnosticsProfile.bootDiagnostics" -o json

> 진단이 꺼져 있다면(특히 오래된 VM/커스텀 이미지) 다음 장애 때를 대비해 항상 켜두는 것이 좋습니다.

4) 빠른 복구 1차: 재부팅/재배포 전 체크리스트

부팅 실패 시 “무작정 재배포(redeploy)”는 위험할 수 있습니다. 먼저 아래를 확인합니다.

  • 최근 변경 사항: 커널 업데이트, fstab 수정, 디스크 확장, 네트워크 변경(NSG/UDR), 클라우드-이니트 변경
  • 데이터 디스크/OS 디스크 상태: 스냅샷/백업 존재 여부
  • 부팅 진단 로그에서 명확한 오류 문자열(fstab, fsck, grub, kernel panic)

재부팅(가장 저렴한 시도)

az vm restart -g <rg> -n <vmname>

재배포(호스트 문제 의심 시)

호스트 노드 이슈로 부팅이 꼬인 경우가 드물게 있습니다. 이때 Redeploy는 VM을 다른 호스트로 옮겨 부팅을 재시도합니다.

az vm redeploy -g <rg> -n <vmname>
  • 장점: 빠르고 간단
  • 단점: OS 내부 파일 손상/부트로더 손상 같은 “디스크 자체 문제”는 해결 못 함

5) 핵심 복구 루트: OS 디스크 오프라인 복구(리커버리 VM)

Boot diagnostics에서 fstab 오류, fsck 필요, grub 손상 등이 보이면, 가장 확실한 방법은:

  1. 문제 VM을 정지(deallocate)
  2. OS 디스크를 분리(detach)
  3. 정상 VM(리커버리 VM)에 데이터 디스크로 연결(attach)
  4. 마운트 후 수정/복구
  5. 원래 VM에 다시 연결

5-1) 안전장치: 스냅샷 먼저

실수로 더 망가뜨리는 경우가 많습니다. 오프라인 복구 전 스냅샷은 거의 필수입니다.

# VM 정지(디스크 분리 전 권장)
az vm deallocate -g <rg> -n <vmname>

# OS 디스크 이름 확인
osdisk=$(az vm show -g <rg> -n <vmname> --query "storageProfile.osDisk.name" -o tsv)

# 스냅샷 생성
az snapshot create -g <rg> \
  -n ${osdisk}-snap-$(date +%Y%m%d%H%M) \
  --source $osdisk

5-2) 리커버리 VM에 OS 디스크 연결

Portal에서도 가능하지만, CLI 흐름을 알아두면 자동화/재현이 쉽습니다.

# 문제 VM에서 OS 디스크 분리(방법 1: VM 업데이트로 OS 디스크 교체는 복잡할 수 있어 보통 Portal 사용)
# 실무에서는 Portal에서 OS 디스크를 'Detach'하거나,
# 스냅샷으로 새 디스크를 만들어 리커버리 VM에 attach하는 방식이 안전합니다.

# 스냅샷에서 새 managed disk 생성
az disk create -g <rg> -n ${osdisk}-repair \
  --source ${osdisk}-snap-<timestamp>

# 리커버리 VM에 데이터 디스크로 attach
az vm disk attach -g <rg> --vm-name <recovery-vm> \
  --name ${osdisk}-repair

> 원본 OS 디스크를 직접 만지는 것보다 스냅샷에서 복제 디스크를 떠서 수리한 뒤 교체하는 방식이 롤백이 쉬워 안전합니다.

5-3) Linux: 마운트 후 자주 터지는 원인 고치기

리커버리 VM에 디스크가 /dev/sdc 같은 형태로 붙었다고 가정합니다.

# 파티션 확인
lsblk -f

# 예: /dev/sdc2 가 루트 파티션이라면
sudo mkdir -p /mnt/repair
sudo mount /dev/sdc2 /mnt/repair

# 부팅 관련 설정 확인
sudo cat /mnt/repair/etc/fstab
sudo ls -al /mnt/repair/boot

(1) /etc/fstab 오타/UUID 불일치

부팅 진단에서 Dependency failed for /... 또는 cannot mount 류가 보이면 fstab이 흔한 원인입니다.

  • 불필요한 마운트 항목을 임시로 nofail 옵션으로 바꾸거나
  • 잘못된 UUID를 올바른 UUID로 교체
# 디스크 UUID 확인(리커버리 VM 기준)
sudo blkid

# fstab 편집
sudo nano /mnt/repair/etc/fstab

(2) 파일시스템 손상: fsck

스크린샷에 “fsck manually”가 보이면 오프라인에서 fsck를 수행합니다.

# 마운트 해제 후 fsck (마운트된 상태에서 하면 위험)
sudo umount /mnt/repair

# ext4 예시
sudo fsck -fy /dev/sdc2

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

(3) 디스크 꽉 참/인오드 고갈로 부팅 실패

부팅 과정에서 로그/임시파일 생성이 안 되면 서비스가 연쇄적으로 죽으면서 부팅이 멈춘 것처럼 보일 수 있습니다. 특히 “용량은 남았는데 No space left”라면 인오드 고갈을 의심해야 합니다. 이 케이스는 아래 글의 체크리스트가 그대로 도움이 됩니다.

(4) GRUB/부트로더 복구(상황에 따라)

부트로더가 깨진 경우는 배포판/부팅 방식(UEFI/BIOS)에 따라 절차가 달라집니다. 일반적인 접근은 chroot 후 grub 재설치지만, Azure 세부 설정에 따라 달라질 수 있어 “스크린샷에 GRUB rescue가 보일 때”만 신중히 진행하세요.

# (예시) chroot 준비
sudo mount --bind /dev  /mnt/repair/dev
sudo mount --bind /proc /mnt/repair/proc
sudo mount --bind /sys  /mnt/repair/sys
sudo chroot /mnt/repair /bin/bash

# 배포판에 맞게 grub 재설치/갱신 (예: Ubuntu)
update-grub
# grub-install 대상 디스크는 환경에 따라 다름
# grub-install /dev/sdc
exit

5-4) Windows: BCD/부팅 복구 개요

Windows는 리커버리 VM에 디스크를 붙인 뒤, Windows Recovery 환경 또는 bcdboot/bootrec로 복구하는 식입니다. 실무에서는 “스냅샷 → 복제 디스크 → 복구 시도 → 교체” 흐름이 안전합니다.

6) 수리한 디스크로 원래 VM 복구(교체/재연결)

수리한 디스크를 원래 VM의 OS 디스크로 교체하는 방식은 Portal이 직관적입니다.

  • 원래 VM 정지(deallocate)
  • OS 디스크를 수리된 디스크로 교체(또는 새 VM 생성 후 디스크 연결)
  • 부팅 후 Boot diagnostics로 재확인

CLI로도 가능하지만 OS 디스크 교체는 실수 시 영향이 커서, 운영 환경에서는 변경 이력을 남기기 쉬운 IaC(Terraform/Bicep) 또는 Portal 작업 + 변경 기록을 권장합니다.

7) Boot diagnostics 로그에서 자주 보이는 메시지 패턴

Linux

  • Kernel panic - not syncing: 커널/드라이버/파일시스템 심각 오류
  • ALERT! UUID=... does not exist: fstab/UUID 불일치
  • You are in emergency mode: 마운트 실패, fsck 필요
  • cloud-init ... failed: 네트워크/메타데이터/사용자 데이터 문제

Windows

  • INACCESSIBLE_BOOT_DEVICE: 스토리지 드라이버/부팅 디바이스 인식 문제
  • Automatic Repair couldn't repair your PC: 업데이트/부팅 구성 손상

8) 재발 방지: 부팅 실패를 ‘관측 가능’하게 만들기

부팅 실패는 종종 “원인 자체”보다 원인을 못 보는 것이 더 큰 문제입니다. 다음을 권장합니다.

  1. Boot diagnostics 상시 활성화
  2. 정기 OS 디스크 스냅샷/백업 정책(업데이트 전 자동 스냅샷 포함)
  3. 변경관리: 커널/부트 설정 변경은 배포 파이프라인으로 기록
  4. 운영 체크리스트: 디스크 사용량뿐 아니라 인오드/로그 폭증도 감시

운영 중 장애 대응을 하다 보면 VM 단의 문제뿐 아니라, 컨테이너/클러스터에서도 “관측(로그/진단) 부재”가 장애 시간을 늘리는 공통 패턴이 있습니다. 원인 파악을 빠르게 하는 관점에서는 아래 글의 접근(원인 분해/재현/체크리스트화)도 참고가 됩니다.

9) 정리: 가장 현실적인 복구 시나리오

  • 1단계(5분): Boot diagnostics로 멈춘 단계/오류 문자열 확보
  • 2단계(10분): 재부팅, 호스트 의심 시 redeploy
  • 3단계(30~90분): 스냅샷 → 복제 디스크 → 리커버리 VM에 attach → fstab/fsck/용량/부트로더 복구
  • 4단계: 수리 디스크로 OS 디스크 교체 또는 새 VM로 마이그레이션

Boot diagnostics는 “켜두면 언젠가 반드시 값어치를 하는” 기능입니다. 특히 부팅 실패는 SSH/RDP가 막히는 순간부터 정보가 급격히 사라지므로, 스크린샷과 시리얼 로그만으로도 방향을 잡을 수 있게 준비하는 것이 복구 시간을 결정합니다.

Discuss on Twitter • View on GitHub