beautifulsoups.dev
Published on

Azure VM 부팅 실패? Boot Diagnostics로 10분 복구

Authors

서버가 갑자기 죽은 것도 아닌데 Azure VM이 부팅 단계에서 멈추고 SSH/RDP가 안 붙는 상황은 운영에서 꽤 자주 만납니다. 특히 커널/드라이버 업데이트, fstab 변경, 디스크 공간 고갈, cloud-init 오동작, 부트로더(Grub) 손상 같은 이슈는 “네트워크는 멀쩡한데 접속만 안 되는” 형태로 나타납니다.

이때 가장 빠른 첫 액션은 재부팅을 반복하는 게 아니라, Boot Diagnostics(부팅 진단) 로 스크린샷 + 시리얼 콘솔 로그를 확인해 “지금 멈춘 지점”을 파악하는 것입니다. 원인을 좁히면 복구 옵션(Serial Console 조치, 디스크 분리 후 오프라인 수정, 복구 VM 활용 등)도 10분 안에 결정할 수 있습니다.

> SSH 자체가 안 될 때 네트워크 원인(NSG/UDR/DNS)부터 점검해야 하는 경우도 많습니다. 부팅 실패가 아니라 접속 경로 문제일 수 있으니, 필요하면 Azure VM SSH 타임아웃 10분 진단 - NSG·UDR·DNS도 함께 확인하세요.

1) “부팅 실패”와 “접속 실패”를 1분 안에 구분

먼저 Azure Portal에서 VM의 상태와 지표를 봅니다.

  • VM 상태: Running인데도 접속이 안 된다 → 네트워크/OS 레벨 둘 다 가능
  • 부팅 실패 패턴
    • Starting에서 오래 멈춤
    • 재부팅해도 동일
    • 부팅 직후 크래시/리부트 루프

가장 빠른 구분법은 Boot Diagnostics 스크린샷입니다.

  • 로그인 프롬프트까지 떴는데 접속만 안 된다 → 네트워크/SSH/RDP/방화벽 가능성 ↑
  • 커널 패닉, initramfs, fsck, grub, fstab 에러 화면 → OS 부팅 문제 확정

2) Boot Diagnostics 활성화/확인 (포털 기준)

2.1 이미 켜져 있으면 바로 로그부터

  1. Azure Portal → VM → Help 또는 Support + troubleshooting
  2. Boot diagnostics
  3. Screenshot / Serial log 확인

2.2 꺼져 있다면 즉시 켜기

Boot Diagnostics는 보통 1~2분 내로 활성화됩니다.

  • VM → Boot diagnostics → Enable
  • 저장소 옵션
    • Managed storage(권장): 진단용 스토리지를 Azure가 관리
    • Storage account 지정: 규정상 로그 저장 위치를 통제해야 할 때

> 팁: 운영 환경에서는 사전에 Boot Diagnostics를 켜 두는 편이 훨씬 유리합니다. 장애 시 “켜고 기다리는 시간”이 줄어듭니다.

3) 스크린샷/시리얼 로그에서 바로 찾는 7가지 신호

Boot Diagnostics의 핵심은 “지금 어디에서 멈췄는지”를 보여주는 것입니다. 아래 패턴은 실제로 복구 루트를 빠르게 결정해 줍니다.

3.1 파일시스템/디스크 공간 문제

  • 증상
    • No space left on device
    • EXT4-fs error, xfs_repair needed
    • 부팅 중 fsck가 멈추거나 read-only로 마운트
  • 조치 방향
    • Serial Console로 불필요 로그 삭제
    • 오프라인로 디스크 붙여서 정리/복구(xfs_repair/fsck)

3.2 /etc/fstab 오타 또는 UUID 변경

  • 증상
    • Dependency failed for /mnt/...
    • Timed out waiting for device ...
    • emergency mode 진입
  • 조치 방향
    • Serial Console에서 /etc/fstab 수정
    • 또는 OS 디스크를 다른 VM에 붙여 fstab 수정

3.3 커널 패닉 / 드라이버 문제

  • 증상
    • Kernel panic - not syncing
    • VFS: Unable to mount root fs
  • 조치 방향
    • 최근 커널 업데이트/드라이버 설치 이력 확인
    • 부트 엔트리 변경(이전 커널로 부팅) 또는 initramfs 재생성

3.4 cloud-init / userdata 스크립트가 부팅을 막음

  • 증상
    • cloud-init 단계에서 장시간 멈춤
    • 네트워크 설정/패키지 설치 단계에서 타임아웃 반복
  • 조치 방향
    • cloud-init 비활성화 또는 문제 모듈 건너뛰기
    • userdata 롤백

3.5 Grub/부트로더 손상

  • 증상
    • grub rescue>
    • no such partition
  • 조치 방향
    • 복구 VM에 디스크 연결 후 grub 재설치

3.6 Windows: 부팅 루프 / 업데이트 실패

  • 증상
    • Preparing Automatic Repair
    • Diagnosing your PC 반복
  • 조치 방향
    • Serial Console(SAC) 또는 Azure의 복구 옵션
    • 오프라인 레지스트리/드라이버 롤백 고려

3.7 “로그인 프롬프트는 뜨는데 원격 접속만 실패”

4) Serial Console로 “바로 고치는” 10분 루트 (Linux 예시)

Boot Diagnostics에서 원인을 특정했다면, 다음은 Serial Console로 즉시 수정하는 루트입니다.

> 전제: Serial Console은 VM/구독/OS 설정에 따라 제한될 수 있습니다. 접근이 안 되면 5장의 “오프라인 복구(디스크 분리)”로 바로 넘어가세요.

4.1 fstab 문제: 부팅 블로킹 제거

Emergency mode로 떨어졌거나 특정 마운트에서 타임아웃이 난다면 /etc/fstab의 문제일 확률이 큽니다.

# Serial Console 접속 후
sudo -i

# 현재 부팅 상태/실패 원인 확인
systemctl --failed
journalctl -xb | tail -n 200

# fstab 백업 후 편집
cp -a /etc/fstab /etc/fstab.bak.$(date +%F-%H%M)
vi /etc/fstab

# 자주 쓰는 응급처치:
# - 문제되는 라인 주석 처리
# - 또는 nofail,x-systemd.device-timeout=10s 옵션 추가

수정 후 재부팅:

reboot

4.2 디스크 Full: 부팅에 필요한 최소 공간 확보

/var나 /가 꽉 차면 systemd 서비스들이 연쇄적으로 실패합니다.

sudo -i

df -h
# 큰 파일/로그 빠르게 찾기
du -xhd1 /var | sort -h
journalctl --disk-usage

# 저널 로그 축소
journalctl --vacuum-size=200M

# 임시 파일 정리
rm -rf /tmp/*

# 컨테이너 환경이면 (주의) 이미지/캐시 정리
# docker system prune -af

4.3 sshd가 죽어 접속이 안 되는 경우

콘솔에서 로그인은 되는데 SSH만 안 되면 sshd/방화벽을 의심합니다.

sudo -i
systemctl status ssh || systemctl status sshd
journalctl -u ssh -n 200 --no-pager || journalctl -u sshd -n 200 --no-pager

# 설정 문법 체크
sshd -t

# 방화벽 확인 (환경에 따라)
ufw status || true
firewall-cmd --state || true

# 재시작
systemctl restart ssh || systemctl restart sshd

5) Serial Console이 안 되면: OS 디스크 분리 후 오프라인 복구

부팅이 아예 안 되거나 Serial Console 접근이 막혔다면, OS 디스크를 다른 “복구 VM”에 붙여서 수정하는 방식이 가장 확실합니다.

5.1 절차 개요

  1. 문제 VM Stop (deallocate)
  2. OS Disk를 분리(Detach)하거나, 스냅샷 생성 후 복제(안전)
  3. 동일 리전의 복구 VM 준비
  4. OS Disk를 복구 VM에 데이터 디스크로 Attach
  5. 복구 VM에서 마운트 후 설정 파일 수정
  6. 원 VM에 다시 연결 후 부팅

5.2 Linux 오프라인 마운트/수정 예시

복구 VM에서 디스크가 /dev/sdc로 붙었다고 가정합니다.

sudo -i
lsblk

mkdir -p /mnt/rescue
mount /dev/sdc1 /mnt/rescue

# fstab 수정
cp -a /mnt/rescue/etc/fstab /mnt/rescue/etc/fstab.bak
vi /mnt/rescue/etc/fstab

# cloud-init 비활성화(필요 시)
touch /mnt/rescue/etc/cloud/cloud-init.disabled

umount /mnt/rescue

> 팁: LVM/암호화/복잡한 파티션이면 lsblk -f, pvs/vgs/lvs, cryptsetup 등을 추가로 확인해야 합니다.

6) Boot Diagnostics를 “사후 분석 도구”가 아니라 “예방 장치”로 쓰기

장애가 나면 켜는 것보다, 평소에 다음을 세팅해 두면 복구 시간이 확 줄어듭니다.

  • Boot Diagnostics 상시 Enable
  • 운영 표준에 맞는 로그 보관(Managed vs 지정 Storage)
  • 커널/에이전트 업데이트 전 스냅샷/백업
  • fstab 변경 시 nofail, x-systemd.device-timeout 같은 안전장치 적용
  • cloud-init/userdata는 멱등성/타임아웃/재시도 정책을 명확히

또한 VM이 “부팅은 되는데 접속만 안 되는” 케이스는 빈도가 높습니다. 이 경우는 부팅 진단만으로는 부족하고 네트워크/보안 규칙을 함께 봐야 하므로, 위에서 언급한 SSH 타임아웃 진단 글을 같이 플레이북에 넣어두는 것을 권합니다.

7) 10분 복구 체크리스트(요약)

  • Portal에서 Boot Diagnostics Screenshot 확인 → 부팅 단계 멈춤 지점 파악
  • Serial log에서 키워드 검색: panic, fstab, emergency, no space, grub, cloud-init
  • 가능하면 Serial Console로 즉시 수정(fstab, 디스크 정리, sshd 복구)
  • Serial 불가/부팅 불가면 OS 디스크 오프라인 복구로 전환
  • 재발 방지: Boot Diagnostics 상시 켜기 + 변경 전 스냅샷 + 안전 옵션 적용

부팅 실패는 “원인을 모르면 오래 걸리고, 원인을 알면 짧게 끝나는” 전형적인 장애입니다. Boot Diagnostics로 멈춘 지점을 먼저 확정하고(스크린샷/시리얼 로그), Serial Console 또는 오프라인 복구로 바로 조치하는 루틴을 갖추면 실제로 10분 내 복구가 가능한 케이스가 많습니다.

Discuss on Twitter • View on GitHub