beautifulsoups.dev
Published on

Azure VM 부팅 실패, Boot Diagnostics로 원인추적

Authors

운영 중인 Azure VM이 갑자기 부팅 실패 상태에 빠지면 가장 곤란한 점은 SSH/RDP가 안 열리면서 관측 수단이 급격히 줄어든다는 것입니다. 이때 가장 먼저 확인해야 할 기능이 Boot Diagnostics(부팅 진단) 입니다. 부팅 과정의 스크린샷과 시리얼 콘솔 로그를 통해, 네트워크 이전 단계(커널/부트로더/드라이버/파일시스템)에서 무슨 일이 벌어졌는지 단서를 얻을 수 있습니다.

이 글에서는 Boot Diagnostics로 얻을 수 있는 증거(스크린샷, 시리얼 로그)를 기반으로 부팅 실패 원인을 분류하고, Azure에서 현실적으로 자주 쓰는 복구 루트(Serial Console, OS 디스크 스왑/오프라인 수리, 확장/에이전트 문제 제거) 를 단계별로 정리합니다.

네트워크 레벨에서 접속이 끊기는 이슈를 함께 점검해야 한다면, 부팅 자체는 정상인데 SSH만 안 되는 케이스도 많습니다. 그 경우는 리눅스 SSH 접속 끊김·Timeout 원인 10가지도 같이 참고하면 진단 속도가 빨라집니다.

Boot Diagnostics란 무엇을 남기나

Boot Diagnostics는 VM이 부팅되는 동안 Azure 호스트가 수집하는 진단 데이터입니다. 핵심은 두 가지입니다.

  • Boot screenshot: 부팅 화면 캡처(부트로더/커널 패닉/윈도우 복구 화면 등)
  • Serial console log: 시리얼 포트로 출력되는 텍스트 로그(커널 로그, systemd 메시지, Windows 부팅 단계 메시지 일부)

이 데이터는 보통 Storage Account(관리형 또는 사용자 지정)에 저장됩니다. VM이 부팅을 못 해도 Azure 호스트 레벨에서 수집되기 때문에, 게스트 OS에 에이전트가 죽어 있어도 얻을 수 있는 경우가 많습니다.

1단계: Boot Diagnostics 활성화 및 확인 절차

포털에서 확인

  1. Azure Portal에서 대상 VM 선택
  2. Boot diagnostics 메뉴로 이동
  3. Screenshot과 Serial log를 확인

여기서 중요한 포인트는 “로그가 비어 있다” 자체도 단서라는 점입니다.

  • 스크린샷이 아예 갱신되지 않음: 호스트/하이퍼바이저 단계에서 멈췄거나, 부팅이 매우 초기에 실패
  • 스크린샷은 있는데 시리얼 로그가 거의 없음: 시리얼 콘솔 출력이 비활성화되었거나(리눅스 커널 파라미터/GRUB 설정), Windows에서 해당 단계 로그가 제한

Azure CLI로 활성화(예시)

아래 예시는 Boot Diagnostics를 켜는 대표적인 방식입니다. 환경에 따라 Storage Account 지정이 필요할 수 있습니다.

# 리소스 그룹과 VM 이름
RG="my-rg"
VM="myvm01"

# Boot diagnostics 활성화(관리형 스토리지 사용이 가능한 구독/정책이면 자동 구성)
az vm boot-diagnostics enable -g "$RG" -n "$VM"

# 상태 확인
az vm boot-diagnostics get-boot-log -g "$RG" -n "$VM" --output tsv

주의: get-boot-log는 텍스트 로그만 가져옵니다. 스크린샷은 포털에서 보는 편이 빠른 경우가 많습니다.

2단계: 스크린샷으로 “부팅이 멈춘 층”부터 분류

부팅 실패는 원인보다 먼저 어느 레이어에서 멈췄는지를 나누는 게 효율적입니다.

A. BIOS/UEFI 또는 부트로더 단계

대표적인 화면/메시지 패턴

  • No bootable device
  • Boot failed 또는 부팅 디바이스를 못 찾는 메시지
  • GRUB 프롬프트로 떨어짐

가능성이 큰 원인

  • OS 디스크 손상/분리, 잘못된 OS 디스크 연결
  • 이미지/세대(Generation) 불일치(UEFI/BIOS)
  • 부트 파티션/부트로더 손상

우선 조치

  • 디스크가 올바르게 연결되어 있는지(특히 OS Disk) 확인
  • 최근에 디스크 스왑, 스냅샷 복원, 암호화 설정 변경이 있었는지 확인
  • 리눅스라면 오프라인으로 GRUB/부트 파티션 복구가 필요할 수 있음(아래 “오프라인 수리” 참고)

B. 커널 로딩/초기화 단계(리눅스)

대표 패턴

  • Kernel panic - not syncing
  • VFS: Unable to mount root fs
  • dracut-initqueue timeout
  • 특정 드라이버 로딩에서 멈춤(NVMe/SCSI/파일시스템 모듈)

가능성이 큰 원인

  • /etc/fstab에 잘못된 UUID/디바이스가 등록되어 부팅 중 마운트 실패
  • initramfs 손상 또는 커널 업데이트 후 부트 엔트리 불일치
  • 파일시스템 손상(XFS/EXT4)

우선 조치

  • 시리얼 로그에서 fstab 관련 메시지, root 디바이스 식별 실패 메시지를 찾음
  • 최근 커널 업데이트/패키지 업데이트 직후인지 확인
  • 오프라인로 디스크를 다른 VM에 붙여 fstab 수정, fsck 또는 XFS 복구 수행

C. systemd 단계에서 멈춤(리눅스)

대표 패턴

  • A start job is running for ...
  • 특정 서비스에서 타임아웃 반복

가능성이 큰 원인

  • 의존 서비스(스토리지/네트워크/마운트) 실패로 부팅 지연 또는 emergency mode
  • 클라우드 초기화(cloud-init) 실패로 부팅이 지연

우선 조치

  • 시리얼 로그에서 타임아웃 대상 유닛 이름 확인
  • cloud-init 로그(가능하면) 또는 오프라인에서 /var/log/cloud-init.log 확인
  • 임시로 해당 유닛을 마스킹하거나, fstab에서 nofail 옵션으로 부팅 우회 후 원인 제거

D. Windows 로고 이후 자동 복구/BSOD

대표 패턴

  • Preparing Automatic Repair
  • INACCESSIBLE_BOOT_DEVICE
  • 업데이트 적용 후 재부팅 루프

가능성이 큰 원인

  • Windows Update/드라이버 업데이트로 부팅 불가
  • 부팅 디바이스 드라이버 문제
  • 시스템 파일 손상

우선 조치

  • Serial Console 또는 복구 환경 진입 후 bcdedit, sfc, dism 계열로 복구(오프라인 수리 포함)
  • 최근 확장(Extension) 설치/업데이트 여부 확인

3단계: Serial Console로 “로그인 없이” 응급 조치

Boot Diagnostics로 원인을 좁혔다면, 다음은 Serial Console(시리얼 콘솔) 로 직접 조치가 가능한지 확인합니다.

  • 리눅스: GRUB/커널 파라미터 조정, emergency shell, systemd target 변경
  • Windows: SAC(Special Administration Console) 기반 제한적 조치

다만 Serial Console은 사전 조건이 있습니다.

  • 부팅 전에 기능이 활성화되어 있어야 하거나(정책/설정)
  • OS에서 시리얼 콘솔 접근이 가능해야 함

Serial Console이 된다면, 리눅스에서 자주 쓰는 우회는 다음입니다.

  • fstab 문제로 멈출 때: root shell로 들어가 문제 마운트 라인을 주석 처리
  • 특정 서비스에서 멈출 때: systemctl mask로 임시 차단

예: 부팅 중 특정 마운트가 문제라면(개념 예시)

# emergency shell에서 fstab 수정
sudo vi /etc/fstab

# 수정 후
sudo systemctl daemon-reload
sudo reboot

4단계: 오프라인 수리(가장 확실한 복구 루트)

Serial Console이 안 되거나, 파일시스템/부트로더 손상이 의심되면 OS 디스크를 다른 “수리용 VM”에 붙여서 고치는 방식이 가장 성공률이 높습니다.

절차 개요

  1. 문제 VM을 중지(Stop)
  2. OS 디스크 스냅샷 생성(원본 보존)
  3. 수리용 VM 준비(동일 OS 계열이면 편함)
  4. 문제 OS 디스크를 수리용 VM에 데이터 디스크로 연결
  5. 마운트 후 설정/부트로더/파일시스템 수정
  6. 원래 VM에 디스크를 다시 연결하고 부팅 테스트

리눅스: fstab/UUID 문제 점검 예시

수리용 VM에서 디스크를 붙인 뒤, 파티션을 확인하고 마운트합니다.

# 디스크/파티션 확인
lsblk -f

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

# fstab 확인
sudo cat /mnt/rescue/etc/fstab

# UUID 확인
sudo blkid

자주 터지는 케이스는 /etc/fstab에 존재하지 않는 UUID가 박혀 있어 부팅이 멈추는 경우입니다. 이때는 올바른 UUID로 바꾸거나, 임시로 해당 라인에 nofail을 주거나 주석 처리해서 부팅을 먼저 살린 뒤 원인을 제거합니다.

리눅스: 파일시스템 점검 예시

EXT4라면 fsck, XFS라면 xfs_repair가 일반적입니다.

# EXT4 예시(마운트 해제 상태에서 수행)
sudo umount /mnt/rescue || true
sudo fsck -f -y /dev/sdc2

# XFS 예시(마운트 해제 상태에서 수행)
sudo xfs_repair /dev/sdc2

주의: 파일시스템 복구는 데이터 손상 위험이 있으니, 스냅샷을 먼저 떠두는 것이 안전합니다.

Windows: 오프라인 복구 개요

Windows는 오프라인에서 다음 조치를 고려합니다.

  • BCD 복구(부팅 구성)
  • 시스템 파일 검사/복구
  • 최근 업데이트 롤백

수리용 VM에 디스크를 붙이고, Windows PE 또는 복구 환경에서 bcdboot, sfc, dism 계열을 사용합니다(환경마다 경로/드라이브 문자가 달라질 수 있음).

5단계: Azure 확장(Extension)과 에이전트가 부팅을 망치는 경우

의외로 VM 부팅 실패가 아니라 “부팅은 되는데 에이전트/확장이 부팅 시퀀스를 망가뜨려” 장애처럼 보이는 경우도 있습니다.

  • Custom Script Extension이 부팅 시 실행되며 무한 대기
  • 보안 에이전트/모니터링 에이전트가 커널 모듈/드라이버 충돌
  • cloud-init이 특정 메타데이터/네트워크 조건을 기다리며 타임아웃

Boot Diagnostics에서 systemd가 특정 유닛에서 멈춘 흔적이 있고, 최근 확장 배포가 있었다면 확장 제거/롤백을 검토합니다.

6단계: “부팅 실패”와 “부팅은 됐는데 접속 실패”를 구분

현장에서는 다음 두 케이스가 자주 섞입니다.

  • 진짜 부팅 실패: 커널 패닉, 파일시스템 마운트 실패, 자동 복구 루프
  • 부팅 성공 + 접속 실패: NSG/라우팅/DNS/SSH 설정/키 손상/방화벽 등

Boot Diagnostics 스크린샷이 로그인 프롬프트까지 도달했거나, 시리얼 로그가 정상적으로 multi-user 단계까지 진행된 흔적이 있다면 “부팅 자체”는 성공했을 가능성이 큽니다. 이때는 네트워크/인증/방화벽 측면 진단으로 전환하는 게 빠릅니다.

이런 식의 장애는 원인 추적 방법론이 중요합니다. 네트워크나 인증처럼 관측 지점이 많은 문제는, 애플리케이션 장애에서 데드락 원인 쿼리를 추적하듯이(증거를 쌓고 범위를 줄이는 방식) 접근해야 합니다. 참고로 원인 추적 관점은 MySQL InnoDB Deadlock 원인 쿼리 추적·해결 가이드처럼 “증거 기반으로 범위를 축소”하는 글들도 도움이 됩니다.

실전 체크리스트: Boot Diagnostics로 10분 안에 좁히기

아래 순서대로 보면, 불필요한 시도를 줄일 수 있습니다.

  1. Boot Diagnostics 스크린샷에서 멈춘 구간 확인(부트로더/커널/systemd/윈도우 복구)
  2. Serial log에서 마지막 100줄을 기준으로 키워드 탐색
    • 리눅스: panic, VFS, dracut, fstab, timeout, emergency
    • Windows: INACCESSIBLE_BOOT_DEVICE, Automatic Repair
  3. 최근 변경 이력 확인
    • 커널/드라이버 업데이트
    • 디스크/암호화/스냅샷 복원
    • VM Extension 배포
  4. Serial Console 가능 여부 확인(가능하면 즉시 응급 조치)
  5. 불가능하면 오프라인 수리로 전환
    • 스냅샷 생성
    • 수리용 VM에 OS 디스크 연결
    • fstab/부트로더/파일시스템/업데이트 롤백 수행

마무리: Boot Diagnostics는 “첫 증거”를 확보하는 도구

Azure VM 부팅 실패 대응에서 Boot Diagnostics의 가치는 단순히 로그를 보는 게 아니라, 원인 추적의 출발점(증거 확보) 이 된다는 점입니다. 스크린샷으로 레이어를 분류하고, 시리얼 로그로 마지막 정상 지점을 찾으면, 그 다음 선택지는 명확해집니다.

  • 시리얼 콘솔로 즉시 복구할지
  • 오프라인 수리로 안전하게 고칠지
  • 부팅은 정상이라면 네트워크/접속 문제로 전환할지

이 흐름만 잡아도 “재부팅 반복” 같은 위험한 시도를 줄이고, 장애 시간을 크게 단축할 수 있습니다.

Discuss on Twitter • View on GitHub