beautifulsoups.dev
Published on

Azure VM 부팅 실패, Serial Console 로그로 복구

Authors

Azure VM이 갑자기 부팅에 실패하면 SSH나 RDP는 당연히 붙지 않고, 진단 확장도 제대로 올라오지 않는 경우가 많습니다. 이때 가장 빠른 단서는 Serial Console(직렬 콘솔) 입니다. 커널 부팅 메시지부터 systemd 단계의 실패까지 그대로 보이기 때문에, “어디에서 멈췄는지”를 먼저 확정하고 그에 맞는 복구 액션을 고르는 게 핵심입니다.

이 글은 다음 흐름으로 진행합니다.

  • Serial Console을 켜고 로그를 확보하는 방법
  • 로그에서 멈춘 지점을 기준으로 원인 분류
  • 자주 터지는 케이스별 복구 절차(실전 커맨드 포함)
  • Serial Console로 해결이 안 될 때의 플랜 B(복구 VM, 디스크 마운트)

참고로 부팅 이후 단계에서 systemd 유닛이 문제를 만드는 경우도 흔합니다. 부팅은 되는데 서비스가 안 뜨는 케이스 진단은 별도로 정리한 글도 함께 참고하면 좋습니다: systemd 서비스가 재부팅 후 안 뜰 때 9분 진단

Serial Console 먼저: “로그 확보”가 복구의 80%

Serial Console이 유효한 상황

  • 커널 패닉, initramfs 진입, dracut 쉘, emergency mode 등으로 SSH가 안 뜰 때
  • 네트워크 설정이 깨져 NIC가 안 올라올 때
  • fstab 오류로 부팅이 멈출 때
  • 부팅 중 특정 유닛에서 무한 대기할 때

반대로, 아래 조건이 충족되지 않으면 Serial Console이 아예 안 뜰 수 있습니다.

  • VM에 Boot diagnostics가 켜져 있어야 함(대부분 Portal에서 켜기 가능)
  • OS가 Serial Console을 지원해야 함(대부분의 Azure 이미지 Linux는 지원)
  • 콘솔 접근 권한(최소 VM Reader 이상 및 Serial Console 권한)

Portal에서 접근 경로

  1. Azure Portal에서 VM 선택
  2. Help 또는 Support + troubleshooting 계열 메뉴에서 Serial console 진입
  3. 콘솔 화면이 뜨면 로그인 프롬프트 또는 부팅 로그가 보임

로그를 “증거로” 남기는 습관

콘솔에서 보이는 메시지는 복구 중에 계속 바뀌므로, 일단 현재 상태를 파일로 남기는 게 좋습니다.

Linux에서 로그인 가능한 상태라면:

# 최근 부팅 로그
journalctl -b -0 --no-pager | tail -n 200

# 이전 부팅 로그(부팅 실패 이후 재시도한 경우 유용)
journalctl -b -1 --no-pager | tail -n 200

# 커널 메시지
dmesg -T | tail -n 200

로그인이 안 되고 emergency mode나 initramfs로 떨어진 경우엔, 화면에 보이는 핵심 에러 라인을 그대로 복사해 티켓/문서에 붙여두는 것만으로도 큰 도움이 됩니다.

부팅 실패를 “멈춘 지점”으로 분류하기

Serial Console 로그를 보면 대개 아래 중 하나로 떨어집니다.

  1. 커널 단계에서 멈춤: kernel panic, VFS mount 실패
  2. initramfs 단계: dracut-initqueue 타임아웃, root 디바이스 못 찾음
  3. systemd 단계: emergency mode, Dependency failed, Job ... timed out
  4. 로그인 직전: 네트워크/sshd 불가, 디스크 full, 권한 문제

각 단계는 복구 접근이 다릅니다. 특히 fstab 오류나 디스크 UUID 변경 같은 문제는 systemd에서 emergency mode로 떨어지는 전형적인 패턴입니다.

케이스 1: fstab 오류로 emergency mode 진입

로그 시그널

  • You are in emergency mode
  • Failed to mount /data 또는 Dependency failed for Local File Systems
  • mount: special device UUID=... does not exist

원인

  • 데이터 디스크를 떼거나 교체했는데 fstab가 예전 UUID를 참조
  • 마운트 옵션 오타
  • 부팅 시 반드시 마운트돼야 하는 항목에 nofail이 없어서 부팅이 중단

복구 절차

  1. 현재 블록 디바이스 확인
lsblk -f
blkid
  1. 문제되는 fstab 라인 찾기
cat /etc/fstab
  1. 빠른 복구 옵션
  • 해당 라인을 주석 처리하거나
  • 부팅 필수 마운트가 아니라면 nofail,x-systemd.device-timeout=10s 같은 옵션을 추가

예시(부팅 중단 방지 목적):

# /etc/fstab 예시
UUID=xxxx-xxxx  /mnt/data  ext4  defaults,nofail,x-systemd.device-timeout=10s  0  2
  1. 재부팅
reboot

부팅이 정상화되면, 이후에 마운트 정책을 다시 정리하는 게 좋습니다. 특히 데이터 디스크는 운영 중 분리될 가능성이 있으면 nofail을 고려해야 합니다.

케이스 2: 디스크 용량 100%로 서비스가 못 뜸(부팅은 되는데 로그인 불가)

로그 시그널

  • No space left on device
  • Failed to start ...
  • journal 또는 rsyslog가 쓰기 실패

복구 절차

  1. 용량 확인
df -h
  1. 즉시 공간 확보(안전한 범위)
  • 오래된 journal 정리
journalctl --disk-usage
journalctl --vacuum-time=7d
  • 패키지 캐시 정리(배포판별)
# Ubuntu/Debian
apt-get clean

# RHEL/CentOS 계열
yum clean all
  1. 부팅 안정화 후 원인 추적
  • 갑자기 커진 디렉터리 확인
du -xhd1 /var | sort -h

케이스 3: systemd 유닛 타임아웃으로 부팅이 멈춤

로그 시그널

  • A start job is running for ... (1min 30s / no limit)
  • Job ... timed out

원인

  • 네트워크 의존 유닛이 영원히 대기
  • 마운트 유닛이 장치를 못 찾아 대기
  • 커스텀 서비스가 부팅 시 무한 블록

복구 절차(Serial Console에서)

  1. 실패 유닛 확인
systemctl --failed
systemctl status <unit-name>

여기서 <unit-name> 같은 표기는 MDX에서 JSX로 오인될 수 있으니, 실제 실행 시에는 예를 들어 systemctl status nginx.service처럼 구체적으로 입력하세요.

  1. 일단 부팅을 살리기 위해 문제 유닛 비활성화
systemctl disable --now problematic.service
  1. 다음 부팅에서 유닛이 잡아먹지 않도록 마스킹(더 강력)
systemctl mask problematic.service
  1. 원인 분석은 부팅 후 진행
  • 설정 파일 경로, 환경 변수, 의존 서비스, 네트워크 준비 순서 등을 점검

이 주제는 범위가 넓어서, systemd 관점의 진단은 위 내부 링크 글을 함께 보면 빠르게 정리됩니다.

케이스 4: 커널 패닉 또는 루트 파일시스템 마운트 실패

로그 시그널

  • Kernel panic - not syncing
  • VFS: Unable to mount root fs
  • initramfs에서 dracut 쉘로 떨어짐

원인

  • 커널/드라이버 업데이트 후 부팅 불가
  • initramfs 손상
  • 루트 디스크 인식 문제(드물지만 스토리지 계층 이슈)

복구 방향

이 단계는 Serial Console만으로 해결이 어려운 경우가 많습니다. 가능한 액션은 다음입니다.

  • GRUB 메뉴가 보이면 이전 커널로 부팅 시도
  • initramfs에서 루트 디바이스 탐색 후 수동 마운트 시도
  • 안 되면 플랜 B: OS 디스크를 분리해 복구 VM에 붙여 오프라인 수정

GRUB가 보이는 환경이라면, 이전 커널 항목으로 들어가서 부팅을 살린 뒤 문제 업데이트를 롤백하는 전략이 효과적입니다.

플랜 B: Serial Console로 안 되면 “복구 VM + OS 디스크 오프라인 수정”

Serial Console이 아예 안 뜨거나, 커널 단계에서 막혀 조작이 불가능하면 다음 절차로 갑니다.

개요

  1. 문제 VM 중지
  2. OS 디스크를 분리
  3. 같은 VNet 또는 접근 가능한 구독에 복구용 VM 준비
  4. 복구 VM에 OS 디스크를 데이터 디스크로 연결
  5. 마운트해서 설정 파일 수정, 로그 확인, SSH 키/네트워크 설정 복구
  6. 원래 VM에 OS 디스크 재연결 후 부팅

Linux에서 오프라인 마운트 예시

복구 VM에 디스크를 붙인 뒤:

lsblk
sudo mkdir -p /mnt/rescue

# 예: 파티션이 /dev/sdc2 라고 가정
sudo mount /dev/sdc2 /mnt/rescue

# 부팅 관련 파일 확인
sudo cat /mnt/rescue/etc/fstab
sudo ls -al /mnt/rescue/var/log

fstab를 고치거나, 네트워크 설정을 되돌리거나, 문제 유닛을 disable 처리하는 등 “부팅 가능한 상태”만 만들어 원래 VM로 되돌리는 것이 목표입니다.

운영 팁: 부팅 실패를 줄이는 체크리스트

  • fstab에 외부/데이터 디스크가 있으면 nofail과 타임아웃 옵션을 고려
  • 커널 업데이트는 가능하면 점검 창에 수행하고, 재부팅 전 Serial Console 접근 경로를 확인
  • 디스크 사용량 알람을 80%부터 설정(특히 /var)
  • 부팅 직후 꼭 필요한 서비스만 After=network-online.target 등에 과도하게 묶지 않기

정리

Azure VM 부팅 실패는 “원인 찾기”보다 “로그를 어디서 보느냐”가 더 어렵습니다. Serial Console은 네트워크가 죽어도 부팅 경로를 그대로 보여주기 때문에, 멈춘 지점을 기준으로 fstab, 디스크 용량, systemd 유닛, 커널 단계 문제를 빠르게 분류할 수 있습니다.

  • emergency mode면 fstab와 마운트 의존성부터
  • 부팅이 느리거나 멈추면 systemd 타임아웃 유닛부터
  • 커널 패닉이면 플랜 B로 오프라인 복구를 준비

부팅이 살아난 뒤에는 재발 방지(알람, 마운트 옵션, 서비스 의존성 정리)까지 마무리해야 같은 장애를 줄일 수 있습니다.

Discuss on Twitter • View on GitHub