Amir Jabbari
اگر هنگام اجرای apt update با خطاهایی مانند does not have a Release file، 404 Not Found، Release file is not valid yet یا خطاهای مربوط به Repository روبه‌رو شده‌اید، قبل از تغییر تصادفی فایل‌های مخزن باید مشخص کنید مشکل دقیقاً از کجاست.
یکی از علت‌های مهم این خطا، استفاده از نسخه‌ای از Ubuntu است که به پایان پشتیبانی استاندارد رسیده و Repository آن از مخازن معمولی به آرشیو نسخه‌های قدیمی منتقل شده است. بااین‌حال، همین پیام می‌تواند به دلیل اشتباه بودن Codename، خراب بودن Repository شخص ثالث یا نادرست بودن ساعت سرور نیز نمایش داده شود.
پاسخ کوتاه: ابتدا نسخه Ubuntu و Codename را بررسی کنید. اگر نسخه EOL است، راه‌حل اصلی ارتقا به نسخه پشتیبانی‌شده یا استفاده از Ubuntu Pro/ESM در صورت مناسب بودن شرایط است. تغییر موقت Repository به old-releases.ubuntu.com فقط برای دسترسی به آرشیو نسخه قدیمی کاربرد دارد و جایگزین پشتیبانی امنیتی نسخه جدید نیست.
خطای Release file دقیقاً یعنی چه؟
APT برای نصب و به‌روزرسانی بسته‌ها به اطلاعات Repository نیاز دارد. این اطلاعات از فایل‌هایی مانند InRelease یا Release دریافت می‌شوند. اگر APT نتواند فایل معتبر مربوط به نسخه و Repository را پیدا یا اعتبارسنجی کند، به‌روزرسانی آن مخزن را متوقف می‌کند.
بنابراین پیامی مانند repository … does not have a Release file به‌تنهایی نمی‌گوید که کل Ubuntu خراب شده است. باید مشخص شود کدام Repository خطا داده و آیا آن Repository متعلق به خود Ubuntu است یا یک سرویس شخص ثالث.
🔹 اگر نام مخزن شامل archive.ubuntu.com یا security.ubuntu.com است: احتمال دارد نسخه Ubuntu قدیمی، Codename اشتباه یا تنظیمات Repository مشکل داشته باشد.
🔹 اگر نام مخزن متعلق به یک نرم‌افزار دیگر است: ممکن است آن نرم‌افزار از نسخه Ubuntu شما پشتیبانی نکند.
🔹 اگر پیام شامل not valid yet است: ابتدا ساعت و همگام‌سازی زمان سرور را بررسی کنید؛ این پیام الزاماً نشانه EOL نیست.
کدام نسخه‌های Ubuntu در سال ۲۰۲۶ پشتیبانی می‌شوند؟
در زمان بازنگری این مقاله، Ubuntu 26.04 LTS جدیدترین نسخه LTS است. Ubuntu 24.04 و 22.04 نیز همچنان در دوره پشتیبانی استاندارد قرار دارند. در مقابل، 20.04 از پشتیبانی استاندارد خارج شده و 18.04 و نسخه‌های قدیمی‌تر نیز مدت‌هاست از این دوره خارج شده‌اند.
| نسخه | وضعیت پشتیبانی استاندارد | مسیر پیشنهادی |
|---|---|---|
| Ubuntu 26.04 LTS | پشتیبانی‌شده | مناسب برای استقرارهای جدید پس از بررسی سازگاری |
| Ubuntu 24.04 LTS | پشتیبانی‌شده تا ۲۰۲۹ | گزینه مناسب برای بسیاری از سرورهای فعلی |
| Ubuntu 22.04 LTS | پشتیبانی‌شده تا ۲۰۲۷ | هنوز قابل استفاده و قابل ارتقا |
| Ubuntu 20.04 LTS | پشتیبانی استاندارد پایان یافته | ارتقا یا بررسی Ubuntu Pro/ESM |
| Ubuntu 18.04 و قدیمی‌تر | خارج از پشتیبانی استاندارد | برنامه‌ریزی برای مهاجرت یا بازیابی موقت از آرشیو |
پایان پشتیبانی استاندارد به معنی حذف فوری تمام فایل‌های نسخه نیست. Canonical برای نسخه‌های قدیمی آرشیوهایی مانند old-releases.ubuntu.com دارد، اما استفاده از این آرشیو با دریافت به‌روزرسانی امنیتی از یک نسخه LTS پشتیبانی‌شده یکسان نیست.
مرحله ۱: نسخه Ubuntu را قبل از هر تغییری بررسی کنید
هدف: ابتدا باید بفهمیم سرور دقیقاً چه نسخه‌ای دارد. این مرحله فقط اطلاعات سیستم را می‌خواند و تغییری ایجاد نمی‌کند.
محل اجرا: ترمینال خود سرور یا اتصال SSH.
cat /etc/os-release
در خروجی، مواردی مانند VERSION_ID و VERSION_CODENAME را پیدا کنید. برای نمونه، Ubuntu 20.04 معمولاً Codename برابر focal دارد و Ubuntu 22.04 از Codename jammy استفاده می‌کند.
برای مشاهده فقط اطلاعات اصلی می‌توانید از این فرمان نیز استفاده کنید:
grep -E '^(VERSION_ID|VERSION_CODENAME)=' /etc/os-release
⚠️ نکته: نسخه Ubuntu را از روی حدس یا نام نرم‌افزار نصب‌شده تعیین نکنید. Codename باید از خود سیستم خوانده شود؛ زیرا Repositoryها بر اساس همین نام به نسخه مشخص متصل می‌شوند.
مرحله ۲: ببینید خطا مربوط به کدام Repository است
در Ubuntuهای جدید، Repositoryهای رسمی Ubuntu معمولاً در فایل ubuntu.sources قرار دارند؛ در نسخه‌های قدیمی‌تر فایل /etc/apt/sources.list نقش اصلی را دارد. فایل‌های داخل /etc/apt/sources.list.d/ نیز می‌توانند Repositoryهای اضافی را تعریف کنند.
grep -RniE '^(deb|Types:|URIs:|Suites:)' /etc/apt/sources.list /etc/apt/sources.list.d 2>/dev/null
اگر خطا از Repository یک نرم‌افزار شخص ثالث مانند PostgreSQL، Docker، Node.js یا یک PPA آمده باشد، تغییر Repositoryهای رسمی Ubuntu لزوماً مشکل را حل نمی‌کند. ابتدا باید بررسی شود که همان سرویس از نسخه Ubuntu شما پشتیبانی می‌کند یا خیر.
مرحله ۳: اگر پیام Release file مربوط به زمان سیستم است
اگر متن خطا عبارتی مانند Release file is not valid yet دارد، قبل از دستکاری Repository ساعت سرور را بررسی کنید. APT برای اعتبارسنجی امضای مخزن به زمان صحیح سیستم نیاز دارد.
timedatectl status
date -u
به‌خصوص مقدار همگام‌سازی زمان را بررسی کنید. در سیستم‌هایی که از سرویس زمان systemd استفاده می‌کنند، می‌توانید وضعیت همگام‌سازی را فعال کنید:
sudo timedatectl set-ntp true
بعد از همگام‌شدن ساعت، دوباره apt update را اجرا کنید. اگر پیام خطا تغییر کرد، علت اصلی احتمالاً Repository یا EOL نبوده است.
مرحله ۴: قبل از تغییر Repository از تنظیمات فعلی نسخه پشتیبان بگیرید
تغییر فایل‌های APT می‌تواند روی نصب و به‌روزرسانی نرم‌افزارها اثر بگذارد. بنابراین قبل از تغییر، از فایل‌های Repository نسخه پشتیبان بگیرید.
sudo cp -a /etc/apt/sources.list /etc/apt/sources.list.backup
sudo cp -a /etc/apt/sources.list.d /etc/apt/sources.list.d.backup
اگر فایل /etc/apt/sources.list در نسخه شما وجود نداشت، نبودن آن به‌تنهایی خطا محسوب نمی‌شود؛ Ubuntuهای جدید می‌توانند از فایل‌های .sources در پوشه sources.list.d استفاده کنند.
اگر Ubuntu واقعاً EOL شده باشد چه کار کنیم؟
برای سروری که هنوز سرویس مهمی روی آن اجرا می‌شود، بهترین مسیر این است که ابتدا از داده‌ها و تنظیمات برنامه نسخه پشتیبان قابل بازیابی تهیه کنید و سپس برای ارتقا یا مهاجرت برنامه‌ریزی کنید. Ubuntu به‌صورت رسمی ارتقای LTSها را به شکل ترتیبی انجام می‌دهد و نباید بدون بررسی، چند نسخه را یک‌باره رد کرد.
برای نمونه، مسیر استاندارد یک سرور 20.04 به نسخه‌های جدیدتر از طریق LTS بعدی انجام می‌شود. در زمان فعلی، اگر هدف نهایی 26.04 باشد، باید محدودیت‌ها و مسیرهای رسمی هر مرحله را بررسی کنید؛ برای سیستم‌های حساس، ساخت یک VPS جدید و انتقال سرویس می‌تواند از ارتقای درجا قابل‌کنترل‌تر باشد.
📌 نکته مهم درباره 26.04: Ubuntu 26.04 LTS در آوریل ۲۰۲۶ منتشر شده و پشتیبانی استاندارد آن پنج سال ادامه دارد. بااین‌حال، سازگاری نرم‌افزارهای قدیمی، نسخه‌های PHP، Python، Docker، درایورها و سرویس‌های شما باید قبل از مهاجرت بررسی شود.
استفاده موقت از old-releases.ubuntu.com برای نسخه EOL
اگر هنوز به نسخه قدیمی وابسته هستید و فقط می‌خواهید بسته‌های موجود در آرشیو همان نسخه را دریافت کنید، Ubuntu برای نسخه‌های قدیمی Repository آرشیوی دارد. راهنمای رسمی EOL Upgrade نیز برای نسخه‌های خارج از پشتیبانی، تغییر دامنه Repository به old-releases.ubuntu.com را توضیح می‌دهد.
این روش را باید یک راهکار موقت و مخصوص آرشیو دانست. تغییر دامنه به old-releases باعث نمی‌شود یک Ubuntu EOL دوباره به نسخه پشتیبانی‌شده تبدیل شود.
نمونه برای Ubuntu 20.04
اگر سیستم شما Ubuntu 20.04 با Codename برابر focal است و تصمیم گرفته‌اید موقتاً از آرشیو رسمی همان نسخه استفاده کنید، محتوای Repositoryهای اصلی باید با Codename صحیح نسخه هماهنگ باشد.
برای جلوگیری از اشتباه، فایل را ابتدا باز کنید:
sudo nano /etc/apt/sources.list
نمونه محتوای پایه برای Ubuntu 20.04 در آرشیو قدیمی:
deb http://old-releases.ubuntu.com/ubuntu/ focal main restricted universe multiverse
deb http://old-releases.ubuntu.com/ubuntu/ focal-updates main restricted universe multiverse
deb http://old-releases.ubuntu.com/ubuntu/ focal-security main restricted universe multiverse
بعد از ذخیره فایل، فهرست بسته‌ها را دوباره دریافت کنید:
sudo apt update
اگر خروجی بدون خطای Repository رسمی پایان یافت، مشکل دسترسی به آرشیو اصلی نسخه قدیمی برطرف شده است. اما اگر Repository شخص ثالث همچنان خطا می‌دهد، باید همان Repository را جداگانه بررسی کنید.
⚠️ هشدار امنیتی: استفاده از old-releases برای ادامه کار بلندمدت روی یک سرور تولیدی به معنی دریافت منظم به‌روزرسانی امنیتی استاندارد نیست. اگر سرویس شما اینترنتی و مهم است، این مرحله را راه‌حل نهایی در نظر نگیرید.
Ubuntu 20.04 را به‌جای آرشیو قدیمی ارتقا دهیم؟
اگر برنامه شما با نسخه جدید سازگار است، ارتقا مسیر بلندمدت‌تری است. مستندات Ubuntu برای Server استفاده از ابزار do-release-upgrade را توصیه می‌کنند. قبل از آن باید سیستم به وضعیت قابل ارتقا برسد، فضای کافی داشته باشد و از داده‌ها نسخه پشتیبان تهیه شود.
بعد از آماده‌سازی Repository و حل خطاهای APT، ابتدا وضعیت بسته‌ها را بررسی کنید:
sudo apt update
sudo apt upgrade
اگر این مرحله خطا دارد، هنوز زمان مناسبی برای شروع ارتقای نسخه نیست. ابتدا خطای APT را برطرف کنید.
برای شروع فرآیند ارتقای نسخه سرور:
sudo do-release-upgrade
ابزار ارتقا قبل از شروع، وضعیت سیستم و تغییرات احتمالی را بررسی می‌کند. اگر نرم‌افزارهای شخص ثالث یا PPAها دارید، آن‌ها یکی از عوامل رایج مشکل در ارتقا هستند و باید سازگاری نسخه جدید را بررسی کنید.
اگر Repository رسمی درست است اما یک مخزن دیگر خطا می‌دهد
فرض کنید apt update بیشتر مخازن Ubuntu را با موفقیت دریافت می‌کند اما یک آدرس مانند Repository یک نرم‌افزار خارجی خطای Release file می‌دهد. در این حالت تغییر کل sources.list به old-releases راه‌حل مناسبی نیست.
ابتدا نام فایل مخزن را پیدا کنید:
grep -RniE '^(deb|Types:|URIs:)' /etc/apt/sources.list.d 2>/dev/null
اگر مشخص شد نرم‌افزار خارجی از Codename فعلی پشتیبانی نمی‌کند، مستندات رسمی همان نرم‌افزار را بررسی کنید. در صورت عدم نیاز، Repository را به‌جای دستکاری کل Ubuntu غیرفعال کنید. فایل آن را حذف نکنید مگر اینکه مطمئن باشید دیگر هیچ بسته‌ای از آن منبع استفاده نمی‌شود.
خطاهای متداول و روش تشخیص
| نشانه | علت‌های محتمل | اولین بررسی |
|---|---|---|
| does not have a Release file | EOL، Codename اشتباه یا Repository شخص ثالث نامعتبر | نسخه Ubuntu و آدرس دقیق مخزن |
| 404 Not Found | مسیر Repository وجود ندارد یا نسخه حذف شده است | Codename و URL Repository |
| Release file is not valid yet | ساعت یا زمان سیستم با زمان واقعی هماهنگ نیست | timedatectl و date -u |
| NO_PUBKEY | کلید امضای Repository در سیستم موجود یا معتبر نیست | مستندات رسمی همان Repository |
آیا تغییر Release file با غیرفعال کردن بررسی امنیتی درست است؟
خیر. فرمان‌ها یا تنظیماتی که بررسی اعتبار Repository، امضای بسته‌ها یا TLS را غیرفعال می‌کنند نباید به‌عنوان راه‌حل عمومی ارائه شوند. APT از مکانیزم‌های اعتبارسنجی Repository استفاده می‌کند تا بسته‌ها از یک منبع معتبر دریافت شوند.
اگر Repository واقعاً مشکل دارد، باید منبع درست، کلید معتبر و Codename صحیح را پیدا کرد؛ نه اینکه کنترل‌های امنیتی APT را خاموش کرد.
قبل از ارتقای Ubuntu روی VPS چه چیزهایی را بررسی کنیم؟
🔹 از فایل‌ها، پایگاه داده و تنظیمات سرویس‌های مهم نسخه پشتیبان قابل بازیابی داشته باشید.
🔹 مطمئن شوید فضای دیسک کافی برای بسته‌های موقت و نسخه جدید وجود دارد.
🔹 سرویس‌های مهم مانند وب‌سرور، PHP، Docker، دیتابیس و Agentهای مانیتورینگ را فهرست کنید.
🔹 Repositoryهای شخص ثالث و PPAها را شناسایی کنید.
🔹 روش دسترسی جایگزین به VPS را در صورت قطع SSH در نظر بگیرید.
🔹 برای سرور تولیدی، زمان مناسب برای Downtime احتمالی و روش بازگشت را از قبل مشخص کنید.
اگر VPS شما هنوز روی Ubuntu EOL است
در سرورهایی که سرویس مهم دارند، حل موقت Repository فقط بخشی از کار است. باید مشخص شود ارتقای درجا، مهاجرت به VPS جدید یا فعال‌سازی پوشش امنیتی مناسب کدام نیاز فنی شما را پوشش می‌دهد.
پرسش‌های متداول
آیا خطای Release file همیشه به معنی EOL بودن Ubuntu است؟
خیر. Repository شخص ثالث، Codename اشتباه، حذف یک نسخه از مخزن، خرابی تنظیمات و نادرست بودن ساعت سیستم نیز می‌توانند خطاهای مشابه ایجاد کنند. ابتدا باید نام Repository و نسخه Ubuntu بررسی شود.
برای Ubuntu 20.04 که EOL شده چه راهی داریم؟
می‌توانید مسیر ارتقا را بررسی کنید یا در صورت داشتن شرایط مناسب از Ubuntu Pro و ESM برای افزایش دوره نگهداری امنیتی استفاده کنید. old-releases نیز آرشیو نسخه قدیمی را در اختیار می‌گذارد، اما استفاده از آن را نباید معادل پشتیبانی استاندارد دانست.
آیا می‌توان Ubuntu EOL را مستقیماً به آخرین نسخه ارتقا داد؟
ارتقاهای LTS طبق مسیرهای ترتیبی انجام می‌شوند و نباید بدون بررسی چند نسخه را رد کرد. برای سیستم‌های قدیمی و سرویس‌های حساس، مهاجرت به یک VPS یا نصب جدید و انتقال کنترل‌شده سرویس نیز می‌تواند گزینه قابل بررسی باشد.
چرا Repository را به old-releases تغییر می‌دهیم؟
زیرا نسخه‌های قدیمی Ubuntu از مخازن اصلی کنار گذاشته می‌شوند و فایل‌های آن‌ها در آرشیو نسخه‌های قدیمی نگهداری می‌شود. این تغییر فقط مسیر دسترسی به بسته‌های آرشیوی همان نسخه را اصلاح می‌کند.
اگر Ubuntu 22.04 دارم ولی Release file خطا می‌دهد چه کنم؟
Ubuntu 22.04 هنوز در دوره پشتیبانی استاندارد است؛ بنابراین نباید صرفاً به دلیل مشاهده این خطا آن را EOL فرض کنید. نسخه، Codename، Repository خطادار و در صورت مشاهده پیام مربوط به زمان، ساعت سیستم را بررسی کنید.
آیا حذف همه Repositoryهای اضافی مشکل را حل می‌کند؟
نه لزوماً. Repository اضافی ممکن است برای نرم‌افزاری که روی سرور نصب شده ضروری باشد. ابتدا منبع خطادار را شناسایی کنید و سپس بر اساس مستندات همان نرم‌افزار درباره غیرفعال‌سازی، اصلاح یا حذف آن تصمیم بگیرید.
جمع‌بندی
رفع خطای Release file از تشخیص شروع می‌شود، نه از تغییر کورکورانه Repository.
ابتدا نسخه Ubuntu و Codename را بخوانید، Repository خطادار را پیدا کنید و ساعت سیستم را در خطاهای زمانی بررسی کنید. اگر نسخه واقعاً EOL است، ارتقا یا مهاجرت را راهکار اصلی قرار دهید و old-releases را فقط برای دسترسی موقت به آرشیو نسخه قدیمی به کار ببرید.
اگر سرور برای یک سرویس مهم استفاده می‌شود، قبل از تغییر Repository یا ارتقا، بکاپ قابل بازیابی و مسیر بازگشت داشته باشید.
منابع رسمی
🔹 چرخه انتشار و وضعیت پشتیبانی Ubuntu
🔹 راهنمای رسمی جامعه Ubuntu برای ارتقای نسخه‌های EOL
🔹 مستندات Ubuntu Server درباره ارتقای Release
🔹 مستندات مدیریت بسته‌ها و Repository در Ubuntu Server
🔹 فهرست Releaseهای Ubuntu و آرشیو نسخه‌های قدیمی
نیاز به بررسی یا کانفیگ VPS دارید؟
اگر خطای Repository روی VPS شما با یک سرویس مهم درگیر شده یا قبل از ارتقا نیاز دارید تنظیمات سرور بررسی شود، می‌توانید درخواست بررسی و کانفیگ را برای ایرانیکاسرور ارسال کنید.
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
دیدگاه‌ها (۰)