ترقية Ubuntu 24.04 إلى 26.04 على VPS بأمان

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

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

شغّل الفحص على خادم 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. لا يُعد ارتفاع رقم الإصدار سبباً كافياً للمساس بجهاز يخدم العملاء.

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

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

غالباً ما يكون البديل أفضل: أنشئ VPS جديداً يعمل بـ26.04، وثبّت حزمة البرامج لديك واستعد البيانات، ثم بدّل DNS بعد التأكد من أنه يستجيب بشكل صحيح. يمكنك إبقاء الخادم القديم قيد التشغيل حتى يثبت الخادم الجديد استقراره، ويصبح rollback تغييراً في 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. سيستمر التحديث أثناء غيابك. إذا لم يستمر، ووجدت عند عودتك أن حالة dpkg أو مصادر apt مهيّأة جزئياً، وأنها تتضمن noble وجزءاً من resolute، فراجع استعادة ترقية إصدار فاشلة. يوضّح هذا القسم كيفية إصلاح حالة الحزم، ومتى تتوقف عن الإصلاح وتستعيد اللقطة بدلاً من ذلك.

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

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

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

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

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 لم يعد موجوداً

يأتي 24.04 مع PHP 8.3، ويأتي 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 الجديد، واختبر الإعدادات، ثم أعد التحميل:

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

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

في 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 ثم إعادة التشغيل.