رفع خطای 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، محدودیت point release در ارتقاهای LTS (پشتیبانی بلندمدت)، مخازن شخص ثالث، بسته‌هایی که در وضعیت held یا نیمه‌پیکربندی‌شده هستند، و نسخه‌ای که دوره پشتیبانی آن به پایان رسیده است.

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

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

sudo do-release-upgrade -c
echo $?

-c حالت فقط بررسی (check only) است. این دستور متادیتای انتشار 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) شما همچنان پاسخ قدیمی را نشان می‌دهد، به این دلیل است که در حافظه کش ذخیره شده است. آن خط از /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 قرار دارد. ایمیج‌های ابری مینیمال گاهی اوقات این بسته را حذف می‌کنند.

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 هنوز مسیر ارتقا را باز نکرده است.

این flag با انتشار نخستین point release به 1 تغییر می‌کند. انتشار Ubuntu 26.04.1 برای 27 August 2026 برنامه‌ریزی شده است و زمان‌بندی انتشار ممکن است تغییر کند؛ بنابراین به‌جای تقویم، metadata را بررسی کنید. point release نسخهٔ جدیدی از Ubuntu نیست؛ فقط همان release است که همهٔ updateهای منتشرشده از زمان launch در media نصب جدید آن ادغام شده‌اند. بنابراین، برای سروری که در حال اجراست، چیزی که اهمیت دارد gateای است که باز می‌شود، نه خود media. این تأخیر عمدی است: افرادی که زودتر upgrade می‌کنند، blockerها را پیدا می‌کنند و این مشکلات پیش از آن‌که جمعیت بسیار بزرگ‌تر سرورهای LTS ارتقا یابد، برطرف می‌شوند. اگر هنگام خواندن این متن آن تاریخ گذشته است، مواردی که همراه با 26.04.1 منتشر شد و معنای آن برای یک سرور 24.04 ادامهٔ این موضوع را توضیح می‌دهد.

بنابراین دو گزینه صادقانه باقی می‌ماند. برای point release منتظر بمانید؛ این انتخاب مناسب هر سروری است که ترجیح می‌دهید دائماً آن را زیر نظر نداشته باشید. یا Prompt=normal را تنظیم کنید تا همان ابزار را به meta-release هدایت کند؛ در آنجا 26.04 از قبل به‌عنوان نسخهٔ پشتیبانی‌شده علامت‌گذاری شده است. مسیر دوم، شما را به 26.04 منتشرشده ارتقا می‌دهد، نه به یک development build؛ بنابراین روی ماشینی که می‌توانید آن را از یک snapshot بازیابی کنید، قابل‌دفاع است. پس از پایان کار، مقدار را به lts برگردانید. مراحل این فرایند، به‌صورت گام‌به‌گام، در راهنمای کامل ارتقای سرور از 24.04 به 26.04 آمده است. سروری که هنوز روی 22.04 است، باید یک مرحلهٔ اضافی را طی کند، زیرا Prompt=lts فقط next LTS release را ارائه می‌کند؛ بنابراین مسیر ارتقا از 22.04 به 26.04 ابتدا از 24.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 روی نام یک بسته چاپ می‌کند که هر نسخه نصب‌شده از کدام مخزن آمده است، بنابراین می‌توانید دقیقاً ببینید کدام بسته‌ها به منبعی که قصد غیرفعال کردن آن را دارید، وابسته‌اند. حذف منبع، هیچ چیزی را دانگرید (downgrade) نمی‌کند، بنابراین بسته‌ای که از یک PPA نصب شده، در همان نسخه PPA باقی می‌ماند و می‌تواند جدیدتر از نسخه‌ای باشد که در نسخه جدید سیستم‌عامل وجود دارد. در مواردی که این موضوع اهمیت دارد، بسته را نیز حذف کنید و پس از ارتقا، آن را از آرشیو اصلی دوباره نصب کنید. مخزنی که قصد دارید دوباره آن را اضافه کنید، مانند Tailscale، نیاز دارد که نام رمز (codename) آن به نسخه جدید به‌روزرسانی شود تا بسته دوباره نصب شود؛ این همان جایی است که بیشتر خطاهای نصب Tailscale در Ubuntu از آن ناشی می‌شود.

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

در Ubuntu 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 بسته‌هایی را فهرست می‌کند که باز شده‌اند (unpacked) اما پیکربندی نشده‌اند. این وضعیت ناشی از نصب ناقص است که معمولاً به دلیل قطع شدن نشست (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 آگوست 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 یک سرور 26.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 باعث خرابی آن نشود

ارتقای release بیشتر اجزای سیستم، از جمله openssh-server و systemd، را جایگزین می‌کند. اگر session مربوط به SSH (secure shell) هنگام کار dpkg قطع شود، این فرایند با packageهایی که فقط unpack شده‌اند و هنوز configuration نشده‌اند، متوقف می‌شود. همین وضعیت مانع تلاش بعدی شما خواهد شد. اگر این اتفاق قبلاً رخ داده است، بازیابی ارتقایی که در میانه متوقف شده است کار جداگانه‌ای است و باید پیش از هر تلاش مجدد انجام شود. ارتقا را هر بار داخل یک terminal multiplexer آغاز کنید.

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

اگر اتصال قطع شد، دوباره وارد شوید و tmux attach -t upgrade را اجرا کنید. ارتقا همچنان در حال اجرا باقی مانده است، زیرا فرزند سرور tmux است و نه نشست SSH شما. اگر screen را ترجیح می‌دهید، 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 به‌جای انتظار برای point release امن است؟

این کار شما را به نسخه نهایی 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. را چاپ کرده و متوقف می‌شود. مستندات رسمی سرور Ubuntu بیان می‌کند که نسخه توسعه‌یافته برای محیط‌های عملیاتی (production) توصیه نمی‌شود، بنابراین زمانی که می‌خواهید نسخه نهایی 26.04 را زودتر دریافت کنید، از Prompt=normal استفاده کنید.

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

آن نسخه به پایان عمر خود (EOL) رسیده است، بنابراین بسته‌های آن از 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های خود را حذف کنم؟

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