가이드

작성자 Matt Connor 2026-08-13 · 업데이트됨 2026-08-14

Ubuntu do-release-upgrade 새 릴리스 없음 해결 방법

Q: Ubuntu 24.04에서 do-release-upgrade가 새 릴리스를 찾지 못하는 이유는 무엇입니까?

Prompt=lts의 기본 설정이 /etc/update-manager/release-upgrades에 적용되어 있어 도구가 https://changelogs.ubuntu.com/meta-release-lts를 읽습니다. Ubuntu 26.04는 첫 번째 포인트 릴리스가 나올 때까지 해당 파일에 Supported: 0을 유지합니다. 업그레이드 도구는 사용 가능한 더 최신 LTS 릴리스를 찾지 못하면 작업을 중단합니다. curl -s https://changelogs.ubuntu.com/meta-release-lts 명령으로 파일을 직접 확인하고 마지막 블록을 읽어 보십시오. 2026년 8월 13일 확인 결과, 해당 플래그는 여전히 0였으며 Ubuntu 26.04.1은 2026년 8월 27일로 예정되어 있었습니다.

Q: 포인트 릴리스를 기다리지 않고 Prompt=normal로 설정해도 안전합니까?

이 설정은 개발 빌드가 아닌 정식 릴리스된 26.04로 업그레이드합니다. Prompt=normal이 meta-release를 읽는데, 이곳에는 이미 26.04가 Supported: 1로 명시되어 있기 때문입니다. 위험 요소는 시점입니다. 초기 업그레이드 사용자들이 발견한 차단 문제들이 해결되기 전에 진행하는 셈입니다. 스냅샷에서 복구할 수 있고 재부팅 실패 시 제공자의 콘솔에 접근할 수 있는 서버에서 수행하십시오. 작업 후에는 값을 다시 lts으로 되돌리십시오.

Q: -d 플래그를 사용하면 26.04로 업그레이드됩니까?

아니요. -d은 meta-release-development을 읽는데, 2026년 8월 13일 기준 최신 항목은 개발 중인 릴리스인 Ubuntu 26.10이었습니다. Prompt=lts가 설정된 LTS 시스템에서 이 플래그를 사용하면 There is no development version of an LTS available.이 출력되고 중단됩니다. Ubuntu 공식 서버 문서에서도 개발 릴리스는 운영 환경에 권장하지 않는다고 명시하므로, 26.04 정식 릴리스를 미리 사용하려면 Prompt=normal을 사용하십시오.

Q: 오래된 릴리스에서 apt update 실행 시 404 오류가 발생합니다. 어떻게 업그레이드합니까?

해당 릴리스는 수명이 종료되어 패키지가 archive.ubuntu.com에서 old-releases.ubuntu.com으로 이동되었습니다. /etc/apt/sources.list.d/ubuntu.sources(구형 레이아웃의 경우 /etc/apt/sources.list)에서 호스트 이름만 변경하고 코드네임은 그대로 유지하십시오. 그 후 sudo apt update과 sudo apt full-upgrade을 실행하십시오. 시스템이 최신 상태가 되면 do-release-upgrade을 사용하여 한 번에 한 릴리스씩 업그레이드할 수 있습니다.

do-release-upgrade 실행 시 no new release found 오류가 발생하는 원인을 분석합니다. Prompt 설정, LTS 포인트 릴리스 제한, 타사 저장소 및 보류 패키지 등 서버 환경별 해결책을 단계별로 안내합니다.

왜 do-release-upgrade에서 새 릴리스를 찾을 수 없다고 하는가

do-release-upgrade가 No new release found.으로 끝나는 현상은 도구 자체가 고장 난 경우가 거의 없습니다. 요청하신 경로가 해당 시점에 닫혀 있으며, 도구는 이를 가장 간결한 방식으로 보고하는 것뿐입니다. 이 경로를 닫는 원인은 다음 다섯 가지입니다: /etc/update-manager/release-upgrades의 Prompt 설정, LTS(long term support) 업그레이드 시 포인트 릴리스 제한, 타사 저장소, 보류 중이거나 절반만 구성된 패키지, 그리고 지원이 종료된 릴리스입니다.

이 순서대로 확인하십시오. 각 항목에는 해당 원인이 서버에 적용되는지 증명하는 명령어가 있으므로, 다섯 가지 중 무엇이 문제인지 추측할 필요가 없습니다.

check-only 플래그가 실제로 보고하는 내용

sudo do-release-upgrade -c
echo $?

-c은 확인 전용 모드입니다. 이 플래그는 HTTPS(hypertext transfer protocol secure)를 통해 Canonical의 릴리스 메타데이터를 읽고 결과를 출력합니다. 업그레이드 도구를 다운로드하거나 소스 파일을 수정하지 않습니다. 다음 두 가지 출력 결과가 중요합니다.

Checking for a new Ubuntu release
No new release found.

Checking for a new Ubuntu release
New release '26.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

종료 코드는 스크립트 작성을 위한 동일한 답변을 제공합니다. 릴리스가 있으면 0을 반환하고, 없으면 1을 반환합니다. 이는 일반적인 셸 관례와 반대이므로, 이를 기반으로 스크립트를 작성하기 전에 주의 깊게 확인하십시오.

로그인 배너에 여전히 이전 결과가 표시된다면 캐시된 것입니다. 해당 줄은 /etc/update-motd.d/91-release-upgrade에서 출력하며, 네트워크에 질의하는 대신 저장된 결과를 보여줍니다. sudo /usr/lib/ubuntu-release-upgrader/release-upgrade-motd을 실행하여 갱신하거나, -c의 결과를 신뢰하십시오. 배너는 마지막으로 실행된 확인 결과만 반복해서 보여줍니다.

또한 이 확인 작업은 changelogs.ubuntu.com에 도달할 수 있어야 합니다. 엄격한 아웃바운드 방화벽이나 프록시 뒤에 있는 서버에서는 도구가 질의를 수행할 수 없으므로 아무것도 찾을 수 없습니다.

curl -sI https://changelogs.ubuntu.com/meta-release-lts | head -n 1

HTTP/2 200 줄이 나타나면 서버가 메타데이터를 확인할 수 있다는 의미입니다. curl: (28) Connection timed out가 나타나면 송신(egress) 규칙이 실제 원인이며, APT(advanced package tool) 파일을 아무리 수정해도 결과는 바뀌지 않습니다.

명령어 자체가 없다면 ubuntu-release-upgrader-core 패키지에 포함되어 있습니다. 최소 사양의 클라우드 이미지에는 해당 패키지가 누락된 경우가 있습니다.

sudo apt install ubuntu-release-upgrader-core

변경 전 /etc/update-manager/release-upgrades 읽기

cat /etc/update-manager/release-upgrades

[DEFAULT]
Prompt=lts

이 파일은 주석 내부에 자체 문서를 포함하고 있습니다. 다음 세 가지 값이 유효합니다.

never: 새 릴리스로의 업그레이드를 확인하거나 허용하지 않습니다.
normal: 현재 실행 중인 릴리스 바로 다음의 지원되는 릴리스를 제안합니다.
lts: 현재 실행 중인 릴리스 다음의 첫 번째 LTS 릴리스를 제안합니다.

Prompt=never는 세 가지 설정 중 진단하기 가장 쉽습니다. 도구가 출력 결과에 파일명과 설정값을 모두 명시하기 때문입니다.

Checking for a new Ubuntu release
In /etc/update-manager/release-upgrades Prompt is set to never so upgrading is not possible.

호스팅 제공업체와 구성 관리 도구는 서버군이 릴리스 사이에서 의도치 않게 변경되는 것을 막기 위해 never을 의도적으로 설정합니다. 해당 설정이 있다면 누군가 이를 선택한 것입니다. 장기 지원(LTS) 트랙을 유지하려는 서버라면 lts로 변경하십시오. 자동화 도구가 이전 값을 요구한다면 작업 후 다시 원래대로 되돌려야 합니다.

주석에 있는 한 가지 세부 사항이 사용자를 혼란스럽게 할 수 있습니다. Prompt=lts가 설정되어 있고 현재 실행 중인 릴리스가 LTS 릴리스가 아닐 경우, 업그레이드 도구는 이 설정을 normal으로 간주합니다. 25.10 버전 머신에서는 두 값이 동일하게 동작합니다. 하지만 24.04 버전 머신에서는 그렇지 않으며, 그 차이가 바로 다음 섹션의 핵심 내용입니다.

LTS에서 LTS로의 업그레이드가 첫 번째 포인트 릴리스를 기다리는 이유

Prompt는 업그레이드 도구가 어떤 메타데이터 파일을 읽을지 결정합니다. 해당 주소는 /etc/update-manager/meta-release에 위치합니다:

[METARELEASE]
URI = https://changelogs.ubuntu.com/meta-release
URI_LTS = https://changelogs.ubuntu.com/meta-release-lts
URI_UNSTABLE_POSTFIX = -development
URI_PROPOSED_POSTFIX = -proposed

Prompt=lts은 meta-release-lts을 읽습니다. Prompt=normal은 meta-release를 읽습니다. 두 파일 모두 각 릴리스를 작은 키 블록으로 설명하며, 업그레이드 도구는 해당 릴리스의 Supported: 플래그가 1일 때만 업그레이드를 제안합니다. 동일한 서버에서 직접 파일을 확인해 보십시오:

curl -s https://changelogs.ubuntu.com/meta-release-lts | grep -A 4 resolute
curl -s https://changelogs.ubuntu.com/meta-release | grep -A 4 resolute

2026년 8월 13일 확인 결과, 두 파일은 Ubuntu 26.04에 대해 서로 다른 정보를 담고 있습니다. LTS 파일의 내용은 다음과 같습니다:

Dist: resolute
Name: Resolute Raccoon
Version: 26.04 LTS
Date: Thu, 23 April 2026 00:26:04 UTC
Supported: 0

일반 파일의 내용은 다음과 같습니다:

Dist: resolute
Name: Resolute Raccoon
Version: 26.04 LTS
Date: Thu, 23 April 2026 00:26:04 UTC
Supported: 1

LTS 파일에 있는 Supported: 0가 바로 관문 역할을 합니다. 기본값인 Prompt=lts을 사용하는 24.04 서버는 해당 파일을 읽은 뒤, 사용 가능으로 표시된 더 최신 LTS 릴리스가 없음을 확인하고 No new release found.를 출력합니다. 시스템에 문제가 있는 것은 아닙니다. Canonical이 아직 경로를 열지 않았기 때문입니다.

이 플래그는 첫 번째 포인트 릴리스가 출시되면 1로 변경됩니다. Ubuntu 26.04.1은 2026년 8월 27일로 예정되어 있으나 릴리스 일정은 변경될 수 있으므로, 달력이 아닌 메타데이터를 확인해야 합니다. 이러한 지연은 의도된 것입니다. 초기에 업그레이드를 수행하는 사용자들이 차단 문제를 발견하면, 더 많은 수의 LTS 서버 사용자들이 업그레이드하기 전에 해당 문제들이 수정됩니다.

따라서 두 가지 합리적인 선택지가 있습니다. 첫 번째는 포인트 릴리스를 기다리는 것으로, 직접 관리하고 싶지 않은 모든 서버에 권장되는 방식입니다. 두 번째는 Prompt=normal을 설정하는 것입니다. 이 설정은 동일한 도구가 meta-release을 참조하게 하며, 이곳에서는 26.04가 이미 지원되는 것으로 표시되어 있습니다. 두 번째 방법은 개발 빌드가 아닌 정식 출시된 26.04로 업그레이드하므로, 스냅샷에서 복구 가능한 서버라면 충분히 시도해 볼 만합니다. 작업이 완료되면 값을 다시 lts로 되돌리십시오. 단계별 절차는 전체 24.04에서 26.04 서버 업그레이드 가이드에서 확인할 수 있습니다.

업그레이드를 차단하는 타사 저장소 및 PPA

업그레이드 도구는 새로운 릴리스를 가리키도록 APT 소스 설정을 다시 작성합니다. 이 작업은 새로운 릴리스용으로 게시된 저장소에 대해서만 가능하므로, 그 외의 모든 저장소는 주석 처리됩니다. 그 이유는 항목당 한 줄씩 출력되며, 구체적으로는 was disabled (unknown mirror), was disabled (unknown dist), was disabled (no Release file) 등이 있습니다.

noble용으로 빌드된 PPA(개인 패키지 아카이브)는 서버에 resolute용 디렉터리가 없으므로, 업그레이드 도구가 새 시리즈를 위한 Release 파일을 가져올 수 없어 해당 항목을 비활성화합니다. 이는 일반적으로 수용 가능한 경고입니다. 하지만 타사 저장소가 새 릴리스에서도 제공하는 패키지를 공급하는 경우, 업그레이드 계산 과정에서 두 개의 후보가 발생하여 둘 다 만족시킬 수 없게 되므로 업그레이드가 중단됩니다.

도구가 긴 시간 동안 자동으로 실행되는 과정에서 판단하게 두지 말고, 시작하기 전에 직접 결정하십시오.

ls /etc/apt/sources.list.d/
apt policy nginx
sudo add-apt-repository --remove ppa:example/ppa

패키지 이름에 apt policy를 사용하면 설치된 각 버전이 어느 저장소에서 왔는지 출력되므로, 비활성화하려는 소스에 어떤 패키지가 의존하는지 정확히 확인할 수 있습니다. 소스를 제거한다고 해서 패키지가 다운그레이드되지는 않으므로, PPA에서 설치된 패키지는 PPA 버전을 유지하며 새 릴리스의 패키지보다 최신 버전일 수 있습니다. 이것이 문제가 되는 경우 해당 패키지를 함께 제거하고, 업그레이드 후 아카이브에서 다시 설치하십시오. Tailscale과 같이 다시 추가할 예정인 저장소는 패키지를 다시 설치하기 전에 코드네임을 새 릴리스로 업데이트해야 하며, Ubuntu에서 발생하는 대부분의 Tailscale 설치 오류는 이 과정에서 비롯됩니다.

반대 선택을 위한 플래그도 존재합니다. 매뉴얼 페이지에서는 --allow-third-party을 "타사 미러 및 저장소를 주석 처리하지 않고 활성화한 상태로 업그레이드를 시도합니다"라고 설명합니다. 이 옵션은 해당 저장소가 이미 대상 릴리스용으로 게시되었음을 확인했을 때만 사용하십시오. 그렇지 않은 경우, 해당 저장소가 빌드된 적 없는 시리즈를 대상으로 의존성 그래프를 해결하도록 APT에 지시하는 꼴이 됩니다.

Ubuntu 24.04 이상에서는 대부분의 소스가 /etc/apt/sources.list.d/ubuntu.sources에 deb822 형식으로 존재합니다. 동일한 저장소가 구형 형식과 신형 형식으로 모두 작성된 경우 별도의 오류로 간주되며, 이에 대한 메시지는 deb822 형식의 중복 소스 항목 오류에서 다룹니다.

보류 및 구성 미완료 패키지가 계산을 중단시킴

릴리스 업그레이드는 시스템의 거의 모든 패키지를 이동시켜야 합니다. 패키지 하나라도 이동할 수 없으면 계산이 실패하며, 업그레이드 도구는 시스템을 중간 상태로 두기보다는 차라리 일찍 중단하는 방식을 택합니다. 원인을 찾으려면 다음 두 명령어를 사용하십시오.

apt-mark showhold
sudo dpkg --audit

apt-mark showhold은 보류된 패키지를 한 줄에 하나씩 출력하며, 깨끗한 시스템에서는 아무것도 출력하지 않습니다. 보류(hold)는 해당 패키지를 절대 변경하지 말라는 수동 지침입니다. 누군가 커널이나 데이터베이스 버전을 고정해두고 잊어버린 경우입니다. 더 이상 필요하지 않은 패키지는 sudo apt-mark unhold 뒤에 패키지 이름을 붙여 해제하십시오.

dpkg --audit은 압축은 풀렸으나 구성되지 않은 패키지 목록을 보여줍니다. 이 상태는 주로 세션 연결이 끊기는 등의 이유로 설치가 중단되었을 때 발생합니다. 업그레이드 도구는 이를 복구하려고 시도하며 dpkg interrupted, calling dpkg --configure -a을 출력하지만, 직접 복구를 실행하면 오류 메시지가 지나가는 것을 지켜보는 대신 내용을 미리 읽을 수 있습니다. 도구가 복구할 수 없는 패키지는 Package in inconsistent state 메시지를 생성하며, 이 패키지는 재시도 전에 반드시 조치가 필요합니다.

업그레이드하기 전에 현재 실행 중인 릴리스를 완전히 최신 상태로 만드십시오.

sudo apt update
sudo apt full-upgrade -o APT::Get::Always-Include-Phased-Updates=true
sudo apt --fix-broken install
sudo dpkg --configure -a
sudo reboot

단계적 업데이트(phased updates) 옵션은 보이는 것보다 중요합니다. Ubuntu는 일부 업데이트를 한 번에 일정 비율의 기기에만 배포하므로, 일반적인 apt upgrade만으로는 패키지가 의도치 않게 누락될 수 있으며, 이 경우 서버는 생각보다 최신 상태가 아닐 수 있습니다. 해당 옵션을 사용하면 모든 업데이트를 가져옵니다. 커널 업데이트가 포함된 경우 재부팅하여 현재 실행 중인 커널에서 업그레이드를 진행하십시오. 무인 보안 업그레이드를 통해 이미 패치를 유지하는 서버는 여기서 할 일이 적지만, 해당 메커니즘은 설계상 릴리스 경계를 넘지 않습니다.

표준 지원 기간이 종료된 릴리스를 다룰 때

중간(interim) Ubuntu 릴리스는 9개월 동안 지원됩니다. 지원이 종료되면 해당 릴리스의 Supported: 플래그는 0로 변경되며, 일반적인 경로로는 업그레이드를 제공하지 않습니다. 2026년 8월 13일 기준으로 확인한 결과, meta-release은 25.10 버전에 대해 다음과 같이 명시합니다.

Dist: questing
Name: Questing Quokka
Version: 25.10
Date: Thu, 09 October 2025 00:25:10 UTC
Supported: 0

이와 동시에 아카이브도 이동합니다. 수명이 다한 릴리스의 패키지는 archive.ubuntu.com에서 제거되고 old-releases.ubuntu.com로 옮겨집니다. 따라서 apt update는 404 Not Found을 반환하기 시작하며, 시스템을 최신 상태로 유지할 수 없게 됩니다. 업그레이드 도구는 시스템이 최신 상태일 것을 요구하므로 어떠한 작업도 진행되지 않습니다. 먼저 소스 설정을 수정해야 합니다.

lsb_release -cs
grep -rn ubuntu.com /etc/apt/sources.list /etc/apt/sources.list.d/

archive.ubuntu.com와 security.ubuntu.com 모두 old-releases.ubuntu.com을 가리키도록 수정하고, 코드네임은 그대로 둡니다. 호스트 이름만 변경됩니다.

sudo sed -i.bak -e 's/archive.ubuntu.com/old-releases.ubuntu.com/g' \
                -e 's/security.ubuntu.com/old-releases.ubuntu.com/g' \
                /etc/apt/sources.list.d/ubuntu.sources
sudo apt update

서버의 소스가 여전히 단일 파일에 보관되어 있다면 /etc/apt/sources.list를 대상으로 동일한 명령을 실행하십시오. -i.bak 옵션은 원본 옆에 백업 파일을 생성하므로, 잘못된 파일을 수정했을 경우 되돌릴 수 있습니다. 이후 apt update을 실행하여 오류가 없으면 아카이브에 다시 접근할 수 있게 된 것이며, do-release-upgrade도 정상적으로 응답할 것입니다.

이 방법으로 어느 정도까지 해결할 수 있을지 현실적으로 판단해야 합니다. Ubuntu는 한 번에 한 단계씩의 릴리스 업그레이드만 지원하므로, 지원이 종료된 릴리스를 두세 단계 건너뛰어야 하는 서버는 각 단계를 순차적으로 거쳐야 합니다. 각 단계마다 서드 파티 저장소나 보류된 패키지로 인해 실패할 가능성이 있습니다. VPS 환경에서는 현재 LTS 버전으로 새 서버를 구축하고 서비스를 이전한 뒤, 확실해질 때까지 기존 서버를 유지하는 편이 더 빠를 때가 많습니다. 또한 이 방식은 제자리 업그레이드에서는 불가능한 롤백을 보장합니다. 이후 어떤 릴리스 트랙을 선택할지 고민 중이라면, 결정을 내리기 전에 서버 환경에서 LTS와 중간 릴리스의 차이점을 읽어보는 것이 좋습니다.

개발 릴리스 플래그의 실제 동작

-d 또는 --devel-release 플래그를 사용하면 업그레이드 도구가 Prompt가 선택한 파일 대신 meta-release-development 파일을 읽습니다. 매뉴얼 페이지에는 이를 "최신 지원 릴리스를 사용하는 경우 개발 릴리스로 업그레이드한다"라고 설명합니다.

2026년 8월 13일 확인 결과, 해당 파일의 최신 항목은 26.04가 아닙니다.

Dist: stonking
Name: Stonking Stingray
Version: 26.10
Date: Thu, 15 October 2026 00:26:10 UTC
Supported: 0

따라서 -d를 사용해도 24.04 서버가 정식 릴리스된 26.04로 업그레이드되지 않습니다. 이 플래그는 아직 개발 중인 26.10 릴리스를 대상으로 합니다. "그저 -d을 추가하라"는 과거의 조언은 LTS가 출시되기 전 특정 기간에 작성된 것이며, 지금 이를 그대로 따라 하면 의도치 않은 버전으로 서버가 업데이트될 수 있습니다. Prompt=lts가 설정된 상태에서 이 플래그를 사용하면 다음과 같은 메시지가 출력되며 중단됩니다.

There is no development version of an LTS available.

Ubuntu 서버 문서에서는 이 플래그에 대해 "개발 릴리스(또는 -d 플래그)를 사용하는 것은 운영 환경에 권장하지 않는다"라고 명시합니다. 개발 릴리스는 매일 변경되며 보안 지원을 보장하지 않으므로, 오전에 정상 작동하던 패키지가 오후에는 서비스를 중단시킬 수 있습니다. 이 플래그는 오직 설정을 테스트하기 위해 만든 임시 가상 머신에서만 사용하십시오. 누군가 의존하고 있는 서버에는 절대 사용해서는 안 됩니다. LTS 출시 전 정식 26.04 버전을 원한다면 Prompt=normal을 사용하는 것이 올바른 방법입니다.

SSH 세션이 끊겨도 업그레이드가 중단되지 않게 실행하기

릴리스 업그레이드는 openssh-server 및 systemd을 포함하여 시스템의 대부분을 교체합니다. dpkg가 작업하는 도중 SSH(secure shell) 세션이 종료되면 프로세스가 강제 종료되면서 패키지가 압축 해제만 되고 설정은 완료되지 않은 상태가 됩니다. 이 상태는 다음 업그레이드 시도를 방해하는 원인이 됩니다. 항상 터미널 멀티플렉서 안에서 업그레이드를 시작하십시오.

sudo apt install -y tmux
tmux new -s upgrade
sudo do-release-upgrade

연결이 끊기면 다시 로그인한 뒤 tmux attach -t upgrade를 실행하십시오. 업그레이드는 SSH 세션이 아닌 tmux 서버의 자식 프로세스로 실행되므로 계속 진행됩니다. screen -S upgrade과 screen -r upgrade도 선호한다면 동일한 역할을 수행합니다.

업그레이드 도구는 멀티플렉서를 사용하지 않는 사용자를 위한 안전장치를 갖추고 있습니다. SSH 환경에서 실행 중임을 감지하면 포트 1022에서 두 번째 sshd를 시작할지 제안합니다. 이를 통해 메인 세션이 끊겨도 접속할 수 있는 경로를 확보할 수 있습니다. 도구는 자신의 부모 프로세스를 추적하여 sshd이라는 이름의 프로세스를 찾습니다. tmux나 screen 내부에서는 이 추적 과정에서 멀티플렉서 서버가 발견되므로 제안이 나타나지 않으며, pid 파일인 /var/run/release-upgrader-sshd.pid는 추가 데몬이 실제로 시작될 때만 생성됩니다. 프롬프트가 보이지 않는다고 해서 문제가 있는 것은 아닙니다. 이미 더 나은 보호 수단을 사용하고 있는 것입니다.

제안을 수락하더라도 포트가 자동으로 열리지는 않습니다. 포트를 여는 것은 보안과 관련된 결정이므로 도구가 사용자를 대신하여 수행할 권한이 없기 때문입니다. 업그레이드하는 동안만 포트를 열고 작업이 끝나면 다시 닫으십시오.

sudo ufw allow 1022/tcp
sudo ufw delete allow 1022/tcp

대부분의 VPS 제공업체는 운영체제 외부의 제어 패널에서 별도의 방화벽을 운영합니다. 해당 방화벽에서도 포트 1022를 열어야 합니다. 그렇지 않으면 폴백 리스너가 실행 중임에도 접근할 수 없게 되며, 이는 가장 좋지 않은 상황입니다.

명령어를 입력하기 전에 다음 네 가지를 확인하십시오.

스냅샷이나 전체 백업을 수행하십시오. 제자리 릴리스 업그레이드는 되돌릴 수 없으며, 이것이 유일한 복구 수단입니다.
필요할 때 제공업체의 콘솔에 접속할 수 있는지 확인하십시오. 재부팅 후 서버가 돌아오지 않으면 SSH를 사용할 수 없게 됩니다. 부팅에 실패한 커널은 별도의 문제이며, 커널 업데이트 후 부팅되지 않는 VPS에서 다루는 복구 단계를 따라야 합니다.
df -h / /boot로 여유 공간을 확인하십시오. 업그레이드는 전체 패키지 세트를 다운로드하며, 여러 개의 이전 커널이 쌓인 /boot 파티션에서 공간 부족으로 멈추는 경우가 흔합니다.
운영 중인 서비스의 릴리스 노트를 읽어보십시오. PostgreSQL이나 PHP의 메이저 버전 변경은 계획 여부와 관계없이 릴리스와 함께 적용됩니다.

FAQ

Ubuntu 24.04에서 do-release-upgrade가 새 릴리스를 찾지 못하는 이유는 무엇입니까?

Prompt=lts의 기본 설정이 /etc/update-manager/release-upgrades에 적용되어 있어 도구가 https://changelogs.ubuntu.com/meta-release-lts를 읽습니다. Ubuntu 26.04는 첫 번째 포인트 릴리스가 나올 때까지 해당 파일에 Supported: 0을 유지합니다. 업그레이드 도구는 사용 가능한 더 최신 LTS 릴리스를 찾지 못하면 작업을 중단합니다. curl -s https://changelogs.ubuntu.com/meta-release-lts 명령으로 파일을 직접 확인하고 마지막 블록을 읽어 보십시오. 2026년 8월 13일 확인 결과, 해당 플래그는 여전히 0였으며 Ubuntu 26.04.1은 2026년 8월 27일로 예정되어 있었습니다.

포인트 릴리스를 기다리지 않고 Prompt=normal로 설정해도 안전합니까?

이 설정은 개발 빌드가 아닌 정식 릴리스된 26.04로 업그레이드합니다. Prompt=normal이 meta-release를 읽는데, 이곳에는 이미 26.04가 Supported: 1로 명시되어 있기 때문입니다. 위험 요소는 시점입니다. 초기 업그레이드 사용자들이 발견한 차단 문제들이 해결되기 전에 진행하는 셈입니다. 스냅샷에서 복구할 수 있고 재부팅 실패 시 제공자의 콘솔에 접근할 수 있는 서버에서 수행하십시오. 작업 후에는 값을 다시 lts으로 되돌리십시오.

-d 플래그를 사용하면 26.04로 업그레이드됩니까?

아니요. -d은 meta-release-development을 읽는데, 2026년 8월 13일 기준 최신 항목은 개발 중인 릴리스인 Ubuntu 26.10이었습니다. Prompt=lts가 설정된 LTS 시스템에서 이 플래그를 사용하면 There is no development version of an LTS available.이 출력되고 중단됩니다. Ubuntu 공식 서버 문서에서도 개발 릴리스는 운영 환경에 권장하지 않는다고 명시하므로, 26.04 정식 릴리스를 미리 사용하려면 Prompt=normal을 사용하십시오.

오래된 릴리스에서 apt update 실행 시 404 오류가 발생합니다. 어떻게 업그레이드합니까?

해당 릴리스는 수명이 종료되어 패키지가 archive.ubuntu.com에서 old-releases.ubuntu.com으로 이동되었습니다. /etc/apt/sources.list.d/ubuntu.sources(구형 레이아웃의 경우 /etc/apt/sources.list)에서 호스트 이름만 변경하고 코드네임은 그대로 유지하십시오. 그 후 sudo apt update과 sudo apt full-upgrade을 실행하십시오. 시스템이 최신 상태가 되면 do-release-upgrade을 사용하여 한 번에 한 릴리스씩 업그레이드할 수 있습니다.

do-release-upgrade를 실행하기 전에 PPA를 제거해야 합니까?

그럴 필요는 없습니다. 업그레이드 도구가 새 릴리스용으로 게시되지 않은 모든 소스를 주석 처리하고 각 항목에 대해 was disabled (no Release file)와 같은 메시지를 출력하기 때문입니다. 하지만 직접 먼저 제거하는 것이 더 좋습니다. 순서를 직접 선택할 수 있고 결과를 확인할 수 있기 때문입니다. 관리하는 패키지에 대해 apt policy을 실행하여 각 PPA에서 온 패키지를 확인하고, PPA 버전이 새 릴리스의 기본 버전보다 최신인 경우 아카이브 버전으로 재설치하십시오.

#ubuntu#do-release-upgrade#apt #lts #troubleshooting