رفع خطای no new release found در do-release-upgrade

چرا دستور do-release-upgrade پیام no new release found را نمایش می‌دهد

do-release-upgrade این وضعیت که با No new release found. پایان می‌یابد، تقریباً هرگز به معنای خرابی ابزار نیست. مسیری که درخواست کرده‌اید در آن لحظه بسته است و ابزار این موضوع را به کوتاه‌ترین شکل ممکن گزارش می‌دهد. پنج عامل باعث بسته شدن این مسیر می‌شوند: تنظیم Prompt در فایل /etc/update-manager/release-upgrades، محدودیت انتشار نسخه‌های نقطه‌ای در ارتقای LTS (پشتیبانی بلندمدت)، مخازن شخص ثالث، بسته‌هایی که در وضعیت held یا نیمه‌پیکربندی‌شده هستند، و نسخه‌ای که دوره پشتیبانی آن به پایان رسیده است.

این موارد را به همین ترتیب بررسی کنید. برای هر مورد دستوری وجود دارد که مشخص می‌کند آیا آن عامل در سرور شما صدق می‌کند یا خیر، بنابراین هرگز نیازی به حدس زدن اینکه با کدام‌یک از این پنج مورد مواجه هستید، نخواهید داشت.

عملکرد واقعی فلگ check-only

sudo do-release-upgrade -c
echo $?

فلگ -c صرفاً برای بررسی است. این فلگ متادیتای انتشار Canonical را از طریق HTTPS (پروتکل انتقال ابرمتن امن) می‌خواند و نتیجه را چاپ می‌کند. هیچ ابزار ارتقایی دانلود نمی‌شود و هیچ فایل منبعی بازنویسی نخواهد شد. دو خروجی اهمیت دارند:

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.

کد خروج (exit code) نیز همین پاسخ را برای اسکریپت‌ها به همراه دارد. اگر نسخه‌ای موجود باشد، کد خروج 0 است و اگر نسخه‌ای موجود نباشد، 1 است. این رفتار برعکس قراردادهای معمول در shell است، بنابراین پیش از پیاده‌سازی هرگونه بررسی خودکار بر اساس آن، با دقت آن را مطالعه کنید.

اگر بنر ورود (login banner) همچنان نسخه قدیمی را نشان می‌دهد، به این دلیل است که در حافظه پنهان (cache) ذخیره شده است. آن خط از طریق /etc/update-motd.d/91-release-upgrade نمایش داده می‌شود که به جای پرس‌وجو از شبکه، نتیجه ذخیره‌شده را چاپ می‌کند. برای به‌روزرسانی آن از sudo /usr/lib/ubuntu-release-upgrader/release-upgrade-motd استفاده کنید یا صرفاً به -c اعتماد کنید. بنر فقط نتیجه آخرین بررسی انجام‌شده را تکرار می‌کند.

این بررسی همچنین باید به changelogs.ubuntu.com دسترسی داشته باشد. در سروری که پشت یک فایروال خروجی سخت‌گیرانه یا یک proxy قرار دارد، ابزار نمی‌تواند پرس‌وجو کند، بنابراین نمی‌تواند هیچ چیزی پیدا کند.

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

خط HTTP/2 200 به این معنی است که سرور می‌تواند متادیتا را ببیند. خط curl: (28) Connection timed out به این معنی است که قوانین خروجی (egress rules) شما علت اصلی مشکل هستند و ویرایش فایل‌های APT (ابزار پیشرفته بسته‌بندی) هیچ تغییری در نتیجه ایجاد نخواهد کرد.

اگر دستور به‌طور کامل وجود ندارد، در ubuntu-release-upgrader-core قرار دارد. تصاویر ابری (cloud images) حداقلی گاهی اوقات این بسته را حذف می‌کنند.

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 تا اولین نسخه نقطه‌ای (point release) منتظر می‌ماند

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

در بررسی انجام‌شده در تاریخ 13 August 2026، این دو فایل درباره 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

آن Supported: 0 در فایل LTS همان دروازه ورودی است. یک سرور 24.04 که از Prompt=lts پیش‌فرض استفاده می‌کند، آن فایل را می‌خواند، نسخه LTS جدیدتری که وضعیت آن در دسترس باشد پیدا نمی‌کند و پیام No new release found. را نمایش می‌دهد. هیچ مشکلی در سیستم شما وجود ندارد. Canonical هنوز مسیر ارتقا را باز نکرده است.

این پرچم زمانی به 1 تغییر می‌کند که اولین نسخه نقطه‌ای منتشر شود. انتشار Ubuntu 26.04.1 برای تاریخ 27 August 2026 برنامه‌ریزی شده است، اما از آنجا که زمان‌بندی‌های انتشار تغییر می‌کنند، به جای تقویم، متادیتا را بررسی کنید. این تأخیر عمدی است: کاربرانی که زودتر ارتقا می‌دهند، مشکلات مسدودکننده (blockers) را پیدا می‌کنند و این مشکلات پیش از آنکه جمعیت بسیار بزرگ‌تری از سرورهای LTS اقدام به ارتقا کنند، برطرف می‌شوند.

این وضعیت دو گزینه منطقی باقی می‌گذارد. منتظر نسخه نقطه‌ای بمانید که برای هر سروری که نمی‌خواهید دائماً آن را زیر نظر داشته باشید، انتخاب درستی است. یا مقدار Prompt=normal را تغییر دهید که همان ابزار را به سمت meta-release هدایت می‌کند، جایی که 26.04 از قبل به عنوان نسخه پشتیبانی‌شده علامت‌گذاری شده است. مسیر دوم شما را به نسخه نهایی 26.04 ارتقا می‌دهد، نه به یک نسخه توسعه‌ای؛ بنابراین در ماشینی که می‌توانید آن را از روی snapshot بازیابی کنید، این کار قابل دفاع است. پس از پایان کار، مقدار را دوباره به lts برگردانید. مراحل گام‌به‌گام این رویه در راهنمای کامل ارتقای سرور از 24.04 به 26.04 موجود است.

مخازن شخص ثالث و PPAهایی که مانع ارتقا می‌شوند

ابزار ارتقا، منابع APT شما را بازنویسی می‌کند تا به نسخه جدید اشاره کنند. این ابزار فقط برای مخزنی می‌تواند این کار را انجام دهد که برای نسخه جدید منتشر شده باشد، بنابراین سایر موارد کامنت می‌شوند. دلایل این کار به ازای هر ورودی در یک خط چاپ می‌شوند و کاملاً مشخص هستند: was disabled (unknown mirror)، was disabled (unknown dist) و was disabled (no Release file).

یک PPA (آرشیو بسته شخصی) که برای noble ساخته شده است، هیچ دایرکتوری برای resolute روی سرور ندارد، بنابراین ابزار ارتقا نمی‌تواند فایل Release را برای سری جدید دریافت کند و آن ورودی را غیرفعال می‌کند. این معمولاً هشداری است که می‌توانید آن را بپذیرید. اما زمانی که یک مخزن شخص ثالث بسته‌ای را ارائه می‌دهد که نسخه جدید نیز آن را عرضه می‌کند، این موضوع به یک مانع تبدیل می‌شود؛ زیرا محاسبه ارتقا در این حالت دو کاندیدا دارد و راهی برای راضی کردن هر دو وجود ندارد.

پیش از شروع، خودتان در این مورد تصمیم بگیرید و اجازه ندهید ابزار در حین یک اجرای طولانی و بدون نظارت، تصمیم‌گیری کند.

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

استفاده از apt policy روی نام یک بسته، نشان می‌دهد که هر نسخه نصب‌شده از کدام مخزن آمده است، بنابراین می‌توانید دقیقاً ببینید کدام بسته‌ها به منبعی که قصد غیرفعال کردن آن را دارید، وابسته هستند. حذف منبع باعث دانگرید شدن هیچ چیزی نمی‌شود، بنابراین بسته‌ای که از یک PPA نصب شده، در همان نسخه PPA باقی می‌ماند و ممکن است جدیدتر از نسخه‌ای باشد که در توزیع جدید ارائه شده است. در مواردی که این موضوع اهمیت دارد، بسته را نیز حذف کنید و پس از ارتقا، آن را از آرشیو اصلی دوباره نصب کنید. مخزنی که قصد دارید دوباره آن را فعال کنید، مانند مخزن Tailscale، نیاز دارد که نام رمز (codename) آن به نسخه جدید به‌روزرسانی شود تا بسته دوباره نصب شود؛ این همان جایی است که بیشتر خطاهای نصب Tailscale در اوبونتو از آن ناشی می‌شوند.

یک فلگ برای انتخاب مخالف وجود دارد. صفحه راهنما (man page) از --allow-third-party به عنوان «تلاش برای ارتقا با فعال نگه داشتن آینه‌ها و مخازن شخص ثالث به جای کامنت کردن آن‌ها» یاد می‌کند. فقط زمانی از آن استفاده کنید که تأیید کرده باشید مخزن مورد نظر قبلاً برای نسخه مقصد منتشر شده است. اگر چنین نباشد، شما از APT خواسته‌اید که گراف وابستگی را در برابر سری‌ای حل کند که آن مخزن هرگز برای آن ساخته نشده است.

در اوبونتو 24.04 و نسخه‌های بعد از آن، بیشتر منابع در /etc/apt/sources.list.d/ubuntu.sources با فرمت deb822 قرار دارند. وجود یک مخزن مشابه که هم با فرمت قدیمی و هم با فرمت جدید نوشته شده باشد، یک خطای جداگانه با پیام مخصوص به خود است که در خطای ورودی منبع تکراری در فرمت deb822 به آن پرداخته شده است.

بسته‌های نگه‌داشته‌شده و نیمه‌پیکربندی‌شده مانع محاسبه می‌شوند

ارتقای نسخه (release upgrade) باید تقریباً تمام بسته‌های موجود در سیستم را جابه‌جا کند. اگر یک بسته نتواند جابه‌جا شود، محاسبه با شکست مواجه می‌شود و ابزار ارتقا ترجیح می‌دهد به‌جای رها کردن سیستم در وضعیتی نیمه‌کاره، عملیات را متوقف کند. دو دستور علت این مشکل را مشخص می‌کنند.

apt-mark showhold
sudo dpkg --audit

دستور apt-mark showhold بسته‌های نگه‌داشته‌شده (held) را هر کدام در یک خط چاپ می‌کند و در یک سیستم تمیز، هیچ خروجی‌ای ندارد. وضعیت hold یک دستور دستی است که به سیستم می‌گوید هرگز آن بسته را تغییر ندهد. ممکن است شخصی یک هسته (kernel) یا نسخه خاصی از پایگاه داده را پین کرده باشد و آن را فراموش کرده باشد. بسته‌هایی که دیگر به آن‌ها نیاز ندارید را با دستور sudo apt-mark unhold و به دنبال آن نام بسته، آزاد کنید.

دستور dpkg --audit بسته‌هایی را فهرست می‌کند که باز شده‌اند اما پیکربندی نشده‌اند. این وضعیت ناشی از نصب ناقص است که معمولاً به دلیل قطع شدن نشست (session) رخ می‌دهد. ابزار ارتقا سعی می‌کند این وضعیت را تعمیر کند و پیام 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) اهمیت بیشتری از آنچه به نظر می‌رسد دارد. اوبونتو برخی از به‌روزرسانی‌ها را به‌صورت مرحله‌ای برای درصدی از ماشین‌ها منتشر می‌کند، بنابراین یک دستور ساده apt upgrade ممکن است به‌درستی برخی بسته‌ها را جا بگذارد و در نتیجه سرور شما به‌اندازه‌ای که تصور می‌کنید به‌روز نباشد. این گزینه تمام آن‌ها را دریافت می‌کند. اگر همراه با به‌روزرسانی‌ها، هسته جدیدی نیز ارائه شده است، پس از آن سیستم را reboot کنید تا ارتقا از هسته‌ای که در حال حاضر روی آن اجرا می‌شوید، انجام شود. سیستمی که از قبل خود را از طریق به‌روزرسانی‌های امنیتی خودکار وصله می‌کند، در اینجا کار کمتری دارد، اگرچه آن مکانیزم طبق طراحی، هرگز از مرز نسخه (release boundary) عبور نمی‌کند.

زمانی که پشتیبانی استاندارد از یک نسخه به پایان می‌رسد

یک نسخه موقت (interim) از Ubuntu به مدت 9 ماه پشتیبانی می‌شود. هنگامی که این پشتیبانی به پایان می‌رسد، پرچم Supported: آن به 0 تغییر می‌یابد و مسیر معمول، دیگر امکان ارتقا از آن را فراهم نمی‌کند. در تاریخ 13 August 2026، دستور 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 می‌کند، سیستم دیگر نمی‌تواند به‌روزرسانی شود و از آنجا که ابزار ارتقا (upgrader) بر به‌روز بودن سیستم اصرار دارد، هیچ فرآیندی پیش نمی‌رود. ابتدا منابع (sources) را اصلاح کنید.

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 تغییر دهید و نام رمز (codename) خود را دست‌نخورده باقی بگذارید. فقط نام میزبان (host name) تغییر می‌کند.

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 در هر مرحله فقط از یک گام ارتقا پشتیبانی می‌کند؛ بنابراین سروری که دو یا سه نسخه منقضی‌شده عقب است، باید هر مرحله را به‌ترتیب طی کند و هر مرحله ممکن است به دلیل مخازن شخص ثالث یا بسته‌های قفل‌شده (held packages) با شکست مواجه شود. در یک VPS، اغلب سریع‌تر است که یک سرور جدید با نسخه LTS فعلی بسازید، سرویس را به آن منتقل کنید و سرور قدیمی را تا زمانی که از صحت عملکرد مطمئن نشده‌اید، نگه دارید. این کار همچنین یک قابلیت بازگشت (rollback) به شما می‌دهد که ارتقای درجا (in-place upgrade) هرگز آن را فراهم نمی‌کند. اگر در حال انتخاب مسیری برای آینده هستید، مطالعه تفاوت بین LTS و نسخه‌های موقت در سرور پیش از تصمیم‌گیری توصیه می‌شود.

عملکرد واقعی فلگ نسخه توسعه (development release)

-d یا --devel-release باعث می‌شود ابزار ارتقا به‌جای فایلی که Prompt انتخاب کرده است، meta-release-development را بخواند. صفحه راهنما (manual page) آن را این‌گونه توصیف می‌کند: «اگر از آخرین نسخه پشتیبانی‌شده استفاده می‌کنید، به نسخه توسعه ارتقا دهید.»

در بررسی انجام‌شده در تاریخ 13 August 2026، جدیدترین ورودی در آن فایل، 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) برای محیط‌های عملیاتی (production) توصیه نمی‌شود.» یک نسخه توسعه به‌صورت روزانه تغییر می‌کند و هیچ تضمینی برای پشتیبانی امنیتی ندارد؛ بنابراین بسته‌ای که صبح کار می‌کند، ممکن است بعدازظهر باعث از کار افتادن یک سرویس شود. از این فلگ فقط روی یک ماشین مجازی آزمایشی که برای تست پیکربندی خود ساخته‌اید استفاده کنید. آن را روی سروری که دیگران به آن وابسته‌اند، به‌کار نبرید. زمانی که پیش از باز شدن دروازه LTS به نسخه نهایی 26.04 نیاز دارید، Prompt=normal مسیر صحیح است.

اجرای ارتقا به‌گونه‌ای که قطع شدن نشست SSH باعث اختلال در آن نشود

ارتقای نسخه، بخش بزرگی از سیستم از جمله openssh-server و systemd را جایگزین می‌کند. اگر نشست SSH (پوسته امن) شما در حین کار tmux attach -t upgrade قطع شود، پردازش متوقف شده و بسته‌ها در وضعیت «استخراج‌شده» اما «پیکربندی‌نشده» باقی می‌مانند؛ این دقیقاً همان وضعیتی است که مانع از تلاش بعدی شما برای ارتقا می‌شود. همیشه ارتقا را درون یک terminal multiplexer شروع کنید.

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

اگر اتصال قطع شد، دوباره وارد شوید و tmux attach -t upgrade را اجرا کنید. ارتقا همچنان در حال اجرا باقی مانده است، زیرا فرزند سرور tmux است و نه نشست SSH شما. اگر screen -S upgrade یا screen -r upgrade را ترجیح می‌دهید، آن‌ها نیز همین کار را انجام می‌دهند.

ابزار ارتقا برای کسانی که از multiplexer استفاده نمی‌کنند، یک لایه حفاظتی داخلی دارد. هنگامی که تشخیص دهد تحت SSH در حال اجراست، پیشنهاد می‌دهد یک sshd دوم روی پورت 1022 راه‌اندازی کند تا در صورت قطع شدن نشست اصلی، همچنان راهی برای ورود وجود داشته باشد. این ابزار با بررسی پردازش‌های والد خود و جستجوی پردازشی به نام sshd تصمیم‌گیری می‌کند. درون tmux یا screen، این جستجو به سرور multiplexer ختم می‌شود، بنابراین آن پیشنهاد هرگز ظاهر نمی‌شود و فایل pid یعنی /var/run/release-upgrader-sshd.pid تنها زمانی نوشته می‌شود که daemon اضافی واقعاً شروع به کار کند. اگر این اعلان را نمی‌بینید، مشکلی وجود ندارد؛ شما در حال حاضر از محافظت بهتری برخوردار هستید.

اگر پیشنهاد را بپذیرید، پورت به‌طور خودکار برای شما باز نمی‌شود. ابزار این موضوع را به‌وضوح اعلام می‌کند، زیرا باز کردن پورت یک تصمیم امنیتی است که ابزار مجاز نیست از طرف شما اتخاذ کند. پورت را برای مدت زمان ارتقا باز کنید و سپس دوباره آن را ببندید.

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

بیشتر ارائه‌دهندگان VPS یک فایروال دوم در پنل کنترل خود دارند که خارج از سیستم‌عامل قرار دارد. پورت 1022 باید در آنجا نیز باز باشد، در غیر این صورت listener پشتیبان اجرا می‌شود اما غیرقابل‌دسترس خواهد بود که بدترین حالت ممکن است.

پیش از تایپ دستور، این چهار مورد باید آماده باشند:

• یک snapshot یا نسخه پشتیبان کامل تهیه کنید. ارتقای نسخه در محل (in-place) قابلیت بازگشت ندارد و این تنها فرصت شماست.
• اطمینان حاصل کنید که می‌توانید پیش از نیاز، به کنسول ارائه‌دهنده خود دسترسی پیدا کنید. اگر سرور پس از reboot بالا نیاید، SSH دقیقاً همان چیزی است که در اختیار نخواهید داشت. هسته‌ای که در بوت شدن شکست می‌خورد، مشکلی مجزا با مراحل بازیابی خاص خود است که در VPS که پس از به‌روزرسانی هسته بوت نمی‌شود پوشش داده شده است.
• فضای آزاد را با df -h / /boot بررسی کنید. ارتقا مجموعه‌ای کامل از بسته‌ها را دانلود می‌کند و پارتیشن /boot که چندین هسته قدیمی را در خود نگه داشته، محل رایجی برای توقف فرآیند است.
• یادداشت‌های انتشار (release notes) سرویس‌هایی که اجرا می‌کنید را بخوانید. جهش نسخه اصلی در PostgreSQL یا PHP همراه با ارتقای سیستم می‌آید، چه برای آن برنامه‌ریزی کرده باشید و چه نکرده باشید.

FAQ

چرا دستور do-release-upgrade در Ubuntu 24.04 می‌گوید هیچ نسخه جدیدی یافت نشد؟

مقدار پیش‌فرض Prompt=lts در فایل /etc/update-manager/release-upgrades باعث می‌شود ابزار فایل https://changelogs.ubuntu.com/meta-release-lts را بخواند، و Ubuntu 26.04 تا زمان انتشار اولین نسخه نقطه‌ای (point release)، مقدار Supported: 0 را در آن فایل نگه می‌دارد. ابزار ارتقا هیچ نسخه LTS جدیدی که به عنوان موجود علامت‌گذاری شده باشد پیدا نمی‌کند، بنابراین متوقف می‌شود. فایل را شخصاً با curl -s https://changelogs.ubuntu.com/meta-release-lts بررسی کنید و بلوک آخر را بخوانید. در بررسی مورخ 13 August 2026، این پرچم همچنان 0 بود، در حالی که Ubuntu 26.04.1 برای 27 August 2026 برنامه‌ریزی شده است.

آیا تنظیم Prompt=normal به جای انتظار برای نسخه نقطه‌ای امن است؟

این کار شما را به نسخه منتشرشده 26.04 ارتقا می‌دهد، نه به یک نسخه توسعه‌یافته (development build)، زیرا Prompt=normal فایل meta-release را می‌خواند که در آن 26.04 از قبل دارای Supported: 1 است. ریسک این کار در زمان‌بندی است. شما پیش از آنکه مشکلات گزارش‌شده توسط ارتقادهندگان اولیه برطرف شود، اقدام می‌کنید. این کار را روی سروری انجام دهید که امکان بازگردانی از snapshot را داشته باشد و در صورت بروز مشکل در reboot، به کنسول ارائه‌دهنده دسترسی داشته باشید. پس از اتمام کار، مقدار را به lts برگردانید.

آیا پرچم -d من را به 26.04 ارتقا می‌دهد؟

خیر. -d فایل meta-release-development را می‌خواند که جدیدترین ورودی آن در 13 August 2026، نسخه Ubuntu 26.10 بود که هنوز در حال توسعه است. روی یک ماشین LTS با تنظیم Prompt=lts، این پرچم عبارت There is no development version of an LTS available. را چاپ کرده و متوقف می‌شود. مستندات سرور خود اوبونتو می‌گوید نسخه توسعه برای محیط عملیاتی (production) توصیه نمی‌شود، بنابراین زمانی که می‌خواهید نسخه 26.04 منتشرشده را زودتر دریافت کنید، از Prompt=normal استفاده کنید.

دستور apt update در یک نسخه قدیمی خطای 404 می‌دهد. چگونه آن را ارتقا دهم؟

آن نسخه به پایان عمر خود رسیده است، بنابراین بسته‌های آن از archive.ubuntu.com به old-releases.ubuntu.com منتقل شده‌اند. فقط نام میزبان‌ها (host names) را در /etc/apt/sources.list.d/ubuntu.sources، یا در /etc/apt/sources.list در ساختارهای قدیمی‌تر تغییر دهید و نام رمز (codename) خود را به همان صورت نگه دارید. سپس دستورات sudo apt update و sudo apt full-upgrade را اجرا کنید. هنگامی که سیستم دوباره به‌روز شد، do-release-upgrade می‌تواند آن را هر بار یک نسخه به جلو ببرد.

آیا باید قبل از اجرای do-release-upgrade، مخازن PPA خود را حذف کنم؟

نیازی به این کار نیست، زیرا ابزار ارتقا هر منبعی که برای نسخه جدید منتشر نشده باشد را کامنت (comment out) می‌کند و برای هر کدام خطی مانند was disabled (no Release file) چاپ می‌کند. انجام دستی این کار بهتر است، زیرا شما ترتیب را انتخاب می‌کنید و نتیجه را می‌بینید. دستور apt policy را روی بسته‌های مورد نظر خود اجرا کنید تا بفهمید کدام‌یک از هر PPA آمده‌اند، سپس اگر نسخه PPA جدیدتر از نسخه موجود در مخزن اصلی است، آن‌ها را از آرشیو دوباره نصب کنید.