ترقية Ubuntu 24.04 إلى 26.04 على VPS

متى يمكنك ترقية Ubuntu 24.04 إلى 26.04؟

يمكنك ترقية Ubuntu 24.04 إلى 26.04 على VPS بعد صدور الإصدار النقطي 26.04.1، والمقرر صدوره في 27 August 2026. وحتى ذلك الحين، لن يعرض خادم 24.04 الإصدار الجديد، وهذا مقصود. صدر Ubuntu 26.04 LTS (Resolute Raccoon) في 23 April 2026، لكن Canonical لا تتيح مسار الترقية من إصدار LTS إلى إصدار LTS إلا عند صدور الإصدار النقطي الأول، لأن هذا الإصدار يضم إصلاحات مشكلات التثبيت والترقية التي اكتُشفت خلال الأشهر الأولى.

شغّل الفحص على خادم 24.04 في أوائل August 2026، وستحصل على الآتي:

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

لا يشير ذلك إلى وجود عطل في خادمك. يحتوي /etc/update-manager/release-upgrades على Prompt=lts في Ubuntu Server، وهذا يعني أن الأداة لا تعرض إلا إصدار الدعم طويل الأمد التالي، وفقط بعد صدور الإصدار النقطي .1. أما ضبط Prompt=normal فسيرشدك بدلاً من ذلك عبر 24.10 ثم 25.04 ثم 25.10، وهي إصدارات مؤقتة انتهى دعمها جميعاً. اتركه مضبوطاً على lts وانتظر. قد تتغير التواريخ في جدول Canonical، لذا أعد الفحص إذا مرّ الموعد دون حدوث شيء.

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

هل ينبغي الترقية أصلاً؟

يتلقى Ubuntu 24.04 تحديثات أمان قياسية حتى 2029، لذلك لا يواجه خادم الإنتاج العامل أي موعد نهائي للترقية. أجرِ الترقية لأنك تحتاج إلى ما يقدمه 26.04، مثل PHP 8.5 أو PostgreSQL 18 أو MySQL 8.4 LTS أو OpenSSH 10.2 أو kernel 7.0. لا تُعدّ زيادة رقم الإصدار سبباً كافياً للمساس بجهاز يخدم العملاء.

لا تُجرِ الترقية على الخادم نفسه إذا انطبق أي مما يلي:

• لم تفتح أبداً وحدة التحكم الخاصة بمزود الخدمة، سواء عبر VNC أو serial، ولم تسجّل الدخول من خلالها. وحدة التحكم هذه هي الطريقة الوحيدة لاستعادة الوصول إلى الخادم إذا تعطل SSH. واكتشاف أنها لا تعمل بعد فقدان الوصول يكون متأخراً.
• لا يمكنك تحمّل ساعة من التوقف، ولا تملك خطة rollback.
• يعتمد النظام لديك على مستودع تابع لجهة خارجية لم ينشر حزمته لـ resolute بعد.
• بُني الخادم يدوياً منذ أكثر من عامين، ولا يعرف أحد ما المثبّت عليه.

غالباً ما يكون البديل أفضل: أنشئ VPS جديداً يعمل بـ26.04، وثبّت المكدس واستعد البيانات، ثم بدّل DNS بعد التأكد من أن الخادم الجديد يستجيب بشكل صحيح. أبقِ الخادم القديم قيد التشغيل حتى يثبت الخادم الجديد جاهزيته، وعندها تصبح استعادة الوضع السابق مجرد تغيير في DNS بدلاً من استعادة نسخة احتياطية. إذا اخترت هذا المسار، فابدأ بـالدقائق العشر الأولى على VPS جديد وأنشئ الخادم الجديد بطريقة صحيحة.

الخطوة 1: أنشئ نسخة احتياطية يمكنك الاستعادة منها

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

أنشئ تفريغاً لقواعد البيانات يدوياً أولاً. التفريغ هو نسخة قاعدة البيانات الاحتياطية الوحيدة التي يمكنك الوثوق بها من دون إيقافها.

sudo -u postgres pg_dumpall | sudo tee /var/backups/pg-all.sql > /dev/null
sudo mysqldump --all-databases --single-transaction --routines | sudo tee /var/backups/mysql-all.sql > /dev/null
sudo tar czf /var/backups/etc-before-upgrade.tgz -C / etc
sudo chmod 600 /var/backups/pg-all.sql /var/backups/mysql-all.sql

ينشئ --single-transaction تفريغاً متسقاً لجداول InnoDB فقط. يجب إيقاف قاعدة البيانات عند استخدام جداول MyISAM. أما أرشيف /etc بصيغة tar، فهو الذي ستستخدمه فعلياً، لأنه يحتوي على كل ملف إعداد سيسألك عنه التحديث.

النسخة الاحتياطية التي لم تستعد منها من قبل ليست سوى تخمين. استخرج ملفاً واحداً منها الآن، قبل أن تحتاج إليه تحت الضغط.

الخطوة 2: ثبّت جميع التحديثات في 24.04 أولاً

يرفض do-release-upgrade العمل على نظام في حالة حزم غير سليمة، كما أن تثبيت تحديثات 24.04 جزئياً يجعل تفسير كل فشل لاحق أصعب.

sudo apt update
sudo apt full-upgrade
sudo apt --purge autoremove
sudo dpkg --audit
apt-mark showhold

إذا لم يطبع dpkg --audit أي شيء، فهذا يعني أنه لا توجد حزمة في حالة إعداد غير مكتملة. وإذا لم يطبع apt-mark showhold أي شيء، فهذا يعني أنه لا توجد حزمة مثبتة على إصدار يمنع الترقية. ألغِ تثبيت أي حزمة يعرضها باستخدام sudo apt-mark unhold واسم الحزمة، أو أقرّ بوجود التثبيت المقيّد لسبب وجيه وتوقّف هنا.

أعِد التشغيل إذا تغيّرت النواة، حتى تجري الترقية من جهاز يشغّل الشيفرة التي يعتقد أنه يشغّلها.

[ -f /var/run/reboot-required ] && sudo reboot

تحقق بعد ذلك من مساحة القرص. ينزّل برنامج الترقية مجموعة الحزم الجديدة بالكامل قبل تثبيت أي شيء، ويتوقف برسالة تذكر نظام الملفات إذا لم تتوفر مساحة كافية.

df -h / /boot

تبدأ المشكلة عادةً عند انخفاض المساحة الحرة على / عن نحو 5 GB. ويفشل /boot عندما تقل المساحة الحرة عن 300 MB، وذلك لاحقاً أثناء تثبيت النواة، مع ظهور No space left on device. تكون النوى القديمة هي السبب عادةً، ويزيلها sudo apt --purge autoremove.

هناك أمر آخر يجب إيقافه قبل البدء: إذا شُغّلت التحديثات الأمنية التلقائية أثناء العملية، فإنها تحجز قفل dpkg، ويتوقف برنامج ترقية الإصدار مع ظهور Could not get lock /var/lib/dpkg/lock-frontend. شغّل sudo systemctl stop unattended-upgrades أولاً، ثم ابدأ الترقية من جديد بعد انتهائه.

الخطوة 3: تحقّق من المستودعات الخارجية والحزم المثبّتة بإصدارات محددة

يعطّل do-release-upgrade كل مصدر apt ليس تابعاً لـUbuntu، لأن الحزمة المبنية لـnoble قد تتسبب في تعطل نظام resolute. ثم يعيد تفعيل المصادر التي يتعرّف إليها، ويترك المصادر الأخرى معلّقة بالتعليقات. اعرف ما أضفته إلى النظام قبل أن تتخذ الأداة القرار نيابةً عنك.

ls /etc/apt/sources.list.d/
grep -rhE '^(deb |Types:|URIs:|Suites:)' /etc/apt/sources.list.d/
ubuntu-security-status --thirdparty
ls /etc/apt/preferences.d/

يستخدم Ubuntu 24.04 تنسيقين في ذلك المجلد: ملفات .list القديمة ذات السطر الواحد، وملفات .sources بتنسيق deb822 التي تحتوي على الحقلين Types: وSuites:. يعطّل الترقية كلا التنسيقين. يسرد ubuntu-security-status --thirdparty الحزم المثبّتة التي لا يوفّرها أي أرشيف Ubuntu، وهذا هو العدد الفعلي لما أضفته إلى النظام. كل ما يرد في /etc/apt/preferences.d/ هو تثبيت إصدار محدد، وسيستمر التثبيت المحدد لـnoble في اختيار حزمة قديمة ضمن الإصدار الجديد.

لكل مستودع خارجي، تأكّد من أن المورّد نشر حزم للإصدار ذي الاسم الرمزي الجديد قبل أن تبدأ. تُدرج مجموعات Docker في https://download.docker.com/linux/ubuntu/dists/، ويستخدم المورّدون الآخرون الدليل نفسه. إذا أُشير في المصدر إلى مجموعة غير موجودة، فستظهر الرسالة التالية عند تنفيذ أول apt update بعد الترقية:

E: The repository 'https://download.docker.com/linux/ubuntu resolute Release' does not have a Release file.

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

الخطوة 4: شغّل الترقية داخل tmux، وليس في جلسة SSH عادية

إذا انقطع اتصالك أثناء تشغيل do-release-upgrade في جلسة تسجيل دخول عادية، فستتلقى العملية الإشارة SIGHUP وتتوقف أثناء فك الحزم. يؤدي ذلك إلى بقاء dpkg مُهيّأً جزئياً، وقد يترك الخادم من دون مكدس شبكة يعمل، فلا تتمكن من الاتصال به مجدداً. شغّل العملية داخل مُعدِّد طرفيات بدلاً من ذلك، كي تظل قيد التشغيل على الخادم عند انقطاع اتصال العميل.

sudo apt install -y tmux
tmux new -s upgrade

داخل تلك الجلسة:

sudo ufw allow 1022/tcp
sudo do-release-upgrade

يبدأ برنامج الترقية خدمة SSH ثانية على المنفذ 1022 قبل أن يغيّر أي شيء، ويعرض رسالة بذلك:

To make recovery in case of failure easier, an additional sshd will be started on port '1022'. If anything goes wrong with the running ssh you can still connect to the additional one.

لا يفتح البرنامج المنفذ في جدارك الناري، لأن فتح منفذ في الجدار الناري من دون طلب صريح سيكون مفاجئاً وغير مناسب. افتح المنفذ 1022 بنفسك قبل البدء، وأغلقه عند الانتهاء من sudo ufw delete allow 1022/tcp. تذكّر أن مزود الخدمة قد يشغّل جداراً نارياً ثانياً في لوحة التحكم الخاصة به، خارج الخادم.

إذا انقطع الاتصال رغم ذلك، سجّل الدخول مجدداً وشغّل tmux attach -t upgrade. استمرت الترقية في العمل أثناء غيابك.

الخطوة 5: أجب عن مطالبات ملف الإعدادات بتأنٍّ

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

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** sshd_config (Y/I/N/O/D/Z) [default=N] ?

اضغط D أولاً في كل مرة. اقرأ التغييرات، ثم احتفظ بنسختك باستخدام N. الخيار الافتراضي هو N، وهو الإجابة الآمنة، لأن ملفك يعمل حالياً، بينما لم يُشغَّل الملف المضمّن في الحزمة من قبل على هذا الجهاز.

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

sudo find /etc -name '*.dpkg-dist' -o -name '*.dpkg-new'

كل ملف تعرضه القائمة هو نسخة المشرف على الحزمة، وقد حُفظ بجوار نسختك. قارن بينهما واحداً تلو الآخر، وانسخ الإعدادات المهمة. يستحق ملفان عناية إضافية: /etc/ssh/sshd_config، لأن الإجابة الخاطئة تنهي جلستك، وملف إعداد خادم الويب، لأن الإجابة الخاطئة توقف المواقع.

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

الخطوة 6: أعد التشغيل، ثم تحقّق من الجهاز

sudo reboot

عند عودته للعمل:

lsb_release -a
uname -r
systemctl --failed
journalctl -p err -b --no-pager | head -50
sudo apt update && sudo apt full-upgrade
sudo apt --purge autoremove

يجب أن يعرض lsb_release -a القيمتين Release: 26.04 وCodename: resolute. يجب أن يعرض uname -r نواة بإصدار 7.0. يجب أن يسرد systemctl --failed صفراً من الوحدات، وأي وحدة يسردها تمثل مهمتك التالية. ينزّل apt update الأخيرةَ المنشورة منذ إنشاء صور الإصدار.

PostgreSQL 16 إلى 18: عنقود يبقى قديماً بصمت

تأتي Ubuntu 24.04 مع PostgreSQL 16، وتأتي 26.04 مع PostgreSQL 18. يثبّت الترقية الإصدار 18 إلى جانب الإصدار 16، ولا تنقل بياناتك. تنشئ طبقة Debian ‏postgresql-common عنقوداً جديداً وفارغاً للإصدار الرئيسي الجديد على أول منفذ متاح، لذلك يحتفظ الإصدار 16 بالمنفذ 5432 وبجميع بياناتك، بينما يبقى الإصدار 18 فارغاً على المنفذ 5433. يستمر تطبيقك في الاتصال بالمنفذ 5432، ولا يبدو أن هناك مشكلة، ولهذا يكتشف الناس الأمر بعد مرور أشهر.

pg_lsclusters

يعني ظهور عنقودين في القائمة أنك لم تنفّذ الترحيل. نفّذه عندما تتمكن من إيقاف التطبيق:

sudo pg_dropcluster --stop 18 main
sudo pg_upgradecluster 16 main
pg_lsclusters
sudo -u postgres vacuumdb --all --analyze-only

احذف عنقود الإصدار 18 الفارغ أولاً، لأن pg_upgradecluster لن يكتب في عنقود هدف موجود مسبقاً. تنشئ الطريقة الافتراضية تفريغاً من الإصدار 16 ثم تعيد تحميله في الإصدار 18، لذلك تحتاج إلى مساحة قرص حرة تعادل حجم قاعدة البيانات تقريباً. تستخدم -m upgrade بدلاً من ذلك pg_upgrade، وهي أسرع بكثير مع قواعد البيانات الكبيرة. عند اكتمال العملية، اقرأ العمود Port: يستولي العنقود الجديد على المنفذ 5432، ويبقى العنقود القديم متوقفاً. نفّذ مرحلة التحليل بنفسك، لأن العنقود الذي حُمّلت إليه البيانات حديثاً لا يملك إحصاءات، وستكون الاستعلامات الأولى بطيئة.

اختبر التطبيق على العنقود الجديد لبضعة أيام. بعد ذلك فقط احذف العنقود القديم:

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

يُعد مجلد بيانات العنقود القديم أسرع خيار لاستعادة الحالة السابقة. لا تحذفه يوم الترقية.

MySQL 8.0 إلى 8.4: الخيار المحذوف الذي يوقف الخادم

ينقل 26.04 MySQL من 8.0 إلى 8.4 LTS، وهناك تغييران قد يفاجئان الخوادم.

أولاً، يرفض mysqld البدء عندما يحتوي إعدادها على خيار أزالته الإصدار الجديد. ويُعد default_authentication_plugin الخيار الأكثر شيوعاً، لأن العديد من الأدلة القديمة تطلب منك ضبطه. تفشل الخدمة، ويذكر journalctl -u mysql -n 50 المتغير غير المعروف مباشرة. احذف ذلك السطر من الملف الموجود ضمن /etc/mysql/mysql.conf.d/، ثم sudo systemctl start mysql.

ثانياً، لم تعد إضافة mysql_native_password مفعّلة افتراضياً في 8.4، ولذلك لا يستطيع أي حساب ما زال يستخدمها تسجيل الدخول إطلاقاً. تحقّق من ذلك بينما ما زلت تستخدم 8.0:

sudo mysql -e "SELECT user, host, plugin FROM mysql.user;"

انقل كل حساب يظهر له mysql_native_password قبل الترقية، ثم حدّث كلمة المرور في إعدادات تطبيقك:

ALTER USER 'appuser'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'a new password';

إذا كانت مكتبة العميل قديمة جداً ولا تستطيع استخدام caching_sha2_password، يمكنك إعادة تفعيل الإضافة القديمة في 8.4 بإضافة mysql_native_password=ON ضمن [mysqld]. تعامل مع ذلك كحل مؤقت له موعد انتهاء، لأن هذه الإضافة في طريقها إلى الإزالة بالكامل.

PHP من 8.3 إلى 8.5: ملفات vhost تشير إلى socket لم يعد موجوداً

يأتي Ubuntu 24.04 مع PHP 8.3، بينما يأتي Ubuntu 26.04 مع PHP 8.5. تُثبّت الحزم الملفات في مسارات مرتبطة بالإصدار، ولا تعيد كتابة إعدادات خادم الويب. لذلك يشير ملف vhost في nginx الذي يحتوي على fastcgi_pass unix:/run/php/php8.3-fpm.sock; الآن إلى socket لا تنشئه أي عملية، فتُرجع كل طلبات PHP الخطأ 502، ويعرض سجل أخطاء nginx ما يلي:

connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory)

وجّه الإعداد إلى socket الجديد، واختبر الإعداد، ثم أعد تحميل nginx:

sudo sed -i 's/php8.3-fpm.sock/php8.5-fpm.sock/' /etc/nginx/sites-available/example.com
sudo nginx -t
sudo systemctl reload nginx

أما مع Apache وmod_php، فتختلف المشكلة: لن يبدأ Apache إطلاقاً، ويُبلغ sudo apache2ctl -t بأنه لا يستطيع تحميل libphp8.3.so لأن الملف غير موجود. الوحدة المفعّلة هي symlink إلى حزمة لم تعد موجودة.

sudo a2dismod php8.3
sudo a2enmod php8.5
sudo systemctl restart apache2

إذا أنشأت الخادم باتباع مكدس LAMP على Ubuntu 24.04، فتحقق من كلا المسارين، لأن الدليل يتركك مع اسم وحدة مرتبط بالإصدار واسم socket مرتبط بالإصدار.

لا تنتقل إعدادات الضبط في php.ini تلقائياً أيضاً. توجد memory_limit وupload_max_filesize وأي إعدادات أخرى عيّنتها في /etc/php/8.3/، بينما يبدأ شجر الإصدار الجديد من القيم الافتراضية. قارِن الملفين وانسخ القيم يدوياً. يؤدي نسخ الملف القديم بالكامل فوق الملف الجديد إلى نقل القيم الافتراضية لـ8.3 إلى تثبيت 8.5. ثم شغّل php -m وقارِن النتائج: تحتاج الإضافة المثبّتة باسم php8.3-redis إلى حزمة php8.5-، وإذا كانت مصدرها PPA، عطّل برنامج الترقية ذلك المصدر، فتكون الإضافة مفقودة ببساطة.

تحتاج الشهادات إلى فحص مستقل. شغّل sudo certbot renew --dry-run بعد الترقية. يختبر ذلك مسار التجديد بالكامل، بما في ذلك hook إعادة تحميل خادم الويب، من دون لمس الشهادة المستخدمة فعلياً. إذا كان hook يستدعي اسم خدمة أو ملفاً تنفيذياً تغيّر، فسيفشل هنا أمامك بدلاً من أن يفشل بصمت بعد 60 يوماً. يشرح Certbot مع Let's Encrypt على nginx الشكل الصحيح لهذه الـhooks.

SSH: الفشل الذي ينهي الجلسة التي تعمل فيها

موجّه sshd_config هو الموضع الذي يُخرج فيه المستخدمون أنفسهم من الخادم. تؤدي الإجابة عن Y إلى تثبيت ملف المشرف، ما يؤدي إلى إسقاط PermitRootLogin وPasswordAuthentication وAllowUsers وPort وكل سطر آخر أضفته. إذا كان جدارك الناري يسمح بمنفذ مخصص فقط، وكان الإعداد المضمّن يستمع على 22، فسيُرفض الاتصال التالي، وستكون الجلسة التي تستخدمها هي آخر جلسة متاحة لك.

امنع ذلك قبل الترقية. يبدأ /etc/ssh/sshd_config في 24.04 بـInclude /etc/ssh/sshd_config.d/*.conf، ويحتفظ OpenSSH بأول قيمة يقرأها لكل إعداد، لذلك يتغلب الملف الإضافي المضمّن في الأعلى على أي قيمة تليه. انقل إعداداتك إلى ملف لا تملكه dpkg:

sudo tee /etc/ssh/sshd_config.d/99-local.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
AllowUsers deploy
EOF
sudo chmod 644 /etc/ssh/sshd_config.d/99-local.conf
sudo sshd -t && sudo systemctl restart ssh

عندما لا يعود في /etc/ssh/sshd_config أي إعداد خاص بك، لن يعود ذلك الموجّه مهماً: فكلتا الإجابتين تحافظان على إعداداتك لأنها موجودة في ملف مختلف.

يحتاج المنفذ المخصص إلى فحص إضافي، لأنه قد لا يكون في الموضع الذي تتوقعه:

systemctl is-enabled ssh.socket

إذا طبع ذلك enabled، فإن systemd يملك منفذ الاستماع، ويتم تجاهل السطر Port في sshd_config. تستخدم Ubuntu تنشيط المقابس لـ sshd منذ 22.10، وهذا هو سبب عدم ظهور أي أثر لتعديل Port 2222. عيّن المنفذ في وحدة المقبس بدلاً من ذلك، باستخدام sudo systemctl edit ssh.socket:

[Socket]
ListenStream=
ListenStream=2222

القيمة الفارغة ListenStream= مطلوبة. فهي تمسح القيمة الموروثة، ومن دونها سيستمع المقبس على 22 وكذلك 2222. طبّق ذلك باستخدام sudo systemctl daemon-reload && sudo systemctl restart ssh.socket.

بعد الترقية، وقبل إغلاق الجلسة التي تستخدمها:

sudo sshd -t
sudo systemctl status ssh.socket --no-pager
sudo ss -lntp | grep -E ':(22|2222)'

ثم افتح طرفية ثانية على جهازك وسجّل الدخول من جديد. إن نجاح جلسة shell في تلك الطرفية الثانية هو الدليل الوحيد المعتمد. أبقِ الجلسة الأولى مفتوحة حتى تتأكد من ذلك. يشرح تأمين SSH على خادم VPS الإعدادات التي يجدر الاحتفاظ بها في الملف الإضافي.

إذا فات الأوان بالفعل، تتيح لك وحدة التحكم على الويب لدى مزود الخدمة تسجيل دخول لا يستخدم SSH مطلقاً. سجّل الدخول إليها، وأصلح الإعداد، ونفّذ sudo sshd -t، ثم أعد تشغيل الخدمة. هذه الوحدة هي تحديداً سبب اختبار الوصول إليها قبل الترقية، لا أثناءها.

FAQ

لماذا يعرض do-release-upgrade الرسالة "No new release found" على Ubuntu 24.04؟

لأن /etc/update-manager/release-upgrades يحتوي على Prompt=lts في Ubuntu Server، وهذا الإعداد لا يتيح إصدار الدعم طويل الأمد التالي إلا بعد صدور أول إصدار نقطي له. صدر Ubuntu 26.04 LTS في 23 April 2026، ومن المقرر إصدار 26.04.1 في 27 August 2026. حتى ذلك اليوم، لن يعثر خادم 24.04 على أي إصدار جديد. اترك الإعداد كما هو بدلاً من التبديل إلى Prompt=normal، لأن ذلك سيمررك عبر الإصدارات المؤقتة بدلاً من ذلك.

هل يجب إعادة تشغيل الخادم لإكمال الترقية؟

نعم. تثبّت الترقية نواة جديدة، ومكتبة C جديدة، ونظام init جديداً. ويستمر النظام قيد التشغيل في استخدام الإصدارات القديمة منها حتى يُعاد تشغيله. يطلب do-release-upgrade إعادة التشغيل في النهاية، والخادم الذي يستمر في العمل حتى "لاحقاً" يشغّل مزيجاً من إصدارين. بعد عودة الخادم، افحص uname -r للتحقق من النواة الجديدة، وsystemctl --failed للخدمات التي لم تعمل بعد إعادة التشغيل.

هل أُجري الترقية على الخادم الحالي أم أنشئ خادم 26.04 جديداً؟

أنشئ خادماً جديداً متى أمكن ذلك. يتيح لك VPS جديد تثبيت حزمة الخدمات، واستعادة البيانات، واختبار كل شيء بينما يواصل الخادم القديم استقبال حركة الشبكة. عندها يصبح التراجع تغييراً في DNS بدلاً من الاستعادة من نسخة احتياطية. أجرِ الترقية على الخادم الحالي عندما يحتوي على حالة يصعب نقلها، أو عندما يحاسبك المزوّد لكل جهاز، أو عندما تملك snapshot وإمكانية وصول مؤكدة إلى console. مسار الترقية على الخادم الحالي مجرّب جيداً، لكنه يصبح مساراً باتجاه واحد خلال الساعة التي يعمل فيها.

ماذا يحدث إذا انقطع اتصال SSH أثناء الترقية؟

في login shell عادي، تستقبل العملية SIGHUP وتتوقف في منتصف التنفيذ، مما يترك dpkg مهيأً جزئياً. ابدأ العملية داخل tmux أو screen، وعندها تستمر العملية في العمل، ثم أعد الاتصال وشغّل tmux attach -t upgrade لمتابعة الترقية. يبدأ برنامج الترقية أيضاً SSH daemon احتياطياً على المنفذ 1022 كطريقة ثانية للوصول، لكنه لا يفتح الجدار الناري لهذا المنفذ. لذلك اسمح بالمنفذ 1022 بنفسك أولاً، ثم أغلقه بعد انتهاء الترقية.

يعرض موقعي الذي يستخدم PHP الخطأ 502 بعد الترقية. ما الذي تعطل؟

تغيّر مسار PHP FPM socket مع الإصدار. يشغّل Ubuntu 24.04 الإصدار PHP 8.3، بينما يشغّل 26.04 الإصدار PHP 8.5. لذلك لم يعد /run/php/php8.3-fpm.sock موجوداً، في حين أن nginx vhost لا يزال يشير إليه. يعرض nginx error log الرسالة connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory). حدّث fastcgi_pass ليشير إلى socket الخاص بالإصدار 8.5، ثم شغّل sudo nginx -t، وبعد ذلك أعد تحميل nginx. في Apache مع mod_php، يكون الإصلاح المكافئ هو sudo a2dismod php8.3، ثم sudo a2enmod php8.5 وإعادة تشغيل الخدمة.