beautifulsoups.dev
Published on

Azure VM 부팅 실패? Boot Diagnostics로 5분 진단

Authors

서버가 죽었을 때 제일 답답한 순간은 SSH나 RDP가 아예 안 붙는 상황입니다. 이때 네트워크(NSG, UDR, Bastion)부터 의심하고 시간을 쓰기 쉽지만, VM이 커널 단계에서 못 올라오거나 부트로더에서 멈춘 케이스라면 네트워크를 아무리 만져도 해결되지 않습니다.

Azure에서 이런 상황을 가장 빠르게 분류하는 도구가 Boot Diagnostics입니다. 부팅 중 화면 스크린샷과 시리얼 콘솔 로그를 통해, “VM이 실제로 어디에서 멈췄는지”를 1차로 확정할 수 있습니다.

이 글은 Boot Diagnostics를 기준으로 5분 안에 부팅 실패를 분류하고 다음 조치를 결정하는 방법에 집중합니다.

네트워크 레벨에서 접속이 끊기는 문제(예: NSG, UDR, Bastion) 진단은 별도의 글로 정리했습니다: Azure VM SSH 접속 끊김 - NSG·UDR·Bastion 진단법

0. Boot Diagnostics가 뭘 주는가

Boot Diagnostics를 켜면 보통 다음 두 가지가 핵심입니다.

  • Screenshot: 부팅 화면 캡처. 부트로더, 커널 패닉, initramfs, 로그인 프롬프트 등 “어디까지 왔는지”가 한 방에 보입니다.
  • Serial console log: 커널 메시지, 클라우드-이닛, 디스크 마운트 실패, 파일시스템 오류, 드라이버 로드 실패 등이 텍스트로 남습니다.

여기서 중요한 포인트는, 이 데이터가 VM 내부 에이전트나 네트워크 접속 없이도 수집되는 경우가 많다는 점입니다. 즉, 접속이 불가능한 상황에서 사실상 유일한 단서가 됩니다.

1. 5분 진단 플로우(요약)

아래 순서대로 보면 대개 5분 내에 “원인 범주”가 정리됩니다.

  1. Azure Portal에서 해당 VM의 Boot diagnostics 열기
  2. Screenshot 먼저 확인
  3. 이어서 Serial log에서 마지막 에러 라인 확인
  4. 증상을 아래 4가지 범주로 분류
  • A. 부트로더 단계에서 멈춤(GRUB, No bootable device)
  • B. 커널 패닉/드라이버 문제(Kernel panic, VFS, initramfs)
  • C. 디스크/파일시스템 마운트 실패(fsck, EXT4-fs error, XFS)
  • D. OS는 올라왔는데 로그인/서비스에서 멈춤(cloud-init, systemd hang)

분류가 되면 조치도 거의 고정됩니다. 예를 들어 A는 디스크/부트 구성이 깨졌을 확률이 높고, C는 파일시스템 복구가 최우선입니다.

2. Boot Diagnostics 활성화 및 확인 위치

Portal에서 켜기

  • VM 리소스 진입
  • Boot diagnostics 메뉴
  • Enable 또는 Storage 계정 지정

이미 켜져 있다면 가장 좋고, 꺼져 있어도 지금 켜면 이후 부팅부터는 자료가 쌓입니다.

Azure CLI로 상태 확인

az vm boot-diagnostics get-boot-log \
  --resource-group my-rg \
  --name my-vm

환경에 따라 스토리지 권한이 필요할 수 있습니다. Portal에서 보는 편이 빠른 경우가 많습니다.

3. Screenshot으로 1분 컷 분류하기

Screenshot은 “이 VM이 부팅을 시작했는지, 어디까지 갔는지”를 알려줍니다.

3.1 No bootable device 또는 디스크를 못 찾는 화면

가능성이 큰 원인:

  • OS 디스크가 분리됨/손상됨
  • 부팅 순서가 꼬임(특히 커스텀 이미지, 마이그레이션, Generation 변경 시)
  • 디스크 타입 변경 과정에서 설정 불일치

즉시 액션:

  • OS 디스크가 VM에 제대로 연결되어 있는지 확인
  • 최근에 디스크 교체/스냅샷 복원/이미지 재배포를 했는지 변경 이력 확인

3.2 GRUB 프롬프트 또는 부트로더에서 멈춤

가능성이 큰 원인:

  • 부트로더 설정 손상
  • 커널 업데이트 중단, /boot 파티션 문제

즉시 액션:

  • Serial log에서 grub 관련 메시지 확인
  • 복구는 보통 “OS 디스크를 다른 복구 VM에 붙여서” 수리하는 방식이 빠릅니다(뒤에서 설명).

3.3 커널 패닉 화면

키워드 예:

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

가능성이 큰 원인:

  • 커널/드라이버 불일치(업데이트 직후 자주 발생)
  • 루트 디스크 UUID 변경, fstab 불일치

즉시 액션:

  • Serial log에서 마지막 20줄을 보고 VFS, initramfs, dracut 같은 키워드를 찾습니다.

3.4 로그인 프롬프트까지 왔는데 접속이 안 됨

Screenshot에 로그인 프롬프트가 보이면 OS는 대체로 올라왔습니다. 이때는 부팅 실패가 아니라 네트워크/인증/서비스 문제일 수 있습니다.

  • 네트워크면 위에서 링크한 NSG/UDR/Bastion 글로 넘어가세요.
  • Linux라면 sshd가 죽었거나 방화벽이 막았을 가능성도 있습니다.

4. Serial log에서 “마지막 에러 라인” 찾기

Serial log는 길기 때문에 전략이 필요합니다.

  • 스크롤을 끝까지 내려서 가장 마지막에 찍힌 에러를 먼저 봅니다.
  • 그 주변 30줄만 읽어도 원인 범주가 보이는 경우가 많습니다.

아래는 자주 만나는 패턴과 의미입니다.

4.1 VFS: Unable to mount root fs (루트 마운트 실패)

의미:

  • 커널이 루트 파일시스템을 못 붙였습니다.

원인 후보:

  • 디스크 장치 이름 변경
  • fstab의 UUID 불일치
  • initramfs가 필요한 드라이버를 포함하지 않음

다음 액션:

  • 복구 VM에 OS 디스크를 붙여 fstab와 blkid를 비교
  • 최근 커널 업데이트가 있었다면 롤백 고려

4.2 EXT4-fs error, XFS (sdaX): log mount/recovery failed

의미:

  • 파일시스템이 손상되었거나 저널 복구가 실패했습니다.

다음 액션:

  • OS 디스크를 분리해 복구 VM에 붙이고 fsck 또는 xfs_repair 수행
  • 가능하면 먼저 스냅샷을 떠서 원본 보존

4.3 cloud-init에서 멈춤

키워드 예:

  • cloud-init stage에서 특정 모듈이 타임아웃
  • Waiting for network to be configured

의미:

  • OS는 올라오지만 초기화 단계에서 블로킹.

원인 후보:

  • 잘못된 cloud-init user data
  • 네트워크 관련 설정 꼬임

다음 액션:

  • Serial log에서 cloud-init이 어떤 단계에서 멈추는지 확인
  • user data 또는 커스텀 데이터 변경 이력 확인

4.4 systemd 서비스 hang

키워드 예:

  • A start job is running for ... (1min 30s / no limit)

의미:

  • 특정 마운트나 서비스가 부팅 경로를 막고 있습니다.

다음 액션:

  • 해당 유닛 이름 확인 후 복구 VM에서 설정 파일 수정
  • 예: fstab에 존재하지 않는 디스크를 마운트하도록 되어 있으면 부팅이 지연/실패할 수 있습니다.

5. “복구 VM에 OS 디스크 붙이기”로 해결하는 전형 패턴

부팅 로그에서 디스크/파일시스템/부트 설정 문제로 보이면, 가장 재현성 높은 방식이 OS 디스크를 다른 VM에 데이터 디스크로 연결해 오프라인 수리하는 것입니다.

5.1 안전한 절차(권장)

  1. 문제 VM 중지(Stop)
  2. OS 디스크 스냅샷 생성
  3. OS 디스크를 분리(Detach)
  4. 별도의 복구용 VM에 데이터 디스크로 연결(Attach)
  5. 복구 VM에서 마운트 후 수리
  6. 원래 VM에 다시 연결 후 부팅

5.2 복구 VM에서 리눅스 디스크 마운트 예시

# 디스크 확인
lsblk

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

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

# UUID 확인
sudo blkid

fstab의 UUID가 실제와 다르면 수정 후 재부팅하면 해결되는 경우가 많습니다.

5.3 파일시스템 점검 예시

EXT4라면:

sudo umount /mnt/rescue || true
sudo fsck -f -y /dev/sdc1

XFS라면(마운트 해제 필요):

sudo umount /dev/sdc1 || true
sudo xfs_repair /dev/sdc1

주의:

  • 수리 전에 스냅샷을 떠두면 롤백이 가능합니다.
  • fsck나 xfs_repair는 상황에 따라 데이터 손실 가능성이 있으니, 운영 환경이라면 변경 승인 프로세스를 함께 가져가세요.

6. 부팅 실패를 자주 만드는 변경 Top 6

부팅 실패는 “갑자기”처럼 보이지만, 대부분 직전 변경이 트리거입니다.

  1. 커널 업데이트 후 재부팅
  2. fstab 수정(특히 존재하지 않는 디스크/UUID)
  3. 디스크 확장/파티션 변경 중 중단
  4. 에이전트/보안 제품 설치로 부팅 경로 오염
  5. cloud-init 커스텀 데이터 변경
  6. 이미지 캡처/복원 과정에서 Generation, Secure Boot, 드라이버 불일치

Boot Diagnostics를 보면 이 중 어디에 가까운지 빠르게 감이 잡힙니다.

7. 운영에서의 베스트 프랙티스

7.1 Boot Diagnostics는 기본값으로 켜두기

장애가 난 뒤 켜면 “장애 당시” 로그가 없는 경우가 있습니다. VM 템플릿(Bicep/Terraform)이나 정책으로 항상 켜두는 편이 좋습니다.

7.2 스냅샷과 변경 이력을 같이 본다

부팅 실패는 로그만으로 100퍼센트 확정이 어려운 경우가 있습니다. 그럴수록 “직전 변경”이 결정적입니다.

  • 커널 업데이트 배포 시각
  • 디스크 작업 이력
  • cloud-init/user data 변경

이런 이력을 같이 보면 해결 속도가 확 올라갑니다.

7.3 진단 순서 고정하기

현장에서 시간을 잡아먹는 건 기술 난이도보다 “순서가 흔들리는 것”입니다.

  • Screenshot으로 단계 확정
  • Serial log로 마지막 에러 확정
  • 디스크/부트 문제면 오프라인 수리
  • OS 기동 완료면 네트워크 진단으로 전환

이 루틴만 지켜도 평균 복구 시간이 줄어듭니다.

8. 자주 묻는 질문

Q1. Screenshot이 빈 화면인데요?

  • VM이 실제로 부팅 프로세스를 시작하지 못했거나, 플랫폼 레벨 이슈일 수 있습니다.
  • 이 경우 Activity log에서 실패 이벤트가 있는지, VM 상태가 Starting에서 멈추는지 확인하세요.

Q2. Serial log가 거의 없어요

  • Boot Diagnostics가 장애 이전에 꺼져 있었거나
  • OS가 시리얼로 로그를 출력하지 않는 구성일 수 있습니다.

그래도 Screenshot만으로도 부트로더/커널 패닉 정도는 분류되는 경우가 많습니다.

마무리: 5분 안에 “원인 범주”를 먼저 잡자

Azure VM 부팅 실패는 원인 자체보다도 “접속이 안 돼서 아무것도 못 한다”는 공포가 문제를 크게 만듭니다. Boot Diagnostics는 그 공포를 줄여주는 첫 단서입니다.

  • Screenshot으로 어디에서 멈췄는지 확정
  • Serial log로 마지막 에러 라인 확인
  • 디스크/부트 문제면 오프라인 수리로 직진
  • OS가 올라온 상태면 네트워크/서비스로 전환

이렇게만 해도 부팅 장애의 절반 이상은 불필요한 우회 없이 바로 해결 경로로 들어갈 수 있습니다.

Discuss on Twitter • View on GitHub