beautifulsoups.dev
Published on

Azure VM 부팅 실패 - UEFI·Secure Boot 진단

Authors

Azure VM이 갑자기 부팅에 실패하면 대부분은 OS 레벨 문제처럼 보이지만, 실제로는 UEFI 부트 체인(펌웨어 -> 부트로더 -> 커널)이나 Secure Boot 정책과의 불일치에서 시작되는 경우가 많습니다. 특히 커널 업데이트, 부트로더 재설치, 디스크 스냅샷 복원, 이미지 변환(Gen1/Gen2), 서명되지 않은 드라이버/부트로더 투입 같은 작업 이후에 “부팅 화면에서 멈춤”, “부트 디바이스를 못 찾음”, “원격 접속 불가” 형태로 나타납니다.

이 글에서는 Azure 환경에서 UEFI·Secure Boot 관련 부팅 실패를 빠르게 진단하는 체크리스트와, 실제로 복구 가능한 경로(Serial Console, Boot diagnostics, 복구 VM 마운트)까지 실무 관점으로 정리합니다.

먼저 확인할 것: 증상 분류와 신호 수집

부팅 실패는 원인을 좁히기 위한 “신호”가 핵심입니다. Azure에서는 화면을 직접 볼 수 없으므로 아래 3가지를 우선 확보합니다.

1) Boot diagnostics 스크린샷/로그

Azure Portal에서 VM의 Boot diagnostics를 켜면 스크린샷과 시리얼 로그를 확인할 수 있습니다. 화면이 UEFI Interactive Shell로 떨어지거나, No bootable device류 메시지가 보이면 부트 체인 쪽 가능성이 큽니다.

2) Serial Console 접근

Serial Console이 활성화되어 있으면 부팅 중 커널 패닉, initramfs 드롭, GRUB 진입 실패 등을 텍스트로 확인할 수 있습니다. Linux의 경우 grub 메뉴가 뜨는지, initramfs 프롬프트로 떨어지는지 여부가 매우 중요합니다.

3) 게스트 OS 로그(오프라인 분석)

부팅이 전혀 되지 않으면 디스크를 떼어내 다른 VM에 붙여 오프라인으로 로그를 봅니다.

  • Linux: /var/log/boot.log, /var/log/syslog, journalctl 로그(예: /var/log/journal)
  • Windows: C:\Windows\System32\winevt\Logs 및 bcdedit 상태

Gen1 vs Gen2: UEFI 문제의 1차 관문

Azure VM은 크게 Gen1(BIOS 기반)과 Gen2(UEFI 기반)로 나뉩니다. 이 차이는 부팅 방식 자체를 바꾸기 때문에, 디스크를 다른 세대 VM에 붙이거나 이미지 변환을 잘못하면 부팅이 깨집니다.

  • Gen1: MBR, BIOS 부트, 전통적인 부트 파티션 구조
  • Gen2: GPT, UEFI 부트, EFI System Partition(ESP) 필요

빠른 체크 포인트

  • Gen2인데 ESP가 없거나 손상되면 UEFI가 부트로더를 못 찾습니다.
  • Gen1 디스크를 Gen2 VM에 붙이면 대체로 부팅이 실패합니다(반대도 마찬가지).

오프라인으로 디스크를 붙였을 때 Linux에서 파티션을 확인하는 예시입니다.

sudo lsblk -f
sudo parted -l

# EFI 파티션이 있다면 보통 vfat(FAT32)로 표시되고, /boot/efi로 마운트됩니다.

ESP가 있어야 하는데 없다면, “왜 없어졌는지”가 중요합니다. 스냅샷 복원 시 특정 파티션이 누락되었거나, 디스크 복제 도구가 GPT/ESP를 제대로 복사하지 못한 경우가 흔합니다.

Secure Boot: 서명 체인 불일치가 만드는 부팅 실패

Gen2 VM에서 Secure Boot가 켜져 있으면, UEFI는 신뢰된 키로 서명된 부트로더/커널만 로드합니다. 즉, 다음 상황에서 부팅이 막힐 수 있습니다.

  • 커스텀 커널/드라이버를 넣었는데 서명이 없거나 키가 다름
  • GRUB 또는 shim이 손상됨
  • 배포판/이미지의 Secure Boot 구성과 Azure 설정이 불일치

어떤 증상이 나오나

  • 부트로더 단계에서 멈추거나, 화면에 인증 실패에 준하는 메시지가 보임
  • Serial Console에 커널까지 못 올라오는 흔적

진단 접근

  1. VM이 Gen2인지 확인
  2. Secure Boot 설정이 켜져 있는지 확인
  3. 최근 변경(커널 업데이트, 부트로더 재설치, 이미지 커스터마이징) 이력 확인

Secure Boot가 의심될 때는 “일시적으로 Secure Boot를 끄고 부팅이 되는지”를 실험하는 것이 가장 빠른 분기점입니다. 다만 운영 환경에서는 보안 요구사항이 있을 수 있으니, 끈 상태로 장기 운영하기보다 원인을 제거하고 다시 켜는 것을 목표로 해야 합니다.

가장 흔한 케이스 5가지와 확인 방법

케이스 1) ESP(/boot/efi) 손상 또는 누락

증상: No bootable device, UEFI Shell로 진입

확인:

# 복구 VM에 OS 디스크를 데이터 디스크로 연결한 뒤
sudo lsblk -f
sudo mkdir -p /mnt/os
sudo mount /dev/sdXn /mnt/os

# EFI 파티션(보통 vfat)을 찾아 마운트
sudo mkdir -p /mnt/efi
sudo mount /dev/sdYn /mnt/efi

ls -al /mnt/efi/EFI

/mnt/efi/EFI 아래에 배포판/벤더 디렉터리(예: ubuntu, redhat, centos)와 grubx64.efi, shimx64.efi 등이 있어야 합니다.

케이스 2) GRUB 설정 깨짐 또는 루트 파일시스템 UUID 변경

증상: GRUB 진입 후 커널 로드 실패, initramfs로 떨어짐

확인:

  • /etc/fstab의 UUID와 실제 파티션 UUID 불일치
  • /boot/grub/grub.cfg 또는 /etc/default/grub 변경
sudo blkid
sudo cat /mnt/os/etc/fstab

디스크 복제/스냅샷/파티션 재구성 후 UUID가 바뀌면 fstab에서 루트 마운트가 실패하면서 부팅이 멈출 수 있습니다.

케이스 3) Secure Boot 상태에서 서명되지 않은 모듈/커널 사용

증상: 커널 직전 또는 커널 로드 초기에 실패

확인:

  • 최근 커널/드라이버 교체 이력
  • shim/grub 업데이트 이력

대응 방향:

  • 공식 서명된 커널로 롤백
  • 배포판 권장 shim/grub 패키지로 복구
  • Secure Boot 정책 요구사항에 맞는 서명 체인 재구성

케이스 4) Windows에서 BCD 손상(UEFI 부트 엔트리 문제)

증상: Windows 로고 전 단계에서 리커버리로 진입하거나 부팅 루프

오프라인 복구(개념 예시):

  • 복구 VM에서 Windows 디스크를 붙인 뒤, WinRE 또는 복구 환경에서 bcdboot 재생성

명령 예시는 환경마다 드라이브 문자가 달라서 그대로 복사하면 위험합니다. 핵심은 EFI 파티션과 Windows 파티션을 정확히 식별한 뒤 BCD를 다시 만드는 것입니다.

케이스 5) 커널 패닉(스토리지/드라이버)인데 UEFI 문제처럼 보이는 경우

증상: 스크린샷은 멈춰 보이지만, Serial Console에는 커널 패닉 로그가 남음

확인:

  • Serial Console에서 마지막 로그가 스토리지 드라이버, 루트 디바이스 탐색, initramfs 관련인지 확인

이 경우는 UEFI 자체보다 “커널이 루트 디스크를 못 찾는” 문제일 수 있습니다. 예를 들어 initramfs 갱신 누락, 드라이버 제거, 디스크 컨트롤러 설정 변경 등이 원인입니다.

복구 전략: Azure에서 안전하게 고치는 순서

1) 스냅샷부터 찍고 시작

부팅 복구는 파티션/부트로더를 건드리는 작업이 많습니다. 먼저 OS 디스크 스냅샷을 찍어 롤백 지점을 확보하세요.

2) “복구 VM + 디스크 마운트” 패턴

가장 재현성이 좋은 방법은:

  1. 문제 VM 종료
  2. OS 디스크를 분리(또는 스냅샷에서 새 디스크 생성)
  3. 정상 VM(복구 VM)에 데이터 디스크로 연결
  4. chroot 또는 오프라인 편집으로 부트로더/설정 복구

Linux에서 chroot 복구의 뼈대 예시입니다.

# 예시: /mnt/os 에 루트 파티션 마운트했다고 가정
sudo mount --bind /dev  /mnt/os/dev
sudo mount --bind /proc /mnt/os/proc
sudo mount --bind /sys  /mnt/os/sys

# UEFI 환경이면 /boot/efi도 함께 마운트 필요
sudo mount /dev/sdYn /mnt/os/boot/efi

sudo chroot /mnt/os /bin/bash

# 여기서 grub 재설치/설정 재생성 등을 수행
# 배포판마다 명령이 다르므로 패키지 매니저/문서에 맞춰 진행

주의: 잘못된 디바이스를 grub-install 대상으로 잡으면 다른 디스크의 부트 영역을 망가뜨릴 수 있습니다. 복구 VM의 OS 디스크가 아니라 “문제 디스크”의 ESP를 대상으로 하고 있는지 계속 확인해야 합니다.

3) Secure Boot 실험은 “원인 분기”로만 사용

Secure Boot를 끄고 부팅이 성공하면 원인이 서명 체인 쪽으로 좁혀집니다. 이후에는 다음 중 하나로 수습합니다.

  • 배포판이 제공하는 Secure Boot 호환 부트로더/shim으로 복구
  • 커스텀 커널/모듈을 제거하거나 서명 체계를 갖춤
  • 정책상 Secure Boot가 필수라면, 끈 상태로 끝내지 말고 재활성화를 목표로 함

운영에서 재발 방지 체크리스트

커널/부트로더 업데이트 전

  • 스냅샷 자동화(변경 작업마다)
  • Gen2/UEFI 여부와 ESP 백업
  • Secure Boot 켜짐 여부 확인

이미지 커스터마이징 시

  • Gen1/Gen2 변환을 섞지 않기
  • ESP 포함 여부를 CI에서 검증(파티션 테이블 검사)
  • 서명되지 않은 부트 컴포넌트 투입 금지 또는 서명 파이프라인 마련

장애 대응 프로세스

  • Boot diagnostics 기본 활성화
  • Serial Console 접근 경로 확보
  • 복구 VM(점프박스) 상시 준비

마무리

Azure VM 부팅 실패는 “OS가 망가졌다”로만 보면 복구 시간이 길어집니다. 먼저 Gen2(UEFI) 여부와 Secure Boot 상태를 기준으로 부트 체인의 어디에서 끊겼는지를 분류하고, Boot diagnostics/Serial Console로 증거를 모은 뒤, 복구 VM에 디스크를 붙여 오프라인으로 수리하는 흐름이 가장 안전하고 빠릅니다.

장애를 진단할 때는 다른 인프라 장애(예: 권한, 토큰, 설정 불일치)처럼 원인 분기를 명확히 나누는 습관이 도움이 됩니다. 비슷한 “진단 중심” 접근은 AKS ImagePullBackOff - ACR 권한·토큰 만료 진단에서도 참고할 수 있습니다.

Discuss on Twitter • View on GitHub