- Published on
Azure VM 부팅 실패, Boot Diagnostics로 복구하기
- Authors
- Name
- 스타차일드
- https://x.com/ETFBITX
운영 중인 Azure VM이 갑자기 부팅에 실패하면, 가장 먼저 필요한 건 **"지금 이 VM이 어디에서 멈췄는지"**를 확인하는 것입니다. SSH나 RDP가 안 붙는 상황에서는 추측으로 재부팅만 반복하기 쉽고, 그 사이 장애 시간이 늘어납니다.
Azure에서는 이때 Boot Diagnostics가 사실상 1차 진단 도구입니다. 부팅 화면 스크린샷과 시리얼(Serial Console) 로그를 통해 커널 패닉, 부트로더 오류, 파일시스템 손상, 디스크 용량/inode 고갈, 네트워크 초기화 문제 등 다양한 원인을 빠르게 분류할 수 있습니다.
이 글에서는 Boot Diagnostics로 원인을 좁히고, 필요 시 OS 디스크를 떼어내 복구(Rescue VM 패턴)하는 흐름을 재현 가능한 체크리스트로 정리합니다.
1) Boot Diagnostics가 제공하는 것
Boot Diagnostics는 VM이 정상 로그인 단계까지 올라오지 못하더라도 다음을 제공합니다.
- 부팅 스크린샷: BIOS/UEFI 단계, GRUB, 커널 부팅 메시지, Windows 부팅 로더/복구 화면 등을 시각적으로 확인
- 시리얼 로그: Linux의 커널/
systemd로그 일부, Windows의 부팅 단계 로그(환경에 따라 제한적) - (환경에 따라) Serial Console 접속: 텍스트 콘솔에서 직접 로그인/명령 실행이 가능한 경우도 있음
중요한 포인트는, Boot Diagnostics만으로도 "네트워크 문제인지" vs "OS/디스크 문제인지"를 빠르게 나눌 수 있다는 점입니다.
2) 먼저 확인할 것: 장애 분류를 2분 안에 끝내기
2.1 Azure Portal에서 Boot Diagnostics 확인
- Azure Portal → 해당 VM
Help또는Support + troubleshooting영역에서 Boot diagnostics 선택- 스크린샷과 시리얼 로그를 확인
여기서 아래 패턴 중 무엇인지 분류합니다.
- GRUB prompt / no bootable device: 부트로더/부팅 파티션/디스크 연결 문제 가능성
- Kernel panic / VFS unable to mount root fs: 루트 파일시스템 마운트 실패,
fstab오류, 디바이스명 변경, initramfs 문제 - systemd에서 특정 서비스 무한 대기: 파일시스템 체크(
fsck) 또는 의존 서비스(디스크/네트워크) 문제 - Windows Automatic Repair / INACCESSIBLE_BOOT_DEVICE: 드라이버/스토리지 컨트롤러/부트 구성 손상
2.2 디스크 용량 및 inode 고갈도 의심하기
부팅 중 임시 파일 생성이나 로그 기록이 실패하면 systemd가 비정상 동작하거나 서비스들이 연쇄적으로 실패해 부팅이 멈춘 것처럼 보일 수 있습니다.
특히 Linux에서 **디스크 사용률 100%**뿐 아니라 inode 고갈도 흔한 원인입니다. 이 케이스는 부팅 후 SSH 접속이 안 되거나, cloud-init가 실패하는 형태로도 나타납니다.
관련해서는 아래 글의 진단 관점이 그대로 도움이 됩니다.
3) Boot Diagnostics 로그에서 자주 보이는 원인 패턴
3.1 fstab 오류로 부팅 대기
시리얼 로그에 다음과 비슷한 메시지가 보이면 fstab에 정의된 마운트가 실패해 부팅이 멈춘 상황일 수 있습니다.
Timed out waiting for device ...Dependency failed for /dataYou are in emergency mode
대응 방향:
- 최근 디스크/파티션 변경 여부 확인
- UUID가 바뀌었는지 확인
- 부팅을 막는 마운트 옵션을
nofail로 완화하는 방안 검토
3.2 커널 패닉 또는 루트 FS 마운트 실패
Kernel panic - not syncing: VFS: Unable to mount root fs
대응 방향:
- initramfs 손상/미생성 여부
- 커널 업데이트 직후라면 이전 커널로 부팅 가능한지
- 디스크 장치명 변경(예:
sdavsnvme0n1) 여부
3.3 GRUB/부트로더 단계에서 멈춤
- GRUB prompt로 떨어짐
no such partition
대응 방향:
- 부팅 파티션 손상 여부
- 부트로더 재설치 필요 가능성
3.4 Windows 부팅 복구 루프
- Automatic Repair 화면 반복
INACCESSIBLE_BOOT_DEVICE
대응 방향:
- 최근 Windows Update/드라이버 변경
- 디스크 컨트롤러/확장 기능 변경 여부
- 복구 환경에서
bcdedit/부팅 구성 점검
4) 복구 전략: "Rescue VM" 패턴으로 OS 디스크 수리
Boot Diagnostics로 원인이 OS/디스크 쪽으로 좁혀졌다면, 다음 단계는 OS 디스크를 떼어내 다른 VM에 붙여서 수리하는 방식이 가장 안전하고 재현성이 높습니다.
핵심 아이디어는 간단합니다.
- 문제가 있는 VM을 중지(Stop)
- OS 디스크를 분리(또는 스냅샷 생성 후 복제)
- 동일 리전의 "구조용 VM(Rescue VM)"에 데이터 디스크로 연결
- 마운트 후 설정/파일시스템/부트로더를 수정
- 원래 VM에 OS 디스크를 다시 연결 후 부팅
4.1 작업 전 안전장치: 스냅샷부터
운영 환경에서는 복구 작업 자체가 2차 장애를 만들 수 있습니다. 따라서 디스크 조작 전에 반드시 스냅샷을 권장합니다.
- OS Disk →
Create snapshot - 또는 Managed Disk를 복제해 복구 작업은 복제본에서 수행
5) Linux 복구 실전: 디스크 마운트 후 점검/수정
아래 예시는 Ubuntu 계열을 기준으로 합니다. Rescue VM에 문제 디스크가 /dev/sdc로 붙었다고 가정합니다.
5.1 파티션 확인 및 마운트
sudo lsblk -f
sudo fdisk -l /dev/sdc
# 예: 루트 파티션이 /dev/sdc2 라면
sudo mkdir -p /mnt/rescue
sudo mount /dev/sdc2 /mnt/rescue
부팅 파티션이 따로 있다면 함께 마운트합니다.
# 예: /boot가 /dev/sdc1
sudo mount /dev/sdc1 /mnt/rescue/boot
5.2 fstab 점검
부팅 대기의 대표 원인이 fstab 불일치입니다.
sudo nano /mnt/rescue/etc/fstab
점검 포인트:
- UUID가 실제와 일치하는지(
blkid로 확인) - 존재하지 않는 디스크/파티션을 마운트하려는 항목이 있는지
- 부팅을 막는다면 임시로
nofail,x-systemd.device-timeout=10등을 고려
UUID 확인 예시:
sudo blkid /dev/sdc1 /dev/sdc2
5.3 파일시스템 체크(fsck)
파일시스템 손상이 의심되면 fsck를 수행합니다. 마운트된 상태에서는 위험하므로 언마운트 후 진행합니다.
sudo umount /mnt/rescue
sudo fsck -fy /dev/sdc2
sudo mount /dev/sdc2 /mnt/rescue
5.4 디스크/inode 고갈 정리
부팅이 안 되는 원인이 공간 또는 inode 부족이라면, 마운트 후 불필요한 파일을 정리합니다.
sudo chroot /mnt/rescue /bin/bash
df -h
df -i
# 큰 로그/임시파일 정리 예시
rm -f /var/log/*.gz
rm -f /var/log/journal/*
apt-get clean || true
exit
inode 고갈은 작은 파일이 과도하게 쌓였을 때 발생하므로, 특정 디렉터리의 파일 개수 폭증 여부도 확인합니다.
6) Linux 부트로더 복구(필요 시)
GRUB 문제라면 chroot 환경에서 GRUB 재설치를 고려합니다. 아래는 일반적인 흐름이며, 배포판/부팅 방식(BIOS/UEFI)에 따라 달라질 수 있습니다.
# 루트 마운트 후 필수 가상 파일시스템 바인드
sudo mount --bind /dev /mnt/rescue/dev
sudo mount --bind /proc /mnt/rescue/proc
sudo mount --bind /sys /mnt/rescue/sys
sudo chroot /mnt/rescue /bin/bash
# 예시: GRUB 재설치(환경에 따라 디바이스명 주의)
update-grub
grub-install /dev/sdc
exit
주의: 실제 부팅 디스크 디바이스를 잘못 지정하면 복구가 더 어려워질 수 있습니다. 확신이 없다면 스냅샷 기반으로 반복 가능하게 진행하세요.
7) Windows 복구 방향(요약)
Windows의 경우도 Rescue VM 패턴(디스크를 다른 VM에 연결)은 유효합니다. 다만 Windows는 오프라인 상태에서 BCD/부팅 구성, 시스템 파일 무결성, 드라이버 문제 등을 다루게 됩니다.
대표 체크:
- Windows Recovery Environment에서 Startup Repair
- 오프라인
sfc/dism점검 bcdedit로 부팅 엔트리 확인
운영 환경에서는 변경 이력(최근 업데이트, 에이전트 설치, 보안 패치)과 Boot Diagnostics 화면을 함께 묶어 원인을 좁히는 것이 중요합니다.
8) 재발 방지 체크리스트
부팅 실패는 "한 번 복구"보다 "다시 안 일어나게"가 더 중요합니다.
- Boot Diagnostics를 항상 Enabled로 유지(특히 프로덕션)
- OS 디스크/데이터 디스크 변경 작업은 변경 전후로 UUID 및 마운트 전략 점검
- 디스크 사용률뿐 아니라
inode사용률도 모니터링 - 커널/에이전트 업데이트는 점진 배포 및 롤백 전략 준비
- 장애 대응 자동화를 위해 Runbook(예: 스냅샷 생성, 디스크 분리/연결 절차) 문서화
CI/CD나 IaC로 인프라 변경이 잦다면, 사소한 권한/상태 꼬임이 큰 장애로 이어질 수 있습니다. 변경 자동화 파이프라인을 운영한다면 아래 글의 "충돌/드리프트" 관점도 함께 참고할 만합니다.
9) 마무리: Boot Diagnostics는 "로그인 불가" 상황의 1차 진실
Azure VM 부팅 실패는 원인이 다양하지만, 대응 순서는 비교적 정형화할 수 있습니다.
- Boot Diagnostics로 멈춘 지점을 확인해 원인을 분류
- OS/디스크 문제라면 스냅샷으로 안전장치 확보
- Rescue VM 패턴으로 디스크를 오프라인 복구
- 부팅 성공 후 재발 방지(모니터링/변경관리)까지 마무리
이 흐름을 팀 런북으로 만들어두면, SSH/RDP가 끊긴 최악의 순간에도 "감"이 아니라 "근거"로 복구를 진행할 수 있습니다.
부록: Azure CLI로 Boot Diagnostics 활성화 예시
환경에 따라 명령/옵션이 달라질 수 있지만, 운영 자동화를 위해서는 CLI 기반으로 상태를 확인해두는 것이 유용합니다.
# VM 인스턴스 뷰 확인
az vm get-instance-view \
--resource-group my-rg \
--name myvm \
--output json
# Boot Diagnostics 설정 확인(리소스 속성 조회)
az vm show \
--resource-group my-rg \
--name myvm \
--query "diagnosticsProfile" \
--output json
CLI 출력에 대한 해석은 구독/정책/스토리지 설정에 따라 달라질 수 있으므로, 포털의 Boot Diagnostics 화면과 함께 교차 확인하는 것을 권장합니다.