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

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

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

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

설정을 변경하기 전에 콘솔에 표시된 내용을 먼저 읽으십시오. 화면에 출력된 텍스트에 따라 장애 유형이 결정됩니다. "부팅되지 않는" 두 서버라도 서로 정반대의 해결책이 필요할 수 있습니다.

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

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

대부분의 제어판은 복구 모드(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은 특정 항목을 단 한 번만 실행한 뒤, 미리 지정한 기본값으로 되돌아갈 수 있습니다. 신뢰할 수 있는 커널을 기본값으로 설정한 다음, 새 커널을 일회성으로 부팅하십시오. 만약 부팅에 실패하더라도 하드 리셋을 수행하면 콘솔 타이밍을 맞출 필요 없이 즉시 정상 커널로 복구됩니다.

GRUB_DEFAULT=saved을 /etc/default/grub에 설정하고 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로 업그레이드를 시작하기 직전에 스냅샷을 생성하십시오. 전날 밤에 생성하는 것이 아니라, 변경하려는 머신과 복원 지점이 정확히 일치하도록 업그레이드 직전에 수행해야 합니다.

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)하십시오. 헤드리스 머신에서 일괄적인 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을 읽어 부팅 중인 커널이 어떤 실행을 통해 설치되었는지 확인하십시오.