Azure VM 부팅 실패, Boot Diagnostics로 10분 진단

서버가 갑자기 죽었는데 포털에서 Running처럼 보이거나, 반대로 Starting에서 끝없이 멈춘 상태를 경험해보면 알겠지만, “부팅 실패”는 원인 범위가 넓습니다. 네트워크 문제처럼 보이지만 실제로는 커널 패닉일 수 있고, 디스크 문제처럼 보이지만 initramfs나 부트로더 설정이 깨진 경우도 흔합니다.

이 글은 Azure VM이 부팅되지 않을 때, Boot Diagnostics(부트 진단) 만으로 10분 안에 원인을 크게 5~6개 범주로 좁히고 다음 액션(복구/롤백/재배포)을 결정하는 방법을 다룹니다. 운영 환경에서 “일단 재시작”을 반복하기 전에, 최소한의 증거를 확보하고 정확한 복구 경로로 들어가는 것이 목표입니다.

0) 10분 진단을 위한 전제: Boot Diagnostics 활성화 확인

Azure의 Boot Diagnostics는 기본적으로 스크린샷 + 시리얼 콘솔 로그를 저장합니다. VM이 네트워크로 붙기 전 단계(커널/부트로더/init)에서 멈추는 경우에도 단서를 주기 때문에, 부팅 실패 트러블슈팅의 출발점입니다.

• Azure Portal: VM → Help 또는 Support + troubleshooting → Boot diagnostics
• 저장 위치: Managed storage(권장) 또는 Storage Account

> 팁: Boot Diagnostics가 꺼져 있으면 “장애 이후에 켜도” 과거 로그는 없습니다. 운영 VM은 기본적으로 켜두는 편이 좋습니다.

1) 10분 타임라인: 무엇을 어떤 순서로 볼 것인가

다음 순서대로 보면, 대체로 10분 안에 “어디에서 멈췄는지”를 특정할 수 있습니다.

1. 부트 스크린샷: BIOS/UEFI → 부트로더 → 커널 로딩 → 로그인 프롬프트 중 어디에서 멈췄는지
2. Serial Log(시리얼 로그): 커널 패닉/파일시스템 오류/systemd 실패 여부
3. VM 상태 + 최근 변경: Resize, OS 업데이트, 커널 업데이트, 디스크 확장, cloud-init 변경 등
4. (필요시) 부트 진단 기반의 다음 액션: 재시작/롤백/복구 VM/디스크 스왑

아래부터는 “스크린샷/시리얼 로그에 어떤 문구가 보이면 무엇을 의심해야 하는지”를 패턴별로 정리합니다.

2) 스크린샷으로 1차 분류: 멈춘 지점이 곧 원인 범주

2.1 BIOS/UEFI 화면에서 멈춤

특징:

• 화면에 제조사 로고/UEFI 설정 단계처럼 보이는 화면에서 정지

의심:

• VM 자체보다는 플랫폼/호스트 이슈, 혹은 부팅 디스크 인식 실패

다음 액션:

• VM Redeploy(호스트 변경) 고려
• 디스크가 제대로 연결되어 있는지(데이터 디스크/OS 디스크 교체 직후) 확인

2.2 부트로더(Grub) 단계에서 멈춤

특징:

• GNU GRUB 메뉴 또는 grub rescue>

의심:

• 부트로더 손상, 파티션 UUID 변경, /boot 영역 문제

다음 액션:

• 복구 VM에 OS 디스크를 attach 후 grub 복구(리눅스)

2.3 커널 로딩 후 “검은 화면” 또는 커널 패닉

특징:

• 커널 메시지가 잠깐 나오다 멈추거나 Kernel panic이 보임

의심:

• 커널/드라이버/초기 램디스크(initramfs) 문제
• 루트 파일시스템 마운트 실패

다음 액션:

• 시리얼 로그에서 VFS: Unable to mount root fs 같은 문구 확인

2.4 systemd 단계에서 멈춤(서비스 실패 루프)

특징:

• Reached target... 이후 특정 서비스에서 멈추거나 재시작 반복

의심:

• systemd 유닛 실패, 의존성 꼬임, 설정 오류

관련해서 systemd 재시작 루프 형태로 보일 때는 아래 글의 패턴도 같이 참고하면 진단 속도가 빨라집니다: systemd 재시작 루프(StartLimitHit) 해결법

3) Serial Log에서 바로 결론 나는 대표 패턴 8가지

Boot Diagnostics의 Serial Log는 “부팅이 어디까지 진행됐는지”를 가장 정확히 보여줍니다. 아래 키워드를 찾으면 대체로 원인이 좁혀집니다.

3.1 VFS: Unable to mount root fs / cannot mount /dev/...

의미:

• 루트 디스크를 마운트하지 못함

원인 후보:

• 디스크/파티션 UUID 변경
• fstab 오타
• initramfs에 필요한 드라이버 누락

다음 액션:

• 복구 VM에 OS 디스크 attach → /etc/fstab 점검, initramfs 재생성

3.2 fsck 오류 / EXT4/XFS corruption

의미:

• 파일시스템 손상으로 부팅 중단

다음 액션:

• 복구 VM에서 오프라인 fsck 수행
• 최근 강제 종료/디스크 가득 참(0 byte 남음) 여부 확인

3.3 No space left on device (특히 /var, /)

의미:

• 디스크 풀로 인해 서비스 시작 실패 → 부팅이 사실상 멈춘 것처럼 보임

다음 액션:

• 복구 VM에서 로그/캐시 정리
• OS 디스크 확장 후 파티션/파일시스템 리사이즈

3.4 cloud-init에서 멈춤

의미:

• 초기화 스크립트가 네트워크/메타데이터/패키지 설치에서 대기

다음 액션:

• cloud-init 설정/스크립트의 외부 의존성 제거
• 타임아웃 설정

3.5 A start job is running for ... 장시간 대기

의미:

• systemd 의존 대상(마운트/네트워크/디스크)이 충족되지 않음

다음 액션:

• 어떤 job인지 확인 → 해당 마운트/서비스 비활성화 또는 타임아웃 조정

3.6 Failed to start ... 반복 / StartLimitHit

의미:

• 특정 서비스가 연쇄 실패하며 부팅 진행을 막음

다음 액션:

• 문제 서비스 비활성화(복구 환경에서) 후 부팅
• 위에 링크한 StartLimitHit 패턴 참고

3.7 Windows: INACCESSIBLE_BOOT_DEVICE

의미:

• 부팅 디바이스 접근 실패(드라이버/스토리지 컨트롤러/업데이트 영향)

다음 액션:

• 최근 Windows Update/드라이버 변경 확인
• 복구 모드에서 부팅 구성/드라이버 롤백

3.8 Windows: Boot configuration data file is missing

의미:

• BCD 손상

다음 액션:

• 복구 환경에서 bcdboot/bootrec 계열로 복구

4) “진단 → 조치”를 빠르게 잇는 운영 체크리스트

10분 안에 결론을 내려야 한다면, 아래 질문에 예/아니오로 답하면서 액션을 결정합니다.

1. 스크린샷이 BIOS/UEFI에서 멈추는가?

• 예: Redeploy(호스트 변경) 우선 고려

2. 부트로더(Grub/BCD) 단계에서 멈추는가?

• 예: OS 디스크를 복구 VM에 붙여 부트로더 복구

3. 커널 패닉/루트 마운트 실패가 보이는가?

• 예: fstab/UUID/initramfs/드라이버 문제로 좁혀서 오프라인 수정

4. systemd/job 대기/StartLimitHit로 보이는가?

• 예: 해당 서비스/마운트 단위로 원인 역추적 후 비활성화/설정 수정

5. 디스크 용량 100% 가능성이 있는가?

• 예: 복구 VM에서 로그 정리 후 디스크 확장

이 과정은 AWS/EKS 쪽 장애에서도 “증상을 범주화해 원인 후보를 줄이는 방식”이 동일하게 적용됩니다. 예를 들어 인증서 문제처럼 보이는 장애도 로그의 특정 키워드로 빠르게 분류합니다: EKS Pod에서 x509 unknown authority 오류 해결

5) 복구의 정석: OS 디스크를 복구 VM에 Attach해서 고친다

부팅이 안 되면 VM 내부에 접속할 수 없으니, 가장 흔한 복구 방법은 다음입니다.

1. 문제 VM Stop(Deallocate)
2. OS Disk를 분리(또는 스냅샷 생성)
3. 별도의 Recovery VM 생성
4. Recovery VM에 문제 OS Disk를 데이터 디스크로 Attach
5. 마운트 후 설정/파일 수정
6. 원래 VM에 OS Disk 재연결 후 부팅

이 접근은 “부팅 자체가 안 되는 상태”에서 가장 확실하고, 변경 사항을 통제하기 쉽습니다.

6) (Linux) 복구 VM에서 자주 쓰는 명령 템플릿

아래 예시는 Ubuntu 계열을 가정합니다. 디스크/파티션 이름은 환경마다 다르니 lsblk로 확인하세요.

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

# 2) (예) 문제 OS 디스크의 루트 파티션이 /dev/sdc2 라고 가정
sudo mkdir -p /mnt/rescue
sudo mount /dev/sdc2 /mnt/rescue

# 3) 부팅 관련 파티션이 따로 있으면 같이 마운트(예: /boot)
# sudo mount /dev/sdc1 /mnt/rescue/boot

# 4) fstab 확인(오타/UUID 변경 여부)
sudo sed -n '1,200p' /mnt/rescue/etc/fstab

# 5) 디스크 용량/로그 폭주 확인
sudo df -h /mnt/rescue
sudo du -sh /mnt/rescue/var/log/* 2>/dev/null | sort -h | tail

# 6) chroot로 들어가 initramfs 재생성(필요 시)
for d in /dev /proc /sys /run; do sudo mount --bind $d /mnt/rescue$d; done
sudo chroot /mnt/rescue /bin/bash

# (chroot 내부)
update-initramfs -u
# grub 재설치가 필요하면(환경에 따라 다름)
# update-grub
exit

# 7) 마운트 해제
for d in /run /sys /proc /dev; do sudo umount /mnt/rescue$d; done
sudo umount /mnt/rescue

핵심은 “부팅 실패의 원인이 되는 파일(fstab, grub 설정, 깨진 유닛 파일, 용량 문제)을 오프라인에서 수정”하는 것입니다.

7) (Windows) BCD/부트 문제의 최소 복구 커맨드 예시

Windows는 상황에 따라 WinRE(복구 환경) 접근이 필요합니다. 아래는 대표적으로 BCD를 다시 구성할 때 자주 언급되는 흐름 예시입니다.

# WinRE/복구 콘솔에서 실행하는 예시(환경마다 드라이브 문자가 다름)
diskpart
list vol
exit

# 예: Windows 파티션이 C:, EFI 파티션이 S:로 잡혔다고 가정
bcdboot C:\Windows /s S: /f UEFI

INACCESSIBLE_BOOT_DEVICE 류는 단순 BCD 문제보다 드라이버/업데이트 영향인 경우가 많아, “최근 변경 사항”과 함께 봐야 진단이 빨라집니다.

8) 재발 방지: Boot Diagnostics만 켜서는 부족하다

부팅 실패는 “원인 파악이 늦어지는 것”이 더 큰 손실로 이어집니다. 다음을 같이 권장합니다.

• 변경 이력 관리: 커널 업데이트, 디스크 확장, fstab 변경, cloud-init 변경을 배포 단위로 추적
• 스냅샷/백업: OS 디스크 스냅샷을 정기적으로(특히 패치 전)
• 로그 보존 정책: /var/log 폭주로 부팅이 막히는 케이스 방지
• 서비스 가드레일: systemd 유닛에 무한 재시작 방지, 타임아웃 설정

운영에서 장애는 “한 번의 원인”이 아니라 “원인 + 관측 불가 + 복구 절차 미정”이 합쳐져 길어집니다. Boot Diagnostics는 관측 가능성을 가장 앞단에서 확보하는 도구이고, 이 글의 분류법은 그 관측을 10분짜리 의사결정으로 바꾸는 방법입니다.

9) 요약: 10분 안에 결론 내리는 핵심만

• 스크린샷으로 멈춘 단계(UEFI/Grub/Kernel/systemd)를 먼저 분류
• Serial Log 키워드로 원인 범주를 확정(루트 마운트, fsck, 용량, cloud-init, StartLimitHit)
• 접속이 안 되면 OS 디스크를 복구 VM에 attach해서 오프라인 수정이 정석
• “재시작 반복” 대신 증거(스크린샷/시리얼 로그) 확보 → 조치로 복구 시간을 줄인다