حل خطأ do-release-upgrade: لم يُعثر على إصدار جديد

لماذا يقول do-release-upgrade إنه لم يعثر على إصدار جديد

do-release-upgrade الذي ينتهي بـ No new release found. لا يكون عادةً أداة معطّلة. يكون المسار الذي طلبته مغلقاً في تلك اللحظة، وتعرض الأداة ذلك بأقصر صيغة ممكنة. هناك خمسة أسباب لإغلاقه: إعداد Prompt في /etc/update-manager/release-upgrades، وحاجز الإصدار المرحلي عند الترقية بين إصدارات LTS (الدعم طويل الأمد)، ومستودعات الجهات الخارجية، والحزم المعلّقة أو غير المكتملة الإعداد، وإصدار انتهى دعمه.

تحقّق من هذه الأسباب بالترتيب. لكل سبب أمر يثبت ما إذا كان ينطبق على خادمك، لذلك لن تضطر إلى التخمين لمعرفة أيٍّ من الأسباب الخمسة تواجهه.

ما الذي يعرضه خيار التحقق فقط فعلياً

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.

يحمل رمز الخروج النتيجة نفسها للبرامج النصية. تكون قيمته 0 عند توفر إصدار، و1 عند عدم توفره. وهذا عكس الاصطلاح المعتاد في shell، لذلك اقرأه بعناية قبل بناء عملية تحقق تعتمد عليه.

إذا ظل شريط تسجيل الدخول يعرض النتيجة القديمة، فهذه النتيجة مخزنة مؤقتاً. يأتي هذا السطر من /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 فيعني أن قواعد الخروج هي السبب الفعلي، ولن يغيّر تحرير ملفات 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 للخادم الذي تريد إبقاءه على مسار الدعم طويل الأجل، ثم أعده إلى قيمته السابقة إذا كانت أدوات التشغيل الآلي لديك تتوقع القيمة القديمة.

تتضمن تلك التعليقات تفصيلاً يسبب الالتباس. عندما تكون 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

عند التحقق في 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، لكن جداول الإصدارات قد تتغير، لذلك تحقّق من البيانات الوصفية بدلاً من الاعتماد على التقويم. إصدار النقطة ليس نسخة جديدة من Ubuntu، بل الإصدار نفسه مع دمج كل التحديثات منذ الإطلاق في وسائط تثبيت جديدة. لذلك، ما يهم الخادم الذي يعمل فعلياً هو البوابة التي يفتحها، لا وسائط التثبيت نفسها. هذا التأخير مقصود: يكتشف الأشخاص الذين يجرون الترقية مبكراً المشكلات التي تمنع الترقية، ثم تُصلح هذه المشكلات قبل أن تتبعهم المجموعة الأكبر بكثير من خوادم LTS. إذا كان ذلك التاريخ قد مرّ عند قراءتك لهذا النص، فستتابع ما الذي جاء مع 26.04.1 وما الذي يعنيه ذلك لخادم 24.04 شرح الموضوع من تلك النقطة.

لديك خياران واضحان. انتظر إصدار النقطة، وهذا هو القرار الصحيح لأي خادم تفضّل ألا تراقبه أثناء الترقية. أو اضبط Prompt=normal، الذي يوجّه الأداة نفسها إلى meta-release، حيث تم تعليم 26.04 على أنه مدعوم. يرقّيك المسار الثاني إلى إصدار 26.04 المنشور، وليس إلى إصدار تطويري، لذلك يمكن تبريره على جهاز تستطيع استعادته من snapshot. أعد القيمة إلى lts بعد الانتهاء. تجد الإجراء نفسه، خطوة بخطوة، في الدليل الكامل لترقية الخادم من 24.04 إلى 26.04. أما الخادم الذي لا يزال يعمل بـ22.04، فعليه تنفيذ قفزة إضافية، لأن Prompt=lts لا يعرض إلا إصدار LTS التالي دائماً، ولذلك يمر المسار من 22.04 إلى 26.04 أولاً عبر 24.04.

المستودعات الخارجية وPPAs التي تعيق الترقية

يعيد برنامج الترقية كتابة مصادر APT لتشير إلى الإصدار الجديد. ولا يمكنه فعل ذلك إلا لمستودع ينشر حزماً للإصدار الجديد، لذلك يُعلّق أي مصدر آخر. تُطبع الأسباب في سطر واحد لكل إدخال، وهي محددة: was disabled (unknown mirror)، وwas disabled (unknown dist)، وwas disabled (no Release file).

لا يحتوي الخادم على مجلد لـresolute خاص بـPPA (أرشيف الحزم الشخصي) المبني للإصدار noble، لذلك لا يستطيع برنامج الترقية جلب ملف 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 على Ubuntu.

يوجد خيار لاتخاذ القرار المعاكس. تصف الصفحة اليدوية --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 الحزم المحجوزة، حزمة واحدة في كل سطر، ولا يطبع شيئاً إطلاقاً في النظام السليم. الحجز هو تعليمات يدوية بعدم تغيير تلك الحزمة مطلقاً. ربما ثبّت أحدهم إصدار kernel أو إصدار قاعدة بيانات، ثم نسي ذلك. ألغِ حجز الحزم التي لم تعد تحتاج إليها باستخدام 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

يؤثر خيار التحديثات المرحلية أكثر مما يبدو. تطرح Ubuntu بعض التحديثات تدريجياً على نسبة مئوية من الأجهزة في كل مرة. لذلك يمكن أن يترك apt upgrade العادي حزمَاً خلفه بصورة صحيحة، ويصبح الخادم عندئذ أقل تحديثاً مما تعتقد. يثبّت ذلك الخيار جميع التحديثات. أعد التشغيل بعد ذلك إذا تضمنت التحديثات kernel، حتى تنفذ الترقية من kernel الذي يعمل عليه النظام فعلياً. أما الخادم الذي يحافظ على تحديث نفسه مسبقاً عبر ترقيات الأمان غير المراقبة، فسيكون لديه عمل أقل هنا، مع أن هذه الآلية لا تتجاوز حدود الإصدار بحكم تصميمها.

عندما يتجاوز الإصدار نهاية الدعم القياسي

يُدعَم إصدار Ubuntu المؤقت لمدة تسعة أشهر. عند انتهاء هذا الدعم، تتغير قيمة 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، ولا يعود بالإمكان تحديث النظام، وبما أن أداة الترقية تشترط أن يكون النظام محدثاً، فلا يتقدم شيء. أصلح مصادر الحزم أولاً.

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 أداة الترقية تقرأ meta-release-development بدلاً من الملف الذي حدده Prompt. يصفه الدليل بأنه: «إذا كنت تستخدم أحدث إصدار مدعوم، فقم بالترقية إلى إصدار التطوير».

عند التحقق في 13 أغسطس 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) في بيئات الإنتاج». يتغير إصدار التطوير يومياً، ولا يتضمن التزاماً بدعم أمني. لذلك قد تتسبب حزمة تعمل صباحاً في تعطل خدمة بعد الظهر. استخدمه على آلة افتراضية مؤقتة أنشأتها لاختبار إعداداتك. لا تستخدمه على خادم يعتمد عليه أي مستخدم. عندما تريد الإصدار 26.04 الصادر قبل فتح بوابة LTS، فإن Prompt=normal هو المسار الصحيح.

نفّذ الترقية بحيث لا تؤدي جلسة SSH المنقطعة إلى إيقافها

تستبدل ترقية الإصدار معظم مكوّنات النظام، بما في ذلك openssh-server وsystemd. إذا توقفت جلسة SSH (الصدفة الآمنة) أثناء عمل dpkg، تُقتل العملية بعد فك حزم وتبقى أخرى غير مهيّأة. وهذه هي الحالة التي تمنع محاولتك التالية. إذا حدث ذلك بالفعل، فإن استرداد ترقية توقفت في منتصفها مهمة مستقلة، ويجب تنفيذها قبل أي محاولة ثانية. ابدأ الترقية داخل 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 المهمة نفسها إذا كنت تفضّل screen.

توفّر أداة الترقية آلية حماية للمستخدمين الذين لا يستعملون terminal multiplexer. فعندما تكتشف أنها تعمل عبر SSH، تعرض تشغيل sshd ثانٍ على المنفذ 1022، بحيث تظل هناك طريقة للدخول إذا تعطلت الجلسة الرئيسية. وتتحقق من ذلك عبر تتبّع العمليات الأصلية الخاصة بها بحثاً عن عملية باسم sshd. داخل tmux أو screen، يعثر هذا التتبع بدلاً من ذلك على خادم terminal multiplexer، ولذلك لا يظهر العرض، ولا يُكتب ملف pid ‏/var/run/release-upgrader-sshd.pid إلا عند تشغيل daemon الإضافي فعلياً. عدم ظهور المطالبة ليس مشكلة. فلديك بالفعل حماية أفضل.

إذا وافقت على العرض، فلن يُفتح المنفذ تلقائياً. توضّح الأداة ذلك صراحة، لأن فتح منفذ قرار أمني لا يحق لها اتخاذه نيابةً عنك. افتحه طوال مدة الترقية، ثم أغلقه مجدداً.

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

يشغّل معظم مزوّدي VPS جداراً نارياً ثانياً في لوحة التحكم الخاصة بهم، خارج نظام التشغيل. ويجب فتح المنفذ 1022 هناك أيضاً، وإلا فسيكون المستمع الاحتياطي قيد التشغيل لكنه غير قابل للوصول، وهذه أسوأ نتيجة ممكنة.

يجب تجهيز أربعة أمور قبل كتابة الأمر:

• أنشئ snapshot أو نسخة احتياطية كاملة. لا تتضمن ترقية الإصدار في مكانه إمكانية التراجع، وهذه هي النسخة الوحيدة التي ستحصل عليها.
• تأكد من قدرتك على فتح وحدة تحكم المزوّد قبل أن تحتاج إليها. إذا لم يعد الخادم بعد إعادة التشغيل، فلن يتوفر لك SSH تحديداً. وفشل kernel في الإقلاع مشكلة مستقلة لها خطوات استرداد خاصة بها، ومذكورة في VPS لا يقلع بعد تحديث kernel.
• افحص المساحة الحرة باستخدام df -h / /boot. تنزّل الترقية مجموعة كاملة من الحزم، ويُعدّ قسم /boot الذي يحتوي على عدة kernels قديمة مكاناً شائعاً للتوقف.
• اقرأ ملاحظات الإصدار الخاصة بالخدمات التي تشغّلها. تأتي قفزة الإصدار الرئيسية في 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 على 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 المُصدَر، وليس إلى إصدار قيد التطوير، لأن Prompt=normal يقرأ meta-release، حيث يحمل 26.04 القيمة Supported: 1 بالفعل. تكمن المخاطرة في التوقيت. ستجري الترقية قبل إصلاح المشكلات التي اكتشفها المستخدمون الأوائل. نفّذ ذلك على خادم يمكنك استعادته من snapshot، وتستطيع الوصول فيه إلى وحدة تحكم المزوّد إذا فشلت عملية إعادة التشغيل. أعد القيمة إلى 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 الخاصة بالخوادم أن الإصدار قيد التطوير غير موصى به لبيئات الإنتاج، لذلك استخدم Prompt=normal عندما تريد تثبيت 26.04 المُصدَر مبكراً.

يعرض 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 ترقيته إصداراً واحداً في كل مرة.

هل أحتاج إلى إزالة PPAs الخاصة بي قبل تشغيل do-release-upgrade؟

لا يلزم ذلك، لأن برنامج الترقية يعطّل بالتعليق أي مصدر لا ينشر حزماً للإصدار الجديد، ويطبع سطراً مثل was disabled (no Release file) لكل مصدر. لكن تنفيذ ذلك بنفسك أولاً أفضل، لأنك تختار الترتيب وترى النتيجة. شغّل apt policy على الحزم التي تهمك لمعرفة الحزم التي جاءت من كل PPA، ثم أعد تثبيت تلك الحزم من الأرشيف إذا كان إصدار PPA أحدث من الإصدار المتاح في الإصدار الجديد.