커널 업데이트 후 VPS 부팅 실패 시 복구 방법

커널 업데이트 후 VPS가 부팅되지 않을 때의 초기 대응

커널 업데이트 후 VPS가 부팅되지 않는 문제는 보통 몇 분 내에 복구할 수 있습니다. 업데이트 과정에서 이전까지 정상 작동하던 커널이 삭제되지 않기 때문입니다. Ubuntu는 새 커널을 기존 커널 옆에 설치하며, GRUB이 기본으로 부팅할 항목만 변경합니다. 따라서 첫 번째 조치는 복구가 아닙니다. 부팅 메뉴에서 이전 커널을 선택하여 로그인 프롬프트를 확보한 뒤, 실행 중인 시스템에서 진단을 수행하십시오.

서버에서의 복구 작업은 노트북과 다릅니다. 키보드가 연결되어 있지 않고 모니터에 패닉 메시지가 표시되지 않기 때문입니다. 기기가 sshd가 시작되는 지점에 도달하지 못하므로 SSH 접속도 불가능합니다. 아래의 모든 작업은 제공업체의 콘솔을 통해 수행해야 합니다.

설정을 변경하기 전에 콘솔 화면을 먼저 확인하십시오. 화면에 표시된 텍스트에 따라 장애 유형이 결정됩니다. "부팅되지 않는" 두 서버라도 필요한 조치는 정반대일 수 있습니다.

SSH 접속이 불가능할 때 콘솔에 접근하는 방법

사용 중인 서비스 제공업체의 제어판을 열고 콘솔 항목을 찾으십시오. 일반적으로 VNC console, web console, noVNC, serial console 등의 명칭으로 제공됩니다. 두 가지가 모두 있다면 serial console을 우선적으로 사용하십시오. VNC는 화면을 이미지로 보여주는 방식이지만, serial console은 텍스트를 직접 스크롤하고 복사할 수 있기 때문입니다. 서버가 정상 상태일 때 미리 이 기능을 찾아보고 정상적으로 열리는지 확인해 두십시오. 장애가 발생한 상황에서 콘솔을 찾는 것은 침착한 대응을 방해합니다. 이 확인 작업은 새 VPS를 설정하는 첫 10분 내에 방화벽 규칙 및 SSH 키 설정과 함께 수행해야 합니다.

대부분의 제어판은 구조 모드(rescue mode)나 복구 이미지(recovery image)를 제공합니다. 이는 제공업체의 네트워크에서 작은 시스템을 부팅한 뒤 사용자의 디스크를 추가 장치로 연결하는 방식이므로, 기존 디스크의 데이터는 실행되지 않습니다. 구조 모드는 GRUB 자체가 손상되었을 때 사용하는 최후의 수단이며, 서버를 폐기하기 전 데이터를 백업할 때도 사용합니다.

로그인할 수 없는 상태에서는 sudo reboot 명령을 실행할 수 없으므로, 부팅 메뉴에 진입하려면 제어판에서 하드 리셋(hard reset)을 수행해야 합니다. 하드 리셋은 전원을 강제로 차단하는 것과 같습니다. 파일 시스템이 비정상적으로 종료되므로, 다음 부팅 시 파일 시스템 검사가 수행될 수 있음을 예상해야 합니다.

GRUB 메뉴에서 이전 커널을 선택하려면 어떻게 해야 합니까?

재부팅 버튼을 누른 직후부터 콘솔 화면을 주시하십시오. 부팅 초기 몇 초 동안 Esc 키를 반복해서 누르거나, 레거시 BIOS 모드로 부팅되는 시스템이라면 Shift 키를 누르고 계십시오. 메뉴가 나타나는 시간은 매우 짧고 콘솔 뷰어 연결에도 시간이 걸릴 수 있으므로, 일찍부터 키를 누르기 시작하여 계속 유지하십시오.

메뉴가 나타나면 "Advanced options for Ubuntu"를 선택하십시오. 해당 하위 메뉴에는 설치된 모든 커널이 최신순으로 나열되며, 각 커널마다 복구 모드(recovery mode) 항목이 포함되어 있습니다. 최신 커널 바로 아래에 있는 두 번째 일반 항목을 선택하고 Enter 키를 누르십시오. 복구 모드는 용도가 다르며, 최소한의 단일 사용자 시스템으로 부팅하여 서비스를 복구하는 것이 아니라 시스템 수리 작업을 수행하기 위한 것입니다.

이전 커널로 부팅에 성공하면 서버를 다시 운영할 수 있습니다. 현재 사용 중인 커널 버전을 확인하고 해당 번호를 기록해 두십시오.

uname -r
dpkg -l 'linux-image-*' | grep '^ii'

dpkg 명령의 출력 결과는 설치된 커널 목록입니다. 만약 목록에 한 줄만 표시된다면 대체할 수 있는 커널이 없는 상태이므로, 이를 가장 먼저 해결해야 합니다.

GRUB 메뉴가 나타나지 않습니다. 어떻게 해야 합니까?

클라우드 이미지는 메뉴를 숨기는 설정을 포함하여 배포됩니다. Ubuntu 이미지는 일반적으로 /etc/default/grub.d/ 경로의 파일에서 타임아웃을 0으로 설정하므로, 최신 커널이 즉시 시작되어 사용자가 입력할 기회가 없습니다.

반대로 메뉴가 화면에 멈춰 있어 시스템이 응그된 것처럼 보이는 경우도 있습니다. GRUB은 부팅 실패를 기록하며, 다음 시작 시 누군가 키를 누를 때까지 메뉴를 유지할 수 있습니다. 키보드가 없는 장비에서는 이 대기 상태가 끝나지 않습니다. 콘솔에 메뉴가 떠 있고 아무런 반응이 없다면 이런 상황입니다. 항목을 선택하여 부팅을 계속하십시오.

시스템이 정상일 때 두 경우 모두 해결하십시오. /etc/default/grub 파일을 편집합니다:

GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=10
GRUB_RECORDFAIL_TIMEOUT=10
GRUB_TERMINAL="console serial"
GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200"
GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0,115200"

그다음 설정을 적용하고 편집 내용이 유지되었는지 확인하십시오. /etc/default/grub.d/의 파일들은 /etc/default/grub 이후에 읽히므로 설정을 덮어쓸 수 있습니다.

sudo update-grub
grep -rE 'TIMEOUT|TERMINAL' /etc/default/grub /etc/default/grub.d/

GRUB_TERMINAL="console serial" 설정은 메뉴를 그래픽 콘솔과 시리얼 포트 모두로 출력하므로, 관리 패널에서 제공하는 어떤 뷰어에서도 메뉴를 볼 수 있습니다. console= 커널 인자도 이후 부팅 메시지에 대해 동일한 역할을 합니다. 부팅 시 10초의 지연은 새벽 2시에 메뉴에 접근해야 할 상황을 대비하는 저렴한 비용입니다.

어떤 유형의 장애인가?

콘솔 출력이 멈추기 직전의 마지막 20줄을 읽어 보십시오. 커널 업데이트 후 발생하는 대부분의 문제는 다음 네 가지 패턴으로 분류됩니다.

GRUB이 자신의 파일을 찾지 못하는 경우. grub rescue> 프롬프트가 나타나거나 존재하지 않는 파티션 또는 파일에 관한 오류가 발생하며, 커널 메시지가 전혀 출력되지 않습니다. 이는 아직 커널이 관여하기 전 단계입니다. 커널 패키지 자체의 문제라기보다는 디스크나 파티션 변경, 혹은 잘못된 장치에 부트로더가 기록되었을 때 발생합니다.

커널은 시작되었으나 루트 파일시스템을 마운트하지 못하는 경우. 커널 메시지가 흐르다가 (initramfs) 프롬프트가 표시되는 busybox 셸로 진입하거나, 루트 파일시스템을 마운트할 수 없다는 패닉 메시지와 함께 부팅이 종료됩니다. 커널은 로드되었습니다. 실제 루트 파일시스템을 찾아 마운트하는 작은 임시 루트인 initramfs가 디스크를 찾지 못한 것입니다. Ubuntu의 경우, 일반적으로 루트 장치를 기다리다 포기했다는 메시지와 함께 찾으려던 UUID가 출력됩니다. 해당 UUID를 복사한 뒤 나중에 blkid 출력 결과와 비교하십시오.

논리 볼륨이 나타나지 않는 경우. 이는 앞서 언급한 유형 중 특정 원인에 의한 것입니다. (initramfs) 프롬프트에서 ls /dev/mapper을 실행하십시오. 만약 control 항목만 보인다면 LVM(logical volume manager) 볼륨이 활성화되지 않은 것이며, 따라서 루트 장치가 존재하지 않는 상태입니다. 볼륨 그룹을 수동으로 활성화하십시오:

lvm vgchange -ay
ls /dev/mapper
exit

exit를 입력하면 제어권이 다시 initramfs 스크립트로 넘어가며 마운트를 재시도합니다. 이때 시스템이 부팅된다면 새로운 initramfs에 LVM 관련 구성 요소가 누락된 것이므로, 커널을 건드리는 대신 해당 이미지를 다시 빌드하여 복구해야 합니다.

Linux 관련 메시지가 전혀 없는 경우. 콘솔에 펌웨어 텍스트, UEFI(unified extensible firmware interface) 셸이 표시되거나, 화면이 비어 있고 커널 출력이 없거나, 재부팅이 반복됩니다. Linux가 실행되기 전 단계에서 장애가 발생한 것입니다. 시스템이 정상화되면 서버가 실제로 어떤 모드를 사용하는지 확인하십시오. 많은 VPS 인스턴스가 레거시 BIOS 모드로 부팅되어 EFI 경로를 전혀 사용하지 않기 때문입니다:

[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
mountpoint /boot/efi
sudo efibootmgr -v

업그레이드 도중 /boot/efi이 마운트되지 않은 상태였다면 UEFI 머신에서 흔히 발생하는 원인이 됩니다. EFI 시스템 파티션을 관리하는 패키지가 일반적인 빈 디렉터리에 기록해 버리기 때문입니다. 펌웨어는 디스크의 내용과 일치하지 않게 될 때까지 기존 부트 항목으로 부팅을 시도합니다.

마지막으로, 부팅 실패가 아닌 경우도 있습니다. 시스템이 응급 모드(emergency mode)라는 메시지와 함께 루트 셸에 도달했다면, 커널은 부팅되었으나 사용자 공간(userspace)에서 멈춘 것입니다. 이는 보통 /etc/fstab에 잘못된 줄이 있거나 파일시스템 검사에 실패했을 때 발생합니다. 해당 셸에서 journalctl -xb를 실행하여 실패한 유닛의 이름을 확인하십시오.

커널 패키지가 손상되었습니까, 아니면 initramfs입니까?

이 두 문제는 콘솔에서 볼 때 동일해 보이지만 서로 다른 복구 방법이 필요합니다. 이전 커널로 부팅한 뒤 파일을 비교하십시오.

ls -l /boot/vmlinuz-* /boot/initrd.img-*
df -h /boot

설치된 모든 버전마다 하나의 vmlinuz-과 그에 대응하는 하나의 initrd.img-이 있어야 하며, 각각 적절한 크기를 유지해야 합니다. initrd가 없거나 다른 파일보다 현저히 작다면 initramfs 생성에 실패한 것입니다. 일반적인 원인은 /boot 용량 부족이며, 증거는 패키지 로그에 남아 있습니다.

sudo grep -iE 'no space|update-initramfs' /var/log/apt/term.log
sudo tail -n 40 /var/log/apt/history.log

history.log는 마지막 실행 시 어떤 패키지가 언제 설치되었는지 정확히 나열하므로, 무엇이 변경되었는지에 대한 논란을 해결해 줍니다.

/boot이 가득 찼다면 먼저 여유 공간을 확보한 뒤, 필요한 버전에 대해 이미지를 다시 빌드하고 메뉴를 새로 고침하십시오. 아래의 자리 표시자는 실제 릴리스가 아니므로, 본인의 ls 출력에서 버전 문자열을 가져와 사용하십시오.

KVER=6.8.0-XX-generic
sudo update-initramfs -c -k "$KVER"
sudo update-grub
ls -l /boot/initrd.img-$KVER

마지막 ls는 확인을 위한 것입니다. 정상적인 크기의 파일이 생성되었다면 이미지가 정상적으로 존재하는 것입니다. 만약 커널 이미지 자체가 손상되었거나 dpkg -l이 패키지를 ii 이외의 상태로 표시한다면, 패키지를 재설치하십시오.

sudo apt install --reinstall linux-image-$KVER
sudo dpkg --configure -a

커널 부팅 실패 시 복구 모드에서 수리하기

메뉴의 모든 항목으로 부팅이 실패하면, 제공업체의 복구 이미지를 부팅하여 외부에서 디스크를 수리해야 합니다. 디스크는 마운트되지 않은 장치로 나타나므로, 내부의 어떤 프로세스도 실행 중이지 않으며 충돌을 일으킬 요소도 없습니다.

sudo lsblk -f
sudo vgchange -ay
sudo mount /dev/ubuntu-vg/ubuntu-lv /mnt
sudo mount /dev/vda2 /mnt/boot
sudo mount /dev/vda1 /mnt/boot/efi

for d in dev proc sys run; do sudo mount --rbind /$d /mnt/$d; done
sudo chroot /mnt /bin/bash

df -h /boot
update-initramfs -u -k all
update-grub
grub-install /dev/vda
exit

다음 부팅을 위험에 빠뜨리지 않고 새 커널 테스트하기

GRUB은 특정 항목을 단 한 번만 실행한 뒤, 미리 지정한 기본값으로 되돌아갈 수 있습니다. 신뢰할 수 있는 커널을 기본값으로 설정한 다음, 새 커널을 이번 부팅에만 사용하도록 실행하십시오. 만약 새 커널이 실패하더라도, 패널에서 하드 리셋을 수행하면 콘솔 타이밍을 맞출 필요 없이 즉시 정상 작동하는 커널로 복구됩니다.

/etc/default/grub에서 GRUB_DEFAULT=saved을 설정하고 sudo update-grub를 실행한 뒤, 항목 제목을 나열하여 정확한 이름을 확인하십시오:

grep -E "(menuentry|submenu) " /boot/grub/grub.cfg | cut -d"'" -f2
sudo grub-set-default "Advanced options for Ubuntu>Ubuntu, with Linux 6.8.0-XX-generic"
sudo grub-editenv list
sudo grub-reboot 0
sudo reboot

grub-editenv list은 선택한 제목을 saved_entry로 출력해야 합니다. 이 출력은 해당 메커니즘이 정상 작동한다는 증거입니다. 설정을 저장하려면 /boot/grub/grubenv에 쓰기 권한이 있어야 하는데, 일부 레이아웃에서는 이 과정이 조용히 실패할 수 있기 때문입니다. 항목 0은 메뉴의 맨 위에 위치하며, 가장 최신 커널을 의미합니다. 커널이 설치되거나 제거될 때마다 번호가 바뀌므로, 번호보다는 제목을 사용하는 것이 더 안전합니다.

headless 서버에서 autoremove가 위험한 이유

APT는 스스로 삭제해서는 안 되는 커널 패키지 목록을 유지합니다. 사용자의 시스템에서 해당 목록을 확인하십시오.

cat /etc/apt/apt.conf.d/01autoremove-kernels
dpkg -l 'linux-image-*' | grep -c '^ii'

이 파일은 커널 패키지가 변경될 때마다 다시 생성되며, 현재 실행 중인 커널과 가장 최근의 커널을 보호합니다. 문제는 타이밍입니다. 새로운 커널로 재부팅한 직후에 sudo apt autoremove --purge를 실행하면 보호 목록이 이미 갱신되어, 의존하고 있던 이전 커널이 더 이상 보호 대상에서 제외됩니다. 키보드가 연결된 기기라면 불편한 정도에 그치지만, headless 서버에서는 부팅 메뉴를 선택하는 것과 복구 이미지로 디스크를 마운트해야 하는 상황의 차이를 만듭니다.

최소 2개의 커널을 유지하고, /boot에 여유가 있다면 3개를 유지하십시오. 현재 실행 중인 커널을 삭제하지 않도록 uname -r을 확인한 뒤, 이전 커널을 이름으로 직접 삭제하십시오.

uname -r
sudo apt purge linux-image-6.8.0-XX-generic
dpkg -l 'linux-image-*' | grep '^ii'

그 후 마지막 명령을 다시 실행하십시오. 개수가 3개에서 2개로 줄어드는 것은 정리 작업입니다. 개수가 1개로 줄어드는 것은 다음 재부팅 시 발생할 장애를 예고하는 것입니다.

업그레이드 전 스냅샷 생성

apt upgrade를 수행하기 전 생성한 스냅샷은 부팅 과정에 의존하지 않는 유일한 복구 경로입니다. 스냅샷을 복원하면 디스크 상태가 이전 커널이 기본값이었던 시점으로 되돌아가며, 콘솔을 열어둔 상태에서 업그레이드를 다시 시도할 수 있습니다. 실행 중인 머신의 스냅샷은 크래시 일관성(crash consistent)을 유지하는데, 이는 전원이 차단된 것과 같은 상태로 디스크를 캡처함을 의미합니다. 따라서 서비스 제공업체가 오프라인 스냅샷을 지원한다면 먼저 서버를 종료하십시오. 스냅샷은 백업이 아닙니다. 일반적으로 복사 대상 볼륨과 동일한 인프라에 저장되기 때문입니다. VPS 스냅샷과 실제 백업의 차이를 이해하는 것은 커널 이상의 장애가 발생했을 때 어떤 방법으로 서버를 복구할지 결정하는 기준이 됩니다.

이 과정은 커널, initramfs 도구, 부트로더, GRUB 설정이 한 번에 변경되는 릴리스 업그레이드에서 가장 중요합니다. Ubuntu 24.04에서 26.04로의 업그레이드를 시작하기 직전에 스냅샷을 생성하십시오. 전날 밤에 미리 생성하는 것이 아니라, 변경하려는 머신 상태와 복원 지점이 일치하도록 직전에 수행해야 합니다. 서버에 아직 업그레이드 알림이 오지 않았다면 이는 설정 오류가 아니라 일정 문제일 가능성이 큽니다. LTS에서 LTS로의 전환은 첫 번째 포인트 릴리스인 26.04.1부터 가능하기 때문입니다.

unattended-upgrades가 커널 패키지를 처리하는 방식

Ubuntu의 unattended-upgrades는 사용자 확인 없이 보안 업데이트를 설치하며, 커널 패키지도 다른 패키지와 마찬가지로 보안 저장소(security pocket)를 통해 전달됩니다. 이로 인해 두 가지 결과가 발생합니다.

첫째, 새 커널은 설치되지만 즉시 실행되지는 않습니다. 커널은 부팅 시에만 적용되기 때문입니다. /var/run/reboot-required 파일이 생성되고 /var/run/reboot-required.pkgs가 재부팅을 요청한 주체를 명시하지만, /etc/apt/apt.conf.d/50unattended-upgrades에서 Unattended-Upgrade::Automatic-Reboot를 활성화하지 않았다면 아무것도 자동으로 재시작되지 않습니다.

cat /var/run/reboot-required.pkgs
grep -E 'Automatic-Reboot|Blacklist' /etc/apt/apt.conf.d/50unattended-upgrades

둘째, 이러한 시차로 인해 문제의 원인을 파악하기 어려워집니다. 서버에 3월에 커널을 설치하고 6월에 전혀 다른 이유로 재부팅을 했는데 부팅에 실패할 수 있습니다. 부팅을 방해한 변경 사항은 3개월 전의 것이므로, 당일 수행한 작업으로는 원인을 설명할 수 없습니다. 현재 부팅 실패의 원인이 된 커널을 설치한 실행 기록은 /var/log/apt/history.log에서 확인할 수 있습니다.

콘솔 창을 열어둔 상태에서 직접 선택한 날짜에 의도적으로 재부팅을 수행하십시오. 이 습관 하나만으로도 원인을 알 수 없는 장애를 2분 내에 해결 가능한 작업으로 바꿀 수 있습니다. 예기치 않은 상황 없이 자동화를 유지하려면 자동 설치는 켜두되 자동 재부팅은 끄고, 정확한 설정 방법은 Ubuntu에서 unattended-upgrades를 구성하는 방법을 참조하십시오. sudo apt-mark hold linux-image-generic을 사용하여 커널 패키지를 보류(hold)하면 업데이트가 완전히 중단되며, 동시에 커널 보안 패치도 적용되지 않습니다. 따라서 이는 안전 조치가 아니라 사용자가 감수하기로 결정한 트레이드오프로 간주해야 합니다.

FAQ

키보드를 사용할 수 없는 VPS에서 이전 커널로 부팅하려면 어떻게 해야 합니까?

제공업체의 콘솔(VNC 또는 시리얼)을 열고 제어판에서 강제 재부팅을 수행하십시오. 정상적인 재부팅을 위한 로그인이 불가능하기 때문입니다. 시스템이 다시 시작될 때 Esc를 반복해서 누르거나, 레거시 BIOS 부팅인 경우 Shift을 길게 눌러 GRUB 메뉴를 띄우십시오. "Advanced options for Ubuntu"를 선택한 다음 최신 커널 아래에 있는 항목을 선택하십시오. 로그인 프롬프트가 나타나면 uname -r을 실행하여 현재 사용 중인 커널을 확인하고, dpkg -l 'linux-image-*'를 실행하여 설치된 다른 커널을 확인하십시오. 시스템이 다시 정상 작동한 후에 진단을 시작하십시오.

VPS에서 GRUB 메뉴가 전혀 보이지 않는 이유는 무엇입니까?

클라우드 이미지는 일반적으로 /etc/default/grub.d/ 아래의 파일에서 GRUB 타임아웃을 0으로 설정하므로, 아무것도 누를 틈 없이 최신 커널로 바로 부팅됩니다. /etc/default/grub에서 GRUB_TIMEOUT=10와 GRUB_TIMEOUT_STYLE=menu를 설정하고, 메뉴가 시리얼 콘솔에도 출력되도록 GRUB_TERMINAL="console serial"을 추가한 뒤 sudo update-grub을 실행하십시오. 해당 디렉터리의 파일들은 메인 파일 이후에 읽히며 설정을 덮어쓸 수 있으므로 grep -r TIMEOUT /etc/default/grub /etc/default/grub.d/로 최종 설정을 확인하십시오.

/boot 공간을 확보하기 위해 이전 커널을 삭제해야 합니까?

가장 오래된 커널들을 삭제하되 최소 두 개는 유지하십시오. /boot이 가득 차면 그 자체로 장애 요인이 됩니다. initramfs 생성에 실패하게 되고, 결과적으로 작동 가능한 이미지가 없는 커널만 남게 되기 때문입니다. uname -r을 확인하여 현재 실행 중인 커널이 삭제 대상에 포함되지 않도록 한 뒤, 정확한 패키지 이름으로 삭제(purge)하십시오. 헤드리스(headless) 장비에서는 일괄적인 sudo apt autoremove --purge 실행을 피하십시오. 보호된 커널 목록은 커널이 변경될 때마다 재생성되는데, 잘못된 시점에 실행하면 커널이 하나만 남게 되어 메뉴에 대체 부팅 항목이 사라질 수 있습니다.

unattended-upgrades가 부팅을 방해할 수 있습니까?

부팅에 실패하는 커널이 설치될 수는 있지만, /etc/apt/apt.conf.d/50unattended-upgrades에서 Unattended-Upgrade::Automatic-Reboot이 true로 설정되어 있지 않으면 시스템을 자동으로 재시작하지 않습니다. 보통은 지연된 장애 형태로 나타납니다. 자동 업데이트 실행 중에 커널이 설치되고 /var/run/reboot-required가 생성되지만, 문제는 몇 주 뒤 다음 재부팅 시점에야 드러납니다. 콘솔을 미리 열어둔 상태에서 의도적으로 재부팅을 수행하고, /var/log/apt/history.log을 읽어 부팅 중인 커널이 어떤 실행 과정에서 설치되었는지 확인하십시오.