حل مشكلة 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. تترك صور cloud الدنيا هذه الحزمة خارج التثبيت أحياناً.

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

لذلك لديك خياران واضحان. انتظر إصدار النقطة، وهذا هو الخيار الصحيح لأي خادم تفضّل ألّا تراقبه باستمرار. أو اضبط Prompt=normal، الذي يوجّه الأداة نفسها إلى meta-release، حيث تم تعليم 26.04 بأنه مدعوم بالفعل. يرقّيك المسار الثاني إلى إصدار 26.04 المنشور، وليس إلى إصدار تطويري، لذلك يمكن تبريره على جهاز يمكنك استعادته من snapshot. أعد القيمة إلى lts بعد الانتهاء. يرد الإجراء نفسه خطوة بخطوة في دليل ترقية الخادم الكامل من 24.04 إلى 26.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.

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

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

تستبدل ترقية الإصدار معظم مكوّنات النظام، بما في ذلك openssh-server وsystemd. إذا انقطعت جلسة SSH (الصدفة الآمنة) أثناء عمل dpkg، تُقتل العملية بعد فك حزم وتبقى غير مُعدّة، وهذه هي الحالة التي تمنع محاولتك التالية. ابدأ الترقية داخل مُعدِّد أطراف في كل مرة.

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.

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

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

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

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

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

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