Ubuntu 업그레이드 중단 시 복구 방법

Ubuntu 업그레이드 중단: 증상부터 파악하기

Ubuntu 24.04에서 26.04로의 릴리스 업그레이드가 실패하면 서버는 4가지 상태 중 하나에 놓이게 되며, 상태마다 해결 방법이 다릅니다. 업그레이드 프로세스가 연결이 끊긴 screen 세션 내에서 여전히 실행 중일 수 있습니다. 패키지가 절반만 설정된 상태에서 dpkg가 강제 종료되어 apt가 모든 명령을 거부할 수도 있습니다. 설치된 패키지는 24.04인데 apt 소스 목록은 26.04를 가리키고 있을 수도 있습니다. 혹은 서버가 아예 부팅되지 않을 수도 있습니다. 어떤 상태인지 파악하기 전에는 아무 명령도 입력하지 마십시오. 한 상태에 대한 해결책이 다른 상태를 더 악화시킬 수 있기 때문입니다.

모든 경우에 적용되는 규칙이 하나 있습니다. dpkg의 상태를 알기 전까지는 재부팅하지 마십시오. 패키지 교체 도중 재부팅을 하면 해결 가능한 dpkg 중단 문제가 이 가이드 후반부에 다루는 부팅 불가 상태로 변합니다. 또한 첫 번째 apt나 dpkg 프로세스가 살아있을 가능성이 있다면 두 번째 프로세스를 시작하지 마십시오. 패키지 데이터베이스에 두 개의 프로세스가 동시에 쓰기를 시도하면 데이터베이스가 손상됩니다.

이 가이드는 사용자가 24.04에서 26.04로의 업그레이드 가이드를 따랐고 시작 전 스냅샷을 생성했다고 가정합니다. 만약 스냅샷을 생성하지 않았다면 최악의 상황에 대한 해결책이 스냅샷임을 인지하고 부팅 관련 섹션을 읽어주십시오.

업그레이드가 여전히 실행 중입니까?

실패했다고 보고된 많은 업그레이드가 실제로는 여전히 실행 중인 상태입니다. SSH 세션이 끊기고 터미널 화면이 멈췄더라도 업그레이더는 사용자와 관계없이 작업을 계속 수행합니다.

do-release-upgrade는 이러한 상황을 대비해 설계되었습니다. 서버 환경에서 텍스트 인터페이스로 실행될 때, do-release-upgrade는 스스로를 GNU screen 세션으로 감싸기 때문에 터미널 연결이 끊겨도 업그레이드는 중단되지 않습니다. 또한 SSH 세션에서 시작된 것을 감지하면 다른 포트(기본값 1022)에서 두 번째 sshd를 시작할 것을 제안합니다. 이는 패키지 교체 중 메인 SSH 데몬에 문제가 생겨도 접속을 유지할 수 있게 합니다. 이 두 가지 사실은 현재 상황에서 매우 중요합니다.

SSH로 다시 접속하여 screen 세션을 찾으십시오. 업그레이더는 root 권한으로 sudo 하에서 실행되었으므로, 일반 사용자 계정으로 screen -ls 명령을 실행해서는 세션 목록을 볼 수 없습니다.

sudo screen -ls

screen -ls은 각 세션의 상태를 attached 또는 detached로 표시합니다. 세션이 목록에 있다면 다시 연결하십시오. 끊긴 SSH 연결이 세션을 해제하지 않아 여전히 attached로 표시된다면, -d을 사용하여 먼저 기존 연결을 강제로 해제하십시오.

sudo screen -d -r

두 개 이상의 세션이 나열되어 있다면 screen -ls의 세션 이름을 -r 뒤에 입력하십시오. sudo do-release-upgrade을 다시 실행하는 방법도 있습니다. 업그레이더는 실행 시 기존 screen 세션이 있는지 확인하고, 있다면 새로 시작하는 대신 해당 세션에 다시 연결합니다. 어느 방법을 사용하든 실행 중인 업그레이드 화면으로 돌아가게 되며, 보통 설정 파일 변경이나 서비스 재시작에 대한 질문에서 멈춰 있을 것입니다. 질문에 답하여 업그레이드를 완료하십시오.

업그레이드 가이드의 권장대로 tmux 내부에서 업그레이드를 시작했다면, 먼저 tmux attach를 사용하여 tmux에 다시 연결하십시오. screen 세션이 해당 tmux 창 안에서 실행 중이므로 업그레이드 화면을 바로 볼 수 있습니다. 만약 창에 셸 프롬프트만 떠 있다면 업그레이더는 더 이상 실행 중이 아닌 것이며, 다음 단계로 sudo screen -ls을 확인해야 합니다.

메인 SSH 포트 연결이 거부된다면 대체 포트인 ssh -p 1022 user@host를 시도하십시오. 해당 데몬은 업그레이드가 진행되는 동안에만 존재합니다. 두 포트 모두 접속할 수 없다면 제공업체의 콘솔을 사용하십시오. 콘솔에서 sudo ss -ltnp를 실행하면 sshd 프로세스가 어떤 포트에서 대기 중인지 확인할 수 있으며, sudo ufw status을 통해 방화벽이 대체 포트를 허용하고 있는지 알 수 있습니다.

screen 세션이 존재하지 않고 콘솔에서도 대기 중인 작업이 없다면 업그레이드는 실제로 중단된 것입니다. 패키지 데이터베이스를 건드리기 전에 작업 중인 프로세스가 없는지 확인하십시오.

ps -eo pid,etime,cmd | grep -iE '[u]pgrade|[d]pkg|[a]pt'

결과가 비어 있다면 dpkg가 유휴 상태이므로 복구 작업을 진행할 수 있습니다. 경과 시간이 긴 dpkg 또는 apt 프로세스가 있는데 다시 연결할 screen 세션이 없다면 해당 프로세스는 멈춘 것입니다. 몇 분 정도 기다린 후 콘솔에서 응답을 기다리는 debconf 질문이 있는지 확인하고, 그 후에 프로세스를 종료하십시오. 프로세스가 잠금 파일을 점유하고 있는 동안 /var/lib/dpkg/ 또는 /var/lib/apt/lists/ 아래의 잠금 파일을 절대 삭제하지 마십시오. 이 잠금은 두 프로세스가 동시에 패키지 데이터베이스에 기록하여 데이터가 손상되는 것을 막는 유일한 장치입니다.

dpkg 작업이 중단되어 apt가 실행되지 않는 경우

패키지 압축 해제와 설정 스크립트 실행 사이에서 dpkg가 강제 종료되면, 해당 작업이 미완료 상태로 /var/lib/dpkg/status에 기록됩니다. 이후 실행되는 모든 apt 명령어는 이 상태를 읽고 중단되는데, 이는 apt가 작업이 완료되지 않은 데이터베이스 위에서 추가 작업을 수행하지 않기 때문입니다. apt가 어떤 문구로 거부하든, 첫 번째 조치는 동일합니다.

sudo dpkg --configure -a

이 명령어는 압축은 풀렸으나 설정이 완료되지 않은 모든 패키지의 설정 단계를 마무리합니다. 의존성 순서에 따라 메인테이너 스크립트를 실행하며, 시스템 업그레이드가 중간에 멈춘 경우 시간이 오래 걸릴 수 있으므로 작업이 끝날 때까지 기다려야 합니다. 특정 패키지에서 멈춘다면 패키지 이름과 실패한 스크립트가 출력됩니다. 해당 이름을 기록해 두십시오. 업그레이드를 중단시킨 주범이며, 다음 섹션에서 오류 내용을 확인하는 방법을 설명합니다.

그다음, 중단으로 인해 충족되지 못한 의존성을 apt가 복구하도록 합니다. 일부 패키지는 업그레이드되었으나 그 패키지가 의존하는 패키지는 업그레이드되지 않았을 수 있기 때문입니다.

sudo apt --fix-broken install

이어서 업그레이더가 수행 중이던 업그레이드를 마무리합니다.

sudo apt update
sudo apt full-upgrade

upgrade 대신 full-upgrade을 사용하십시오. 릴리스 업그레이드는 패키지 삭제를 수반하는데, 일반 upgrade은 삭제 작업을 거부하기 때문입니다. 확인을 누르기 전에 apt가 출력하는 요약 정보를 읽어 보십시오. 소수의 패키지가 삭제되는 것은 정상입니다. 하지만 ubuntu-server, systemd, openssh-server 또는 커널 패키지가 삭제 목록에 있다면, 작업을 중단하고 apt가 왜 해당 패키지들을 삭제하려 하는지 먼저 파악해야 합니다.

다른 작업을 수행하기 전에 결과를 확인하십시오.

sudo dpkg --audit
sudo apt-get check

dpkg --audit은 여전히 깨진 상태인 모든 패키지를 나열하며, apt-get check은 충족되지 않은 의존성을 보고합니다. 두 명령어 모두 아무것도 출력하지 않아야 합니다. 정상이라면 sudo apt autoremove를 실행하여 더 이상 의존하는 패키지가 없는 24.04 패키지를 제거하고, cat /etc/os-release으로 릴리스를 확인한 뒤 sudo update-initramfs -u -k all과 sudo update-grub를 실행하고 나서 재부팅하십시오.

/var/log/dist-upgrade를 읽어 업그레이드를 중단시킨 패키지 찾는 법

업그레이더는 모든 기록을 /var/log/dist-upgrade/에 남깁니다. 업그레이드를 여러 번 시도했다면 이전 시도의 로그는 타임스탬프가 붙은 하위 디렉터리로 이동하므로, 먼저 ls -la /var/log/dist-upgrade/를 확인하여 실패한 실행 시점과 일치하는 디렉터리를 읽으십시오.

main.log는 업그레이더의 일지입니다. 실행 단계와 소스에 대해 내린 결정이 기록되어 있습니다. 업그레이더 자체가 충돌했다면 Python 트레이스백도 여기에 포함됩니다. 끝부분부터 읽으십시오. 마지막 줄은 중단 당시의 단계를 알려주며, 트레이스백이 있다면 패키지가 아닌 도구 자체의 실패입니다.

apt.log에는 의존성 해결 과정의 논리가 담겨 있습니다. 내용이 방대하며, apt가 업그레이드 계산 자체를 거부했을 때(패키지에 손대기 전의 실패) 중요합니다. 업그레이드가 패키지 설치 단계까지 진행되었다면 보통 이 파일은 건너뛰어도 됩니다.

apt-term.log은 패키지 실패 시 확인해야 할 파일입니다. 업그레이드 중 터미널에 출력되었던 dpkg의 내용을 그대로 담고 있습니다. 마지막에 언급된 패키지가 업그레이드 중단 당시 실행 중이던 패키지이며, 메인테이너 스크립트가 실패했다면 스크립트의 오류 바로 위에 dpkg의 불만 사항이 기록되어 있습니다.

sudo tail -n 60 /var/log/dist-upgrade/apt-term.log
sudo grep -in 'error' /var/log/dist-upgrade/apt-term.log | tail

/var/log/dpkg.log과 교차 검증하십시오. 이 파일은 dpkg가 수행한 모든 상태 변경을 타임스탬프와 함께 기록합니다. tail -n 30 /var/log/dpkg.log는 dpkg가 마지막으로 다룬 패키지와 수행한 작업을 보여주며, 이는 두 번째 출처를 통한 동일한 답변입니다.

서버에서 이 단계의 실패는 대부분 몇 가지 원인에서 비롯됩니다. 패키지의 postinst에서 재시작하는 서비스가 사용자가 수정한 설정 파일 때문에 시작에 실패하는 경우이며, systemctl status과 journalctl -xeu을 해당 서비스에 실행하면 허용되지 않는 줄을 알려줍니다. 디스크가 꽉 찬 경우도 있는데, 주로 오래된 커널로 인한 /boot나 apt 패키지 캐시로 인한 /var이며 df -h / /boot /var로 확인할 수 있습니다. sudo apt clean는 apt가 멈춘 상태에서도 캐시를 비워주며, du 명령어로는 여유 공간이 있는데 디스크가 꽉 찼다고 나오는 경우에 대한 별도의 설명이 있습니다. 업그레이더가 비활성화한 타사 저장소의 패키지가 26.04에서 더 이상 제공하지 않는 라이브러리에 의존하는 경우도 있습니다. 고정된 패키지(apt-mark showhold)가 의존성 업데이트를 막았을 수도 있습니다. 원인을 해결한 후 sudo dpkg --configure -a을 다시 실행하십시오. 중단된 지점부터 다시 시작합니다.

어떤 방법을 써도 패키지 하나가 설정을 거부하고, 중요한 서비스가 그 패키지에 의존하지 않는다면, 해당 패키지를 삭제한 뒤 업그레이드가 완료되면 다시 설치하십시오.

sudo dpkg --remove --force-remove-reinstreq package-name
sudo dpkg --configure -a

이 명령어는 이름과 이유를 명확히 아는 패키지에만 사용하십시오. 라이브러리나 ubuntu-server 의존성 체인에 있는 패키지에는 절대 사용하지 마십시오. 강제 삭제는 다른 패키지가 깨질 수 있는지 확인하는 검사를 건너뛰기 때문입니다.

소스는 변경되었으나 패키지는 업데이트되지 않은 경우

업그레이드 도구는 패키지를 다운로드하기 전, 초기 단계에서 apt 소스 파일을 다시 작성합니다. 이 시점에 작업이 중단되면 소스 파일은 26.04를 가리키지만 설치된 패키지는 혼재된 상태가 됩니다. 이러한 혼재는 도구들의 동작을 방해하며, do-release-upgrade가 새로운 릴리스가 없다고 판단하는 원인이 됩니다.

현재 어떤 릴리스를 사용 중인지 정의하는 두 위치를 비교하십시오. /etc/apt/sources.list.d/ubuntu.sources은 24.04에서 도입된 deb822 형식의 소스 파일이며, Suites: 항목에 릴리스 코드명이 명시되어 있습니다. /etc/os-release는 base-files 패키지에 의해 작성되며, 실제로 설치된 릴리스 정보를 담고 있습니다.

grep -E '^(Suites|Components):' /etc/apt/sources.list.d/ubuntu.sources
grep -E '^(VERSION_ID|VERSION_CODENAME)=' /etc/os-release
apt-cache policy base-files

다음 세 가지 조합을 확인해야 합니다. 소스 파일이 여전히 24.04(코드명 noble)를 가리키고 os-release도 24.04인 경우, 업그레이드가 검사 단계를 통과하지 못한 상태입니다. main.log을 읽고 중단 원인을 파악한 뒤 sudo do-release-upgrade를 다시 실행하십시오. 소스 파일은 26.04 코드명을 가리키는데 os-release는 여전히 24.04인 경우, 패키지 교체가 시작되었다가 중단된 상태입니다. 이전 섹션의 dpkg 복구 절차를 수행하고 apt full-upgrade로 마무리하여 작업을 완료하십시오. 소스 파일과 os-release 모두 26.04를 가리키는 경우, base-files 패키지가 이미 업데이트되어 시스템이 스스로를 26.04로 인식하고 있는 상태입니다. 실제로는 대부분의 패키지가 이전 버전이라 하더라도 시스템은 그렇게 판단합니다.

마지막 조합이 함정입니다. do-release-upgrade는 os-release에 담긴 정보를 바탕으로 현재 릴리스를 결정합니다. 만약 os-release가 이미 26.04라면, 도구는 26.04보다 최신 버전을 찾으려 시도하고, 결과가 없으므로 새로운 릴리스가 없다고 보고합니다. 도구는 os-release에 대한 질문에 답하고 있을 뿐이며, os-release의 정보가 잘못된 것입니다. 업그레이드 도구 사용을 중단하고 apt를 사용하여 마무리하십시오. sudo apt update을 실행한 뒤, 24.04 버전에 머물러 있는 모든 패키지를 업그레이드하는 sudo apt full-upgrade을 수행하고, 마지막으로 sudo apt autoremove를 실행하십시오. os-release가 여전히 24.04를 가리키고 있다면, do-release-upgrade가 새로운 릴리스가 없다고 보고하는 다른 이유들 (예: 첫 번째 포인트 릴리스를 기다리는 LTS 설정 등)을 먼저 확인해 보아야 합니다.

업그레이드 도구는 /etc/apt/sources.list.d/ 하위의 타사 소스들을 비활성화하며, 변경된 각 파일의 원본을 백업하고 파일명 뒤에 접미사를 추가합니다. ls -la /etc/apt/sources.list.d/를 실행하고 diff를 사용하여 각 원본 파일과 백업 파일을 비교하면 도구가 수행한 작업을 정확히 파악할 수 있습니다. Ubuntu 패키지 상태가 일관될 때까지 타사 소스 항목은 비활성화 상태로 두십시오. 이후 각 공급업체가 26.04용 패키지를 제공하는지 확인한 뒤에 하나씩 다시 활성화하십시오. 만약 apt update이 소스가 중복 설정되었다고 경고한다면, 기존의 sources.list 항목과 새로운 ubuntu.sources 항목이 동일한 제품군을 가리키고 있는 경우입니다. deb822 중복 소스 오류 문서를 참조하여 어떤 항목을 제거해야 할지 확인하십시오.

업그레이드 후 서버가 부팅되지 않음

재부팅은 미완성된 업그레이드의 대가를 치르는 시점입니다. VPS에서 발생할 수 있는 주요 원인으로는 initramfs 없이 설치된 커널, 재생성되지 않은 GRUB 설정, 부팅 시점 유닛이 의존하는 패키지의 설정 미완료, 또는 dpkg가 쓰기 작업을 수행하는 도중 디스크 용량이 가득 찬 경우 등이 있습니다.

다른 작업을 수행하기 전에 제공업체의 콘솔을 여십시오. 부팅이 멈추는 지점을 확인할 수 있습니다. GRUB 메뉴, 커널 패닉, 파일 시스템 검사 대기 상태, 또는 root 암호를 요구하는 systemd 긴급 셸 중 어디에서 멈추는지 확인하십시오. 이 관찰 결과가 다음 단계를 결정합니다.

GRUB이 나타나면 고급 옵션 하위 메뉴에서 이전 24.04 커널로 부팅하십시오. 이전 커널은 일반적으로 autoremove가 실행되기 전까지 설치된 상태로 유지됩니다. 이전 커널로 시스템이 정상 부팅되면 sudo dpkg --configure -a을 실행하고 위 섹션의 나머지 복구 작업을 수행한 뒤, 새 커널을 다시 시도하기 전에 sudo update-initramfs -u -k all 및 sudo update-grub를 실행하십시오. 커널 업데이트 후 부팅에 실패한 VPS 복구하기에서 GRUB 및 initramfs 관련 내용을 자세히 다룹니다.

긴급 셸로 진입한 경우, 루트 파일 시스템은 보통 읽기 전용으로 마운트되어 있습니다. 이를 다시 마운트하고 동일한 복구 작업을 수행하십시오.

mount -o remount,rw /
dpkg --configure -a

시스템이 셸에 전혀 도달하지 못하면 제공업체의 구조용 이미지(rescue image)로 부팅하여 VPS 디스크를 마운트한 뒤 chroot 환경에서 복구하십시오. 루트 파티션 이름은 추측하지 말고 lsblk을 사용하여 찾으십시오.

lsblk
mount /dev/<root-partition> /mnt
for d in dev proc sys run; do mount --bind /$d /mnt/$d; done
chroot /mnt /bin/bash
dpkg --configure -a
apt --fix-broken install
update-initramfs -u -k all
update-grub
exit
reboot

chroot 환경에서 한 시간을 보내기 전에 스냅샷 복구와 비교해 보십시오. 작업을 시작하기 전에 스냅샷을 생성했다면, 대부분의 제공업체에서 복구하는 데 몇 분밖에 걸리지 않습니다. 그 후 업그레이드를 다시 실행하면 VPS에서는 한 시간 이내에 완료되며, 이번에는 어떤 패키지를 미리 수정해야 할지 알 수 있습니다. 다음 중 하나라도 해당한다면 복구가 더 빠른 길입니다: 콘솔이나 구조용 이미지에 접근할 수 없는 경우, 업그레이드를 중단시킨 패키지를 특정할 수 없는 경우, 여러 패키지가 멈춘 경우, 또는 해당 서버가 사용자들이 기다리는 서비스를 운영 중인 경우. 수동 패치는 무엇이 문제인지 정확히 알고 있고 수정 방법이 단일 명령어로 해결될 때만 더 빠른 방법입니다.

복구하기 전에 /var/log/dist-upgrade/를 서버 밖으로 복사해 두십시오. 구조용 이미지를 통해서만 접근 가능하다면 그곳에서 복사하십시오. 복구 시 해당 로그는 삭제되며, 첫 번째 시도가 왜 실패했는지 배우지 못하면 두 번째 시도도 똑같이 실패합니다. 스냅샷으로 복구할 수 있는 것과 없는 것은 스냅샷에 의존하기 전에 읽어볼 가치가 있습니다. 스냅샷은 생성 시점 이후 기록된 모든 데이터를 포함하여 디스크 전체를 되돌립니다. 업그레이드 도중에는 괜찮지만, 일주일이 지난 시점이라면 문제가 될 수 있습니다.

시스템을 재구축해야 하는 세 가지 징후

일부 업그레이드는 복구할 가치가 없습니다. 스냅샷을 복원하고 다시 실행하는 것은 비용이 적게 들지만, 실패 원인이 서버 자체의 상태에 있다면 두 번째 시도 역시 실패합니다. 이 경우 정직한 해결책은 26.04 이미지를 새로 설치하고 백업에서 데이터를 복원하는 것입니다. 다음 세 가지 징후가 나타나면 재구축이 필요한 시점입니다.

첫째, dpkg 데이터베이스 자체가 손상된 경우입니다. dpkg --audit나 apt-get check이 내부의 깨진 패키지를 보고하는 수준을 넘어 /var/lib/dpkg/status을 아예 읽지 못한다면, 설치된 패키지에 대한 기록이 사라진 것입니다. Ubuntu는 /var/backups/(ls -la /var/backups/dpkg.status*)에 매일 복사본을 보관하므로, 가장 최근의 정상 복사본으로 교체하면 해결될 때가 있습니다. 하지만 해당 복사본조차 실제 디스크 상태와 일치하지 않는다면 추측에 의존하게 되며, 이후 실행되는 모든 apt 작업은 그 추측을 바탕으로 수행됩니다.

둘째, 시스템 복구에 필요한 도구 자체가 고장 난 경우입니다. 공유 라이브러리가 삭제되거나 절반만 교체되어 apt이나 dpkg이 실행되지 않거나, 패키지 자체가 제대로 설정되지 않아 systemd가 유닛을 시작할 수 없는 상황이라면 패키지 관리자를 고칠 수 있는 도구가 남아 있지 않은 것입니다. ldd /usr/bin/apt을 사용하면 apt 라이브러리가 모두 존재하는지 확인할 수 있습니다. 복구 이미지의 chroot 환경에서 부트스트랩을 시도해 볼 수는 있지만, 그에 소요되는 시간은 보통 재구축보다 깁니다.

셋째, 깨진 패키지 목록이 줄어들지 않는 경우입니다. dpkg --configure -a와 apt --fix-broken install를 한 시간 이상 반복 실행했음에도 이전 문제를 해결하기는커녕 매번 새로운 패키지 오류가 나타난다면, 시스템은 업그레이드 이전부터 문제를 안고 있었던 것입니다. 예를 들어 /usr 하위 파일을 직접 수정했거나, 패키지를 고정(pinning) 또는 보류(hold)했거나, 제3자 저장소가 핵심 라이브러리를 교체했거나, 이전 업그레이드가 완료되지 않은 경우 등이 해당합니다. 새로 설치한 이미지에는 이러한 문제가 없으며, 데이터를 새로 설치된 시스템으로 옮기는 것이 원인을 찾는 것보다 시간이 적게 듭니다.

재구축은 데이터가 서버 외부의 다른 곳에 저장되어 있을 때만 효율적입니다. 이것이 스냅샷과 백업의 차이이며, 업그레이드 가이드에서 두 가지 모두를 요구하는 이유입니다.

FAQ

중단된 뒤에 do-release-upgrade를 다시 실행해도 됩니까?

네, 가장 먼저 시도해야 할 최선의 방법입니다. 업그레이드 도구가 screen 세션에서 여전히 실행 중이라면, 다시 실행할 때 해당 세션에 재연결됩니다. 그렇지 않다면 먼저 sudo dpkg --configure -a과 sudo apt --fix-broken install을 실행한 뒤 업그레이드 도구를 다시 시작하십시오. 도구가 현재 상태를 다시 읽고 작업을 이어갑니다. 단, /etc/os-release가 이미 26.04라고 출력하는 경우에는 업그레이드가 완료된 것으로 간주하므로 이 방법이 통하지 않습니다. 대신 sudo apt full-upgrade으로 마무리하십시오.

업그레이드 실패 후 do-release-upgrade가 새 릴리스가 없다고 하는 이유는 무엇입니까?

/etc/os-release 파일을 작성하는 패키지인 base-files이 중단 이전에 이미 업그레이드되었기 때문입니다. 도구가 해당 파일을 읽고 사용자가 이미 26.04 버전을 사용 중이라고 판단하여 더 최신 버전을 제안하지 않는 것입니다. grep VERSION_ID /etc/os-release과 grep Suites /etc/apt/sources.list.d/ubuntu.sources를 비교한 뒤 sudo apt update && sudo apt full-upgrade로 마무리하십시오.

업그레이드가 완료되지 않은 Ubuntu 서버를 재부팅해도 안전합니까?

sudo dpkg --audit이 아무것도 반환하지 않을 때까지는 안전하지 않습니다. 커널은 압축 해제되었으나 설정되지 않았거나 GRUB이 재생성되지 않은 상태에서 재부팅하는 것은, 10분이면 해결할 수 있었던 업그레이드 문제를 복구 이미지 작업이 필요한 상황으로 만드는 가장 흔한 원인입니다. dpkg 복구와 apt full-upgrade을 완료하고, update-initramfs -u -k all과 update-grub를 실행한 뒤에 재부팅하십시오.

어떤 패키지 때문에 업그레이드가 중단되었는지 어떻게 확인합니까?

dpkg의 터미널 출력이 기록된 /var/log/dist-upgrade/apt-term.log의 마지막 부분을 확인하십시오. 로그가 끝나는 지점 바로 앞에 명시된 패키지가 실행 중이던 것이며, 메인테이너 스크립트 오류가 발생했다면 dpkg의 오류 메시지 바로 위에 해당 내용이 출력됩니다. tail -n 30 /var/log/dpkg.log을 통해 다른 소스에서 이를 확인할 수 있습니다. 만약 main.log가 Python 트레이스백으로 끝난다면 업그레이드 도구 자체가 충돌한 것이며, 특정 패키지의 잘못이 아닙니다.

스냅샷을 복구해야 합니까, 아니면 계속 수정해야 합니까?

실패한 패키지를 특정할 수 없거나, 여러 패키지가 멈췄거나, 콘솔 접근이 불가능하거나, 서버를 빠르게 정상화해야 할 때는 스냅샷을 복구하십시오. 무엇이 문제인지 정확히 알고 있고 단일 명령어로 해결 가능한 경우에만 수정을 계속하십시오. 복구하기 전에 /var/log/dist-upgrade/을 서버 외부로 복사해 두십시오. 그렇지 않으면 두 번째 시도에서도 동일한 이유로 실패하게 됩니다.