beautifulsoups.dev
Published on

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

Authors

서버가 갑자기 부팅되지 않으면(SSH/RDP 불가, 상태는 Running인데 접속 불가 등) 흔히 “네트워크 문제”부터 의심하지만, 실제로는 커널 패닉, 부트로더 손상, fstab/스토리지 마운트 실패, 디스크 공간 100%, Windows 부팅 BCD 손상처럼 OS 레벨 부팅 단계에서 멈춘 케이스가 많습니다. 이때 Azure에서 가장 먼저 켜야 할 스위치가 Boot Diagnostics입니다.

Boot Diagnostics는 VM의 부팅 과정에서 발생하는 **스크린샷(그래픽 콘솔 캡처)**과 **시리얼 로그(텍스트 로그)**를 저장해, 포털 접속만으로도 “어디에서 멈췄는지”를 확인하게 해줍니다. 특히 운영 환경에서 VM을 재배포하기 전에, 로그 기반으로 원인을 좁혀 최소 변경으로 복구할 수 있다는 점이 핵심입니다.

Boot Diagnostics: 무엇을, 어디까지 볼 수 있나

Boot Diagnostics는 크게 두 가지 데이터를 제공합니다.

  • Boot screenshot: 부팅 화면이 멈춘 지점을 시각적으로 확인(예: GRUB 프롬프트, initramfs emergency mode, Windows Recovery 화면 등)
  • Serial log: 커널/부트 로더/초기 서비스 로그를 텍스트로 확인(특히 Linux에서 강력)

구성 방식은 두 가지입니다.

  • Managed storage(권장): Azure가 진단용 스토리지를 관리
  • Storage account 지정: 기존 Storage Account에 진단 로그 저장(정책/감사 목적)

> 운영 팁: 장애가 났을 때 “그때 켜면 되지”라고 생각하기 쉽지만, 일부 상황에서는 부팅 직후 짧은 로그가 결정적입니다. 가능하면 평상시에도 Boot Diagnostics를 활성화해 두는 편이 안전합니다.

1단계: 포털에서 부팅 실패 지점 파악

1) Boot Diagnostics 화면에서 확인할 것

포털에서 VM → Boot diagnostics로 들어가 다음을 확인합니다.

  • 스크린샷이 GRUB에서 멈추는가?
  • initramfs 또는 dracut의 emergency shell로 떨어지는가?
  • A start job is running for ... 같은 systemd 타임아웃인가?
  • Windows라면 Automatic Repair / Inaccessible Boot Device 같은 메시지인가?

2) 시리얼 로그에서 자주 보이는 패턴(리눅스)

  • Kernel panic - not syncing: VFS: Unable to mount root fs
    • 루트 디바이스(UUID) 불일치, initramfs 문제, 디스크 인식 실패
  • Failed to mount /... 또는 Dependency failed for Local File Systems
    • /etc/fstab에 잘못된 디스크/네트워크 파일시스템(NFS 등) 등록
  • No space left on device가 부팅 초기에 반복
    • /var, /, /boot 공간 부족으로 서비스 시작 실패
  • grub rescue>
    • GRUB 설정/부트 파티션 손상

이 단계의 목적은 “복구 방법”을 고르는 것입니다. 예를 들어 fstab 문제면 디스크를 떼어내 수정하면 되고, 커널/부트로더 문제면 chroot 복구가 필요할 수 있습니다.

2단계: Serial Console로 즉시 복구(가능한 경우)

Boot Diagnostics가 켜져 있고, OS가 시리얼 콘솔을 지원하도록 설정되어 있다면 Serial Console이 가장 빠른 복구 루트입니다(포털에서 VM → Serial console).

리눅스: fstab 오류로 emergency mode 진입한 경우

Boot Diagnostics에서 emergency mode가 보이면, 시리얼 콘솔로 로그인 후 /etc/fstab를 수정해 부팅을 정상화할 수 있습니다.

# 현재 실패한 마운트 확인
systemctl --failed
journalctl -xb | tail -n 200

# fstab 점검
sudo nano /etc/fstab

# 예: 존재하지 않는 디스크 UUID로 마운트 시 부팅이 멈출 수 있음
# UUID=xxxx  /data  ext4  defaults  0 2
# -> 임시로 주석 처리하거나, nofail 옵션 추가

실무에서 자주 쓰는 완화 옵션:

  • nofail: 마운트 실패해도 부팅 진행
  • x-systemd.device-timeout=10s: 무한 대기 방지

예시:

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

수정 후 재부팅:

sudo reboot

Windows: 부팅 로더/BCD 문제는 Serial Console만으로 한계

Windows는 상황에 따라 SAC(Serial Console)로 할 수 있는 범위가 제한적입니다. 부팅 로더/BCD 손상, 디스크 드라이버 문제는 보통 **복구 VM(디스크 오프라인 수리)**가 더 확실합니다.

3단계: 복구 VM으로 디스크 오프라인 수리(가장 범용)

Serial Console이 안 열리거나, OS가 그 단계까지 못 가는 경우에는 OS 디스크를 분리해서 다른 VM에 붙여 고치는 방식이 정석입니다.

전체 절차 개요

  1. 문제 VM을 Stop (deallocate)
  2. OS Disk를 분리(또는 스냅샷 생성 후 복제)
  3. 정상 VM(복구 VM)에 OS Disk를 데이터 디스크로 Attach
  4. 복구 VM에서 마운트/수정(리눅스) 또는 offline repair(Windows)
  5. 원래 VM에 OS Disk 재부착 후 부팅

> 운영 팁: 원본 OS 디스크를 직접 만지기 전에 Snapshot을 먼저 떠두면, 복구 중 실수해도 롤백이 가능합니다.

리눅스: 복구 VM에서 마운트 후 수정(chroot)

복구 VM에서 디스크가 /dev/sdc로 붙었다고 가정합니다(환경에 따라 다름).

# 파티션 확인
lsblk
sudo blkid

# 루트 파티션 마운트(예: /dev/sdc2)
sudo mount /dev/sdc2 /mnt

# /boot가 별도 파티션이면 추가 마운트(예: /dev/sdc1)
sudo mount /dev/sdc1 /mnt/boot

# chroot를 위한 pseudo fs 마운트
for i in /dev /dev/pts /proc /sys /run; do sudo mount --bind $i /mnt$i; done

# chroot 진입
sudo chroot /mnt

여기서 할 수 있는 대표 작업:

  • /etc/fstab 수정
  • initramfs 재생성
  • GRUB 재설치
  • 커널 패키지 정리

예: Ubuntu/Debian 계열에서 initramfs/GRUB 복구

# (chroot 내부)
update-initramfs -u
update-grub

grub-install /dev/sdc

RHEL/CentOS 계열 예시:

# (chroot 내부)
dractu -f

grub2-mkconfig -o /boot/grub2/grub.cfg

작업 후 chroot 종료 및 언마운트:

exit
for i in /run /sys /proc /dev/pts /dev; do sudo umount -lf /mnt$i; done
sudo umount -lf /mnt/boot
sudo umount -lf /mnt

Windows: BCD/부팅 복구(복구 VM + Windows 도구)

Windows OS 디스크를 복구 VM에 붙인 뒤, Disk Management에서 드라이브 문자를 확인하고(예: E:), 필요 시 bcdboot, bootrec 등을 사용합니다. 다만 Azure 환경/파티션 구성(UEFI/EFI)에 따라 명령이 달라질 수 있어, “Boot Diagnostics의 스크린샷 메시지”로 어느 단계가 깨졌는지 먼저 확정하는 것이 중요합니다.

PowerShell 예시(관리자 권한):

# 예: Windows 파티션이 E:, EFI 파티션이 S:로 마운트되어 있다고 가정
bcdboot E:\Windows /s S: /f UEFI

4단계: Boot Diagnostics 로그를 운영 관점에서 활용하는 법

부팅 실패는 보통 “한 번 고치고 끝”이 아니라, 재발 방지 장치가 필요합니다. Boot Diagnostics를 단순히 장애 시에만 보는 게 아니라, 아래처럼 운영 체계에 묶어두면 효과가 큽니다.

1) 장애 분류를 빠르게 만드는 체크리스트

  • 부트로더 단계(GRUB/Windows Boot Manager)에서 멈춤 → 디스크/부트 파티션/BCD 의심
  • 커널 로딩 단계에서 멈춤 → 커널/드라이버/initramfs/루트 디바이스 의심
  • systemd 서비스 단계에서 멈춤 → fstab, 네트워크 마운트, 디스크 full, 특정 서비스 설정 의심

이 분류만으로도 “바로 복구 VM로 갈지 / Serial Console로 해결할지”가 결정됩니다.

2) 변경 작업 후 부팅 리스크 줄이기

  • /etc/fstab에 네트워크 스토리지(NFS 등) 추가 시 nofail, timeout 옵션 기본 적용
  • 디스크 공간 모니터링(특히 /boot, /var)을 알람화
  • 커널 업데이트/에이전트 업데이트 후에는 재부팅 윈도우를 잡고 검증

3) 비슷한 ‘원인 추적’ 접근이 필요한 다른 장애들

부팅 장애는 “로그가 말해주는 사실”을 기반으로 의심 범위를 좁히는 점에서, 쿠버네티스의 이미지 풀/인증서/엔드포인트 문제를 추적하는 방식과 매우 유사합니다. 예를 들어 다음 글들도 같은 문제 해결 사고방식을 공유합니다.

자주 만나는 원인별 ‘즉시 처방’ 요약

  • fstab 마운트 실패: Boot Diagnostics에서 systemd mount 실패 확인 → Serial Console 또는 복구 VM에서 /etc/fstab 수정(nofail, timeout)
  • 디스크/파티션 UUID 변경: blkid로 실제 UUID 확인 → fstab/GRUB 설정 갱신
  • GRUB 손상: 복구 VM에서 chroot 후 grub-install, update-grub(또는 grub2-mkconfig)
  • 루트 FS 마운트 불가(VFS panic): initramfs 재생성, 커널/드라이버 점검, 디스크 연결/컨트롤러 변경 여부 확인
  • Windows BCD/부팅 구성 손상: 복구 VM에서 EFI 파티션 확인 후 bcdboot로 재생성

마무리: “부팅 실패”는 관측 가능하게 만들면 절반은 끝난다

Azure VM 부팅 실패는 겉으로는 ‘접속 불가’로 동일하게 보이지만, 실제 원인은 부트로더/커널/파일시스템/서비스 단계로 갈라집니다. Boot Diagnostics의 스크린샷과 시리얼 로그만 확보하면, 추측이 아니라 근거 기반으로 단계별 복구 전략을 선택할 수 있습니다.

정리하면,

  • 평상시에 Boot Diagnostics를 켜두고
  • 장애 시에는 스크린샷/시리얼 로그로 멈춘 지점을 확정한 뒤
  • 가능하면 Serial Console로 빠르게 수정, 아니면 복구 VM으로 오프라인 수리

이 루틴을 팀의 표준 운영 절차로 만들어두면, “재배포/복구” 같은 큰 수술을 하기 전에 훨씬 작은 변경으로 서비스를 살릴 가능성이 높아집니다.

Discuss on Twitter • View on GitHub