Amir Jabbariاگر هنگام اجرای apt update روی VPS اوبونتو با خطاهایی مانند
Release file expired، 404 Not Found،
does not have a Release file یا خطای Repository مواجه شده‌اید،
ممکن است نسخه Ubuntu شما به پایان دوره پشتیبانی رسیده باشد. در این راهنما
روش تشخیص نسخه EOL، اصلاح Repository، استفاده از مخزن old-releases.ubuntu.com
و آماده‌سازی سرور برای ارتقا به نسخه جدید را مرحله‌به‌مرحله بررسی می‌کنیم.
استفاده از مخزن Old Releases یک راهکار موقت برای دسترسی به بسته‌های یک نسخه قدیمی است.
این روش به معنی دریافت پشتیبانی امنیتی جدید برای نسخه EOL نیست. اگر سرور شما برای سرویس
تولیدی استفاده می‌شود، بعد از برطرف کردن مشکل APT، برنامه ارتقا به نسخه پشتیبانی‌شده را
در اولویت قرار دهید.
مدیریت و عیب‌یابی Ubuntu VPS؛ قبل از تغییر Repository از وضعیت سیستم نسخه فعلی مطمئن شوید.خطای Release file در Ubuntu چیست؟
ابزار APT برای دریافت فهرست بسته‌ها به Repositoryهای اوبونتو متصل می‌شود.
هر Repository باید فایل‌های Release مربوط به نسخه موردنظر را در اختیار APT قرار دهد.
زمانی که نسخه Ubuntu از چرخه پشتیبانی خارج شود، آدرس معمول Repository دیگر محل مناسبی
برای دریافت آن نسخه نیست و ممکن است خطاهای مختلفی هنگام اجرای apt update
مشاهده کنید.
در چنین شرایطی، یکی از نشانه‌های رایج این است که APT به آدرس‌هایی مانند
archive.ubuntu.com یا security.ubuntu.com مراجعه می‌کند،
اما نسخه قدیمی موردنظر دیگر در مخازن معمول قرار ندارد. Ubuntu برای نسخه‌های قدیمی
آرشیوی جداگانه در اختیار کاربران قرار می‌دهد که با نام old-releases.ubuntu.com
شناخته می‌شود. :contentReference[oaicite:0]{index=0}
اول نسخه Ubuntu را بررسی کنید
قبل از تغییر هر فایل Repository، مشخص کنید سرور دقیقاً از چه نسخه‌ای استفاده می‌کند.
این کار از تغییر اشتباه Codename جلوگیری می‌کند.
cat /etc/os-releaseبرای مشاهده اطلاعات کامل‌تر می‌توانید از دستور زیر نیز استفاده کنید:
lsb_release -aبرای مثال ممکن است خروجی سرور نشان دهد که نسخه شما Ubuntu 20.04 است
و Codename آن focal است. مهم است که هنگام اصلاح Repository، همین Codename
واقعی سیستم را حفظ کنید و آن را حدسی تغییر ندهید.
🔹 Ubuntu 18.04 → bionic
🔹 Ubuntu 20.04 → focal
🔹 Ubuntu 22.04 → jammy
🔹 Ubuntu 24.04 → noble
🔹 Ubuntu 25.04 → plucky
🔹 Ubuntu 25.10 → questing
چرا Repository معمولی کار نمی‌کند؟
Ubuntu نسخه‌های جاری را از Repositoryهای اصلی ارائه می‌کند، اما نسخه‌های قدیمی پس از
خروج از چرخه معمول انتشار به آرشیو Old Releases منتقل می‌شوند. صفحه رسمی انتشارهای Ubuntu
نیز برای نسخه‌های قدیمی به old-releases.ubuntu.com ارجاع می‌دهد. :contentReference[oaicite:1]{index=1}
بنابراین اگر فایل /etc/apt/sources.list هنوز به Repositoryهای معمول اشاره کند،
APT ممکن است نتواند متادیتای موردنیاز نسخه قدیمی را پیدا کند.
قبل از تغییر Repository از فایل sources.list بکاپ بگیرید
بهتر است قبل از هر تغییری یک نسخه پشتیبان از تنظیمات APT داشته باشید. اگر تغییری اشتباه انجام شود،
می‌توانید فایل قبلی را برگردانید.
sudo cp /etc/apt/sources.list /etc/apt/sources.list.backupهمچنین اگر Repositoryهای اضافی در فایل‌های داخل /etc/apt/sources.list.d/ دارید،
بهتر است قبل از تغییرات بررسی کنید.
ls -la /etc/apt/sources.list.d/روش استاندارد اصلاح Repository برای Ubuntu EOL
طبق راهنمای Ubuntu Community برای ارتقای نسخه‌های EOL، می‌توان Repositoryهای نسخه قدیمی
را به old-releases.ubuntu.com منتقل کرد، بدون اینکه Codename نسخه را تغییر دهید.
نمونه استاندارد شامل Repositoryهای اصلی، Updates و Security است. :contentReference[oaicite:2]{index=2}
مرحله اول: فایل sources.list را باز کنید
sudo nano /etc/apt/sources.listفرض کنیم نسخه سرور Ubuntu 20.04 و Codename آن focal است.
Repositoryهای اصلی را می‌توان به شکل زیر تنظیم کرد:
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اگر نسخه شما چیز دیگری است، فقط Codename واقعی همان نسخه را جایگزین کنید.
برای مثال در Ubuntu 18.04 از bionic استفاده می‌شود و در Ubuntu 22.04 از
jammy.
Codename را فقط برای اینکه Repository جواب بدهد به نسخه دیگری تغییر ندهید.
Repository باید با نسخه نصب‌شده روی سیستم هماهنگ باشد. راهنمای EOL Ubuntu نیز صراحتاً
توصیه می‌کند Codename را تغییر ندهید و فقط دامنه Repository را به Old Releases منتقل کنید. :contentReference[oaicite:3]{index=3}
اصلاح سریع Repository با یک دستور
اگر فایل sources.list شما فقط Repositoryهای استاندارد Ubuntu را دارد، می‌توانید دامنه
Repository را به Old Releases تغییر دهید. با این حال، قبل از اجرای دستور، حتماً از فایل
پشتیبان گرفته باشید.
sudo sed -i \
's|archive.ubuntu.com/ubuntu|old-releases.ubuntu.com/ubuntu|g;
s|security.ubuntu.com/ubuntu|old-releases.ubuntu.com/ubuntu|g' \
/etc/apt/sources.listسپس محتوای فایل را بررسی کنید:
cat /etc/apt/sources.listاین روش فقط دامنه Repository را تغییر می‌دهد و Codename را دستکاری نمی‌کند.
حالا apt update را اجرا کنید
sudo apt updateاگر Repositoryها صحیح باشند، APT باید بتواند فایل‌های Release و فهرست بسته‌ها را از آرشیو
دریافت کند. Old Releases در حال حاضر مجموعه بزرگی از نسخه‌های قدیمی Ubuntu را نگهداری می‌کند،
از جمله نسخه‌هایی مانند 18.04، 20.04 و بسیاری از نسخه‌های قدیمی‌تر. :contentReference[oaicite:4]{index=4}
اگر خطای Release file expired دریافت کردیم چه کنیم؟
خطای Release file is expired با خطای نبودن Repository یکسان نیست.
در این وضعیت باید ابتدا ساعت و تاریخ سیستم را بررسی کنید؛ چون APT برای اعتبارسنجی متادیتای
Repository از زمان سیستم استفاده می‌کند.
timedatectl statusاگر زمان سیستم اشتباه است، NTP را فعال کنید:
sudo timedatectl set-ntp true
timedatectl statusبعد دوباره فهرست بسته‌ها را دریافت کنید:
sudo apt updateاگر خطای 404 Not Found داشتیم
خطای 404 معمولاً یعنی APT به مسیری مراجعه کرده که برای نسخه یا Repository موردنظر در دسترس نیست.
ابتدا Repositoryهای فعال را بررسی کنید.
grep -RhsE '^[[:space:]]*deb ' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/nullاگر Repository شخص ثالثی مربوط به نسخه قدیمی در خروجی وجود دارد، ممکن است همان Repository
باعث خطا شده باشد. در این شرایط لازم نیست همه خطاها را به Ubuntu نسبت دهید؛ Repositoryهای
مربوط به نرم‌افزارهای جانبی را نیز جداگانه بررسی کنید.
اگر خطای does not have a Release file نمایش داده شد
این خطا معمولاً زمانی دیده می‌شود که APT برای مسیر مشخصی فایل Release پیدا نمی‌کند.
یکی از دلایل آن استفاده از Repository اشتباه، Codename اشتباه یا نگهداری نشدن نسخه در
مخزن معمولی است.
اگر نسخه Ubuntu شما EOL است، استفاده از ساختار Old Releases راهکار مناسب‌تری برای دسترسی
موقت به بسته‌های همان نسخه است. مستندات EOL Ubuntu نیز ساختار Repository را با
old-releases.ubuntu.com ارائه می‌کنند. :contentReference[oaicite:5]{index=5}
Repositoryهای اضافی را هم بررسی کنید
گاهی apt update همچنان خطا می‌دهد، چون یک Repository خارجی در
/etc/apt/sources.list.d/ فعال است.
grep -RhsE '^[[:space:]]*deb ' /etc/apt/sources.list.d/ 2>/dev/nullاگر Repository متعلق به نرم‌افزاری است که دیگر برای نسخه Ubuntu شما بسته ارائه نمی‌کند،
می‌توانید فایل مربوط به آن را موقتاً غیرفعال کنید.
برای مثال:
sudo mv /etc/apt/sources.list.d/example.list \
/etc/apt/sources.list.d/example.list.disabledسپس دوباره APT را آزمایش کنید:
sudo apt updateتفاوت Repository معمولی و Old Releases
| ویژگی | Repository معمولی | Old Releases |
|---|---|---|
| هدف | نسخه‌های جاری و پشتیبانی‌شده | آرشیو نسخه‌های قدیمی |
| مناسب برای EOL | معمولاً خیر | بله، برای دسترسی آرشیوی |
| دریافت به‌روزرسانی امنیتی جدید | بسته به چرخه پشتیبانی | خیر؛ آرشیو نسخه قدیمی است |
| کاربرد اصلی | استفاده روزمره از نسخه پشتیبانی‌شده | بازیابی، تعمیر و آماده‌سازی برای ارتقا |
بعد از رفع خطا، آیا باید Ubuntu را ارتقا دهیم؟
اگر سرور شما واقعاً EOL است، بهتر است Old Releases را راهکار نهایی در نظر نگیرید.
هدف منطقی این است که ابتدا APT را دوباره قابل استفاده کنید، بسته‌های لازم برای مدیریت
سرور را نصب یا تعمیر کنید و سپس برای ارتقای سیستم‌عامل برنامه‌ریزی کنید.
چرخه پشتیبانی Ubuntu بین نسخه‌های مختلف متفاوت است. Ubuntu اعلام می‌کند نسخه‌های LTS
در مجموع تا ۱۰ سال چرخه نگهداری دارند، شامل ۵ سال پشتیبانی استاندارد و ۵ سال ESM،
در حالی که نسخه‌های Interim معمولاً ۹ ماه پشتیبانی می‌شوند. :contentReference[oaicite:6]{index=6}
🔹 از فایل‌های مهم و دیتابیس‌ها بکاپ بگیرید.
🔹 وضعیت فضای دیسک را بررسی کنید.
🔹 سرویس‌های فعال را فهرست کنید.
🔹 وضعیت SSH و دسترسی کنسول VPS را بررسی کنید.
🔹 فایل‌های Repository شخص ثالث را شناسایی کنید.
🔹 مسیر ارتقا بین نسخه فعلی و مقصد را بررسی کنید.
بررسی فضای دیسک قبل از تعمیر یا ارتقا
df -hاگر پارتیشن روت تقریباً پر باشد، APT ممکن است در زمان دانلود یا نصب بسته‌ها با خطاهای
دیگری مواجه شود. بنابراین قبل از اجرای عملیات بزرگ، وجود فضای کافی را بررسی کنید.
بررسی وضعیت بسته‌های نیمه‌نصب‌شده
اگر قبل از بروز خطا عملیات نصب یا ارتقا متوقف شده است، وضعیت بسته‌های سیستم را بررسی کنید:
dpkg --auditدر صورت وجود بسته‌های نیمه‌پیکربندی‌شده، پس از اصلاح Repository می‌توانید وضعیت APT را
با دستور زیر تکمیل کنید:
sudo dpkg --configure -aسپس:
sudo apt -f installیک سناریوی کامل برای Ubuntu 20.04 EOL
فرض کنید VPS شما Ubuntu 20.04 با Codename برابر focal دارد و هنگام
apt update با خطای Repository مواجه شده است. ترتیب پیشنهادی بررسی به این صورت است:
cat /etc/os-release
sudo cp /etc/apt/sources.list /etc/apt/sources.list.backup
sudo sed -i \
's|archive.ubuntu.com/ubuntu|old-releases.ubuntu.com/ubuntu|g;
s|security.ubuntu.com/ubuntu|old-releases.ubuntu.com/ubuntu|g' \
/etc/apt/sources.list
sudo apt updateاگر دستور آخر بدون خطای Repository اجرا شد، وضعیت APT دوباره قابل استفاده است.
از این مرحله به بعد می‌توانید بسته‌های موردنیاز را مدیریت کنید و برای ارتقای نسخه برنامه‌ریزی کنید.
چه زمانی نباید فقط Repository را تغییر دهیم؟
اگر سرور شما نسخه‌ای دارد که هنوز تحت پشتیبانی است، صرفاً به دلیل یک خطای APT نباید
آن را به Old Releases منتقل کنید. ابتدا DNS، اتصال شبکه، تاریخ سیستم، فایل‌های Repository
و Repositoryهای شخص ثالث را بررسی کنید.
همچنین اگر هدف شما فقط نصب یک نرم‌افزار قدیمی است، تغییر کل Repositoryهای سیستم می‌تواند
تصمیم مناسبی نباشد. ابتدا مشخص کنید خطا دقیقاً از کدام Repository ایجاد شده است.
چک‌لیست نهایی رفع خطای Repository
🔹 نسخه Ubuntu را با cat /etc/os-release بررسی کنید.
🔹 Codename واقعی نسخه را مشخص کنید.
🔹 از /etc/apt/sources.list بکاپ بگیرید.
🔹 Repositoryهای شخص ثالث را بررسی کنید.
🔹 در نسخه EOL، Repository مربوط به همان Codename را به Old Releases منتقل کنید.
🔹 تاریخ و ساعت سیستم را با timedatectl بررسی کنید.
🔹 sudo apt update را اجرا کنید.
🔹 در صورت نیاز بسته‌های نیمه‌نصب‌شده را با dpkg –configure -a بررسی کنید.
🔹 پس از بازیابی APT، برای ارتقا از نسخه EOL برنامه‌ریزی کنید.
VPS مناسب برای اجرای سرویس‌های لینوکسی
اگر برای اجرای Ubuntu Server، Docker، وب‌سرور، پنل مدیریت یا سرویس‌های پردازشی
به VPS نیاز دارید، می‌توانید مشخصات سرور را متناسب با مصرف CPU، RAM، دیسک و شبکه انتخاب کنید.
ایرانیکاسرور | مشاوره و پشتیبانی سرور
91302467-021
سوالات متداول
چرا apt update در Ubuntu EOL خطای Release file می‌دهد؟
چون نسخه‌های قدیمی ممکن است دیگر از Repositoryهای معمول ارائه نشوند و باید برای
دسترسی آرشیوی از Old Releases استفاده شود.
آیا استفاده از old-releases.ubuntu.com امن است؟
Old Releases برای نگهداری نسخه‌های قدیمی Ubuntu استفاده می‌شود، اما نباید آن را
معادل دریافت به‌روزرسانی‌های امنیتی جدید دانست. برای سرور تولیدی، ارتقا به نسخه پشتیبانی‌شده
اهمیت دارد.
آیا باید Codename را هنگام اصلاح Repository تغییر دهیم؟
خیر. اگر نسخه نصب‌شده مثلاً focal است، Repository باید برای همان نسخه تنظیم شود.
راهنمای EOL Ubuntu نیز تغییر ندادن Codename و تغییر دامنه به Old Releases را توصیه می‌کند.
چرا بعد از تغییر sources.list هنوز apt update خطا می‌دهد؟
ممکن است Repository شخص ثالث، تاریخ اشتباه سیستم، DNS، شبکه یا یک فایل اضافی در
/etc/apt/sources.list.d/ عامل خطا باشد.
بعد از رفع خطای Repository چه کاری انجام دهیم؟
APT را آزمایش کنید، بسته‌های نیمه‌نصب‌شده را بررسی کنید و سپس برای انتقال سرور
از نسخه EOL به یک نسخه پشتیبانی‌شده برنامه‌ریزی کنید.
آیا می‌توان Ubuntu EOL را برای همیشه با Old Releases نگه داشت؟
از نظر فنی ممکن است دسترسی آرشیوی ادامه داشته باشد، اما برای سرور حساس و تولیدی
نباید آن را جایگزین چرخه پشتیبانی و دریافت اصلاحات امنیتی دانست.
جمع‌بندی:
خطاهای Release file، 404 Repository و
does not have a Release file در Ubuntu EOL معمولاً به وضعیت قدیمی
Repositoryها مربوط می‌شوند. ابتدا نسخه و Codename واقعی را شناسایی کنید، از تنظیمات
APT بکاپ بگیرید و در صورت EOL بودن نسخه، Repository همان نسخه را به
old-releases.ubuntu.com منتقل کنید. پس از بازیابی APT، راهکار بلندمدت
برای یک VPS تولیدی، برنامه‌ریزی برای ارتقا به نسخه پشتیبانی‌شده است.
دیدگاه‌ها (۰)