- Published on
Azure VM 부팅 실패? Boot Diagnostics로 복구하기
- Authors
- Name
- 스타차일드
- https://x.com/ETFBITX
운영 중인 Azure VM이 갑자기 재부팅을 반복하거나, 부팅은 되는 것 같은데 SSH/RDP가 전혀 붙지 않는 상황은 생각보다 자주 발생합니다. 커널 업데이트 직후, 디스크 용량 100% 직후, fstab 오타, 부트로더 손상, 네트워크 설정 꼬임 같은 원인은 다양하지만 공통점이 하나 있습니다.
바로 인스턴스 내부로 들어가 진단하기가 어렵다는 점입니다. 이때 가장 먼저 확인해야 할 도구가 Azure Boot Diagnostics입니다. 부팅 과정의 스크린샷과 시리얼 콘솔 로그를 통해 “OS가 어디까지 올라왔는지”, “어떤 메시지에서 멈췄는지”를 확인하고, 다음 액션(재부팅/복구/디스크 오프라인 수정)을 결정할 수 있습니다.
아래에서는 Boot Diagnostics를 중심으로, 실제 복구까지 이어지는 절차를 리눅스 VM 기준으로 정리합니다(Windows도 개념은 동일).
Boot Diagnostics가 하는 일과 한계
Boot Diagnostics는 크게 두 가지 정보를 제공합니다.
- Boot screenshot: VM 콘솔 화면 캡처. 커널 패닉, initramfs 드롭, 로그인 프롬프트, fsck 화면 등 “어디서 멈췄는지”를 빠르게 파악할 수 있습니다.
- Serial console log: 부팅 시점의 텍스트 로그. 커널/부트로더/클라우드-init/systemd 메시지를 확인할 수 있습니다.
다만 Boot Diagnostics는 “원인 추정과 다음 조치 결정”에 강하고, 그 자체로 자동 복구를 해주진 않습니다. 부팅이 멈춘 지점에 따라 아래 중 하나로 이어집니다.
- 설정/파일 문제라면: OS 디스크를 떼서 다른 VM에 붙여 수정
- 커널/부트로더 문제라면: GRUB 설정, initramfs 재생성, 커널 롤백
- 디스크/파일시스템 문제라면: fsck, 마운트 옵션 수정, 용량 확보
부팅 실패 유형을 먼저 분류하기
Boot Diagnostics를 보기 전에, 포털에서 VM 상태를 대략 분류하면 시간을 줄일 수 있습니다.
- VM은 Running인데 SSH/RDP만 안 됨: 네트워크(NSG/UDR), sshd, 방화벽, 인증/키, 디스크 full, CPU 100% 등.
- VM이 Running으로 안 올라오고 재부팅 반복: 커널 패닉,
fstab오류, 파일시스템 손상, cloud-init 실패, 드라이버 문제. - 부팅은 되는데 로그인 직전 멈춤: systemd 유닛 실패/무한 재시작, 디스크 마운트 대기.
SSH 지연이나 끊김처럼 “붙긴 붙는데 불안정”한 케이스는 부팅 실패와 결이 다르므로, 별도로 로그를 추적하는 접근이 유효합니다. 관련해서는 리눅스 SSH 접속 지연·끊김, auth.log로 추적하기도 함께 참고하면 좋습니다.
Azure Portal에서 Boot Diagnostics 확인하기
- Azure Portal에서 대상 VM 선택
- 좌측 메뉴에서
Boot diagnostics진입 - 다음을 확인
Screenshot: 멈춘 화면이 커널 패닉인지, initramfs 쉘인지, systemd 로그인지Serial log: 마지막 수십~수백 줄에서 에러 키워드 탐색
자주 보이는 메시지 패턴
Kernel panic - not syncing: 커널/드라이버/루트 파일시스템 접근 실패ALERT! UUID=... does not exist. Dropping to a shell!: 루트 디스크 UUID 변경,fstab/GRUB 불일치Dependency failed for /mnt/...+Timed out waiting for device ...:fstab오타, 네트워크 디스크 마운트 대기Welcome to emergency mode!: 마운트 실패, 파일시스템 오류No space left on device: 디스크 100%로 서비스/로그 폭주
디스크 100%로 인해 부팅 이후 서비스가 올라오지 못하는 경우도 많습니다. 삭제해도 용량이 안 줄어드는(삭제된 파일을 프로세스가 잡고 있는) 케이스까지 포함하면 원인 파악이 까다로워지는데, 이런 상황은 리눅스 디스크 100%인데 삭제해도 용량이 안 줄 때(lsof) 방식이 그대로 통합니다.
복구 전략 1: Serial Console로 응급 조치(가능한 경우)
Boot Diagnostics에서 시리얼 로그만 보는 것과 별개로, Azure는 Serial Console 접속을 지원합니다(배포/설정에 따라 비활성일 수 있음). 시리얼 콘솔로 emergency shell에 진입할 수 있으면, 디스크 분리 없이도 빠르게 처리 가능합니다.
가능한 조치 예시는 다음과 같습니다.
fstab에서 문제 마운트 주석 처리systemctl disable로 문제 서비스 비활성화- 디스크 공간 확보(로그 정리)
예를 들어 fstab의 특정 마운트가 부팅을 막는다면, 임시로 nofail 옵션을 주거나 주석 처리로 부팅을 먼저 살릴 수 있습니다.
# /etc/fstab 예시: 부팅을 막지 않도록 임시 완화
UUID=xxxx /data ext4 defaults,nofail,x-systemd.device-timeout=10s 0 2
또는 systemd 유닛이 계속 재시작되며 부팅을 지연시키는 경우, 시리얼 콘솔에서 원인 유닛을 확인하고 비활성화한 뒤 부팅을 정상화할 수 있습니다.
# 실패한 유닛 확인
systemctl --failed
# 특정 서비스가 부팅을 막는다면 임시 비활성화
systemctl disable --now myservice.service
systemd 재시작 루프의 추적 방법은 systemd 서비스가 계속 재시작될 때 원인 추적법에 정리된 흐름을 그대로 적용할 수 있습니다.
복구 전략 2: OS 디스크를 분리해 오프라인 수정(가장 확실)
부팅이 완전히 막혀 시리얼 콘솔도 못 쓰는 경우, 가장 확실한 방법은 OS 디스크를 떼어내 다른 “복구 VM”에 데이터 디스크로 붙인 뒤 수정하는 것입니다.
절차 개요
- 문제 VM
Stop(deallocate) - OS 디스크 스냅샷 생성(안전장치)
- 동일 리전/가용성 요구사항을 맞춘 복구 VM 준비
- 문제 OS 디스크를 복구 VM에
Attach(데이터 디스크로) - 복구 VM에서 마운트 후 설정 수정
- 디스크를 원래 VM에 다시 연결(필요 시 OS 디스크 스왑)
복구 VM에서 디스크 마운트
복구 VM에 붙으면 보통 /dev/sdc 같은 디바이스로 보입니다. 파티션과 파일시스템을 확인한 뒤 마운트합니다.
# 어떤 디스크/파티션인지 확인
lsblk -f
sudo fdisk -l
# 예: /dev/sdc1 이 루트 파티션이라고 가정
sudo mkdir -p /mnt/rescue
sudo mount /dev/sdc1 /mnt/rescue
# 부팅 관련 파일을 수정하려면 필요에 따라 바인드 마운트
sudo mount --bind /dev /mnt/rescue/dev
sudo mount --bind /proc /mnt/rescue/proc
sudo mount --bind /sys /mnt/rescue/sys
이후에는 /mnt/rescue/etc/fstab, /mnt/rescue/etc/default/grub, /mnt/rescue/var/log 등을 직접 수정할 수 있습니다.
fstab 오류 복구
Boot Diagnostics에서 마운트 타임아웃/디바이스 대기 메시지가 보이면 fstab를 최우선으로 의심합니다.
# 오프라인에서 fstab 열기
sudo nano /mnt/rescue/etc/fstab
# 네트워크/외장 디스크 마운트는 임시로 주석 처리하거나 nofail 적용
# UUID 오타, 타입 오타(ext4/xfs), 마운트 포인트 누락 등을 점검
디스크 용량 100% 복구
용량이 100%면 부팅 후 필수 데몬이 실패하거나, 로그인이 막히기도 합니다. 오프라인에서 큰 로그/덤프를 정리해 부팅을 먼저 살립니다.
# 큰 파일/디렉터리 찾기
sudo du -xhd1 /mnt/rescue/var | sort -h
sudo du -xhd1 /mnt/rescue/var/log | sort -h
# 예: 압축/삭제(정책에 맞게)
sudo rm -f /mnt/rescue/var/log/*.gz
sudo rm -f /mnt/rescue/var/log/journal/*
chroot로 GRUB/initramfs 복구(필요 시)
부트로더/커널 관련 문제는 오프라인 수정만으로 부족할 수 있어 chroot로 복구 작업을 진행합니다.
# chroot 진입
sudo chroot /mnt/rescue /bin/bash
# 배포판에 맞춰 initramfs 재생성(예: Ubuntu/Debian)
update-initramfs -u
# GRUB 재설정(디스크/EFI 환경에 따라 다름)
update-grub
exit
주의: UEFI/BIOS, 디스크 레이아웃, Azure 이미지 종류에 따라 GRUB 설치 방식이 달라집니다. 이 단계는 스냅샷을 만들어 둔 상태에서, 변경을 최소화하며 진행하는 것이 안전합니다.
Boot Diagnostics에서 “어디서 멈췄는지”로 액션을 결정하는 법
Boot Diagnostics를 단순히 “로그 보기”로 끝내면 복구가 느립니다. 아래처럼 멈춘 지점을 기준으로 액션을 정형화해두면 장애 대응 시간이 크게 줄어듭니다.
1) 커널 패닉/루트 디바이스 미발견
- 의심: 커널 업데이트 후 호환성 문제, initramfs 손상, 디스크 UUID 불일치
- 액션: 오프라인
fstab/GRUB 점검, initramfs 재생성, 커널 롤백
2) emergency mode, 마운트 실패
- 의심:
fstab오타, 디스크 손상, 파일시스템 체크 필요 - 액션:
fstab임시 완화(nofail),fsck수행(오프라인 권장)
# 오프라인 fsck 예시(반드시 언마운트 상태에서)
sudo umount /mnt/rescue
sudo fsck -f /dev/sdc1
3) systemd 단계에서 특정 유닛 타임아웃
- 의심: 의존 서비스(DB, 네트워크, 마운트) 지연, 잘못된 설정, 재시작 루프
- 액션: 해당 유닛 비활성화 후 부팅 성공시키고, 부팅 후 원인 분석
4) 로그인 프롬프트까지 왔는데 원격 접속만 실패
- 의심: NSG/방화벽, sshd 설정, 키/계정 문제, 클라우드-init, CPU/디스크 병목
- 액션: Boot Diagnostics로는 한계가 있으니, 네트워크/에이전트/시리얼 콘솔/RunCommand 병행
Azure CLI로 Boot Diagnostics 점검 자동화
장애 대응에서 포털 클릭을 줄이려면, VM 진단 설정 상태를 CLI로 확인하고 표준화하는 것이 좋습니다.
# VM의 부트 진단 설정 확인
az vm boot-diagnostics get-boot-log \
--resource-group my-rg \
--name my-vm
환경에 따라 출력이 길 수 있으니, CI나 런북에서는 마지막 N줄만 추려 알림에 붙이는 식으로 운영합니다.
재발 방지 체크리스트(운영 관점)
부팅 실패는 “한 번 복구”보다 “다음에 더 빨리 복구”가 중요합니다. 아래는 Boot Diagnostics 기반으로 추천하는 기본 체크리스트입니다.
- Boot Diagnostics 항상 활성화(스토리지 계정/관리형 스토리지 정책 포함)
- 커널/에이전트 업데이트는 점진 적용(카나리 VM)
fstab변경은nofail및 타임아웃 옵션을 기본값으로 고려- 디스크 사용률 알림(특히
/var/log, journal) - 시스템 서비스 변경 시
systemctl --failed기반 헬스체크 추가 - OS 디스크 스냅샷 런북(Stop, Snapshot, Attach, Fix, Swap) 문서화
마무리
Azure VM 부팅 실패는 원인이 다양하지만, Boot Diagnostics로 “멈춘 지점”을 먼저 확정하면 복구 경로가 선명해집니다. 스크린샷으로 커널/마운트/systemd 단계를 구분하고, 시리얼 로그로 마지막 에러를 잡은 뒤, 가능하면 시리얼 콘솔로 응급조치, 아니라면 OS 디스크를 분리해 오프라인 수정으로 들어가면 됩니다.
운영 환경에서는 이 과정을 런북으로 표준화해두는 것만으로도, 야간 장애에서 “감으로 재부팅 반복”하는 시간을 크게 줄일 수 있습니다.