حل مشكلة عدم إقلاع VPS بعد تحديث النواة

ما الذي يجب فعله أولاً عندما لا يقلع VPS بعد تحديث النواة

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

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

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

كيف أصل إلى وحدة التحكم عندما يتوقف SSH عن العمل؟

افتح لوحة تحكم مزود الخدمة وابحث عن وحدة تحكم. تشمل الأسماء الشائعة VNC console وweb console وnoVNC وserial console. استخدم serial console عند توفر الخيارين، لأنها تعرض نصاً فعلياً يمكنك تمريره ونسخه، بينما تعرض VNC صورة للشاشة فقط. ابحث عن هذا الخيار الآن، ما دام الخادم يعمل بشكل سليم، وتأكد من أنه يفتح. البحث عنه أثناء انقطاع الخدمة يستهلك الهدوء الذي تحتاج إليه. أدرج هذا التحقق ضمن الدقائق العشر الأولى على VPS جديد، إلى جانب قواعد الجدار الناري ومفاتيح SSH.

توفر معظم اللوحات أيضاً rescue mode أو recovery image. يقلع النظام من شبكة مزود الخدمة، ويرفق قرصك كجهاز إضافي، لذلك لا يعمل أي شيء من القرص نفسه. يُستخدم rescue mode كخيار احتياطي عندما يكون GRUB نفسه معطلاً، كما يُستخدم لنسخ البيانات من خادم قررت عدم إنقاذه.

ستحتاج عادةً إلى hard reset من لوحة التحكم للوصول إلى قائمة الإقلاع، لأنك لا تستطيع تشغيل sudo reboot على جهاز لا يمكنك تسجيل الدخول إليه. يعادل hard reset فصل الطاقة. ستتعرض أنظمة الملفات لإيقاف تشغيل غير سليم، لذلك توقّع إجراء فحص لنظام الملفات عند الإقلاع التالي.

كيف تختار نواة أقدم من قائمة GRUB؟

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

عند ظهور القائمة، اختر «Advanced options for Ubuntu». تعرض هذه القائمة الفرعية كل النوى المثبّتة، بدءاً من الأحدث، مع إدخال لوضع الاسترداد لكل نواة. اختر الإدخال العادي الثاني، أي النواة الأقدم من الأحدث، ثم اضغط Enter. وضع الاسترداد مختلف؛ فهو يقلع إلى نظام أحادي المستخدم ومحدود، ويُستخدم للإصلاح، وليس لإعادة خدماتك إلى العمل.

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

uname -r
dpkg -l 'linux-image-*' | grep '^ii'

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

لا تظهر قائمة GRUB. ماذا تفعل الآن؟

تأتي صور السحابة بإعداد يخفي القائمة. تضبط صور Ubuntu عادةً مهلة الانتظار على 0 في ملف ضمن /etc/default/grub.d/، لذلك تبدأ أحدث نواة فوراً ولا يوجد وقت للضغط على أي مفتاح.

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

أصلح الحالتين بينما يعمل الجهاز بصورة سليمة. عدّل /etc/default/grub:

GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=10
GRUB_RECORDFAIL_TIMEOUT=10
GRUB_TERMINAL="console serial"
GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200"
GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0,115200"

طبّق التعديل بعد ذلك، وتحقق من بقائه، لأن الملفات الموجودة في /etc/default/grub.d/ تُقرأ بعد /etc/default/grub ويمكنها تجاوز إعدادك.

sudo update-grub
grep -rE 'TIMEOUT|TERMINAL' /etc/default/grub /etc/default/grub.d/

يرسل GRUB_TERMINAL="console serial" القائمة إلى وحدة التحكم الرسومية والمنفذ التسلسلي، لذلك ستظهر في أي عارض توفره لوحة التحكم. وتفعل وسيطات نواة console= الشيء نفسه مع رسائل الإقلاع اللاحقة. إن تأخير الإقلاع 10 ثوانٍ في كل مرة ثمن زهيد مقابل قائمة يمكنك الوصول إليها فعلياً عند الساعة 2 صباحاً.

ما فئة العطل التي أواجهها؟

اقرأ الأسطر العشرين الأخيرة قبل توقف تغيّر شاشة وحدة التحكم. تغطي أربعة أنماط معظم ما يحدث بعد تحديث kernel.

لا يستطيع GRUB العثور على ملفاته الخاصة. تظهر مطالبة grub rescue>، أو يظهر خطأ بشأن partition أو file غير موجود، ولا تظهر أي رسالة من kernel. لم يبدأ kernel عمله بعد. يحدث ذلك بعد تغيير القرص أو partition، أو بعد كتابة bootloader على الجهاز الخطأ، وليس بسبب حزمة kernel وحدها.

يبدأ kernel، لكنه لا يستطيع mount لـ root. تتوالى رسائل kernel، ثم تصل إلى shell من busybox تظهر فيه المطالبة (initramfs)، أو ينتهي الإقلاع برسالة panic تفيد بتعذر mount لنظام ملفات root. تم تحميل kernel. لكن initramfs، وهو root مؤقت صغير يعثر على نظام ملفات root الحقيقي ويجري له mount، لم يعثر على القرص. في Ubuntu، تسبق هذه shell عادةً رسالة تفيد بالتوقف عن انتظار جهاز root، وتذكر UUID المطلوب. انسخ UUID وقارنه لاحقاً بمخرجات blkid.

لا يظهر logical volume. هذه هي الفئة السابقة نفسها، لكن بسبب محدد. عند مطالبة (initramfs)، شغّل ls /dev/mapper. إذا كان الإدخال الوحيد هو control، فهذا يعني أنه لم يتم تفعيل أي وحدة تخزين من LVM (مدير logical volume)، ولذلك لا يزال جهاز root غير موجود. فعّل volume groups يدوياً:

lvm vgchange -ay
ls /dev/mapper
exit

تعيد exit التحكم إلى script الخاص بـ initramfs، الذي يعيد محاولة إجراء mount. إذا أقلع النظام بعد ذلك، فهذا يعني أن initramfs الجديد يفتقد مكونات LVM. ويكون الإصلاح بإعادة إنشاء تلك الصورة، لا بتعديل kernel.

لا يظهر أي شيء من Linux إطلاقاً. تعرض وحدة التحكم نصاً من firmware، أو shell من UEFI (واجهة firmware الموسعة الموحّدة)، أو شاشة فارغة بلا مخرجات من kernel، أو حلقة إعادة تشغيل. يحدث العطل قبل تشغيل Linux. تحقّق من الوضع الذي يستخدمه الخادم فعلياً بعد عودته للعمل، لأن كثيراً من مثيلات VPS تقلع في وضع BIOS القديم ولا تستخدم مسار EFI مطلقاً:

[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
mountpoint /boot/efi
sudo efibootmgr -v

يُعد عدم إجراء mount لـ /boot/efi أثناء الترقية سبباً شائعاً على أجهزة UEFI، لأن الحزم التي تدير EFI system partition تكون قد كتبت عندئذٍ إلى directory عادي وفارغ بدلاً منها. ويواصل firmware تشغيل boot entry القديم إلى أن يتوقف ذلك الإدخال عن مطابقة ما هو موجود على القرص.

هناك نمط آخر لا يُعد فشل إقلاع أصلاً. إذا وصلت إلى root shell تفيد بأن النظام في emergency mode، فهذا يعني أن kernel أقلع ثم توقفت userspace. يحدث ذلك عادةً بسبب سطر غير صحيح في /etc/fstab أو بسبب فشل نظام ملفات في الفحص. شغّل journalctl -xb في تلك shell واقرأ اسم الوحدة التي فشلت.

هل حزمة kernel معطّلة، أم أن initramfs هو المعطّل؟

يبدو السببان متطابقين من وحدة التحكم، لكن إصلاح كل منهما يختلف عن الآخر. أقلِع باستخدام kernel القديم، ثم قارن الملفات.

ls -l /boot/vmlinuz-* /boot/initrd.img-*
df -h /boot

يجب أن يكون لديك ملف vmlinuz- واحد وملف initrd.img- مطابق له لكل إصدار مثبّت، وأن يكون لكل منهما حجم معقول. يشير غياب initrd، أو كون حجمه أصغر بكثير من أحجام الملفات المجاورة، إلى فشل إنشاء initramfs. والسبب المعتاد هو امتلاء /boot، وتظهر الأدلة في سجلات الحزم:

sudo grep -iE 'no space|update-initramfs' /var/log/apt/term.log
sudo tail -n 40 /var/log/apt/history.log

يسرد history.log أيضاً الحزم التي ثبّتها عمليات التشغيل الأخيرة بالضبط ووقت تثبيتها، ما يحسم أي خلاف بشأن ما تغيّر.

وفّر مساحة أولاً إذا كان /boot ممتلئاً، ثم أعد إنشاء الصورة للإصدار المطلوب وحدّث القائمة. خذ سلسلة الإصدار من ناتج ls لديك، لأن العنصر النائب أدناه ليس إصداراً حقيقياً:

KVER=6.8.0-XX-generic
sudo update-initramfs -c -k "$KVER"
sudo update-grub
ls -l /boot/initrd.img-$KVER

إن ls الأخير هو عملية التحقق. يدل وجود ملف بالحجم المعتاد على أن الصورة أصبحت موجودة. أما إذا كانت صورة kernel نفسها تالفة، أو أظهر dpkg -l أن الحزمة في أي حالة غير ii، فأعد تثبيت الحزمة:

sudo apt install --reinstall linux-image-$KVER
sudo dpkg --configure -a

الإصلاح من وضع الإنقاذ عندما لا يقلع أي kernel

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

sudo lsblk -f
sudo vgchange -ay
sudo mount /dev/ubuntu-vg/ubuntu-lv /mnt
sudo mount /dev/vda2 /mnt/boot
sudo mount /dev/vda1 /mnt/boot/efi

for d in dev proc sys run; do sudo mount --rbind /$d /mnt/$d; done
sudo chroot /mnt /bin/bash

df -h /boot
update-initramfs -u -k all
update-grub
grub-install /dev/vda
exit

اختبر نواة جديدة من دون المخاطرة بالإقلاع التالي

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

اضبط GRUB_DEFAULT=saved في /etc/default/grub، وشغّل sudo update-grub، ثم اعرض عناوين الإدخالات كي تتمكن من تسمية أحدها بدقة:

grep -E "(menuentry|submenu) " /boot/grub/grub.cfg | cut -d"'" -f2
sudo grub-set-default "Advanced options for Ubuntu>Ubuntu, with Linux 6.8.0-XX-generic"
sudo grub-editenv list
sudo grub-reboot 0
sudo reboot

يجب أن يطبع grub-editenv list العنوان الذي اخترته بصيغة saved_entry. يثبت هذا الناتج أن الآلية تعمل، لأن الحفظ يتطلب أن يكون /boot/grub/grubenv قابلاً للكتابة، وهو ليس كذلك بصمت في بعض التخطيطات. الإدخال 0 هو أعلى القائمة، أي أنه يمثل أحدث نواة. تكون العناوين أكثر أماناً من الأرقام هنا، لأن الأرقام تتغير كلما ثُبّتت نواة أو أُزيلت.

لماذا تكون autoremove محفوفة بالمخاطر على خادم بلا واجهة محلية

يحتفظ APT بقائمة بحزم kernel التي يجب ألا يزيلها تلقائياً. اقرأ قائمتك:

cat /etc/apt/apt.conf.d/01autoremove-kernels
dpkg -l 'linux-image-*' | grep -c '^ii'

يُعاد إنشاء هذا الملف كلما تغيّرت حزم kernel، وهو يحمي kernel قيد التشغيل وأحدث حزم kernel. تكمن المشكلة في التوقيت. إذا شغّلت sudo apt autoremove --purge مباشرة بعد الإقلاع باستخدام kernel جديد، فستكون القائمة المحمية قد تقدمت بالفعل، ولن يعود kernel الأقدم الذي كنت تعتمد عليه محمياً. على جهاز مزود بلوحة مفاتيح، يمثّل ذلك إزعاجاً. أما على خادم بلا واجهة محلية، فهو الفرق بين اختيار إدخال من قائمة الإقلاع وتركيب القرص من صورة إنقاذ.

أبقِ على kernelين كحد أدنى، وعلى ثلاثة عندما تتوفر مساحة لدى /boot. أزل الحزم القديمة بالاسم بعد التحقق من uname -r، حتى لا تتمكن من حذف kernel الذي تستخدمه:

uname -r
sudo apt purge linux-image-6.8.0-XX-generic
dpkg -l 'linux-image-*' | grep '^ii'

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

التقط لقطة قبل الترقية

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

يكون هذا مهماً خصوصاً عند ترقية الإصدار، إذ تتغير kernel وأدوات initramfs وbootloader وتهيئة GRUB كلها في عملية واحدة. التقط اللقطة مباشرة قبل أن تبدأ ترقية Ubuntu من 24.04 إلى 26.04، وليس في الليلة السابقة، حتى تتطابق نقطة الاستعادة مع الجهاز الذي توشك على تغييره. إذا لم تُعرض هذه الترقية على خادمك بعد، فالسبب هو الجدولة وليس خللاً في الإعداد، لأن الانتقال من إصدار LTS إلى إصدار LTS لا يُفتح إلا عند أول إصدار نقطي، 26.04.1.

كيفية تعامل unattended-upgrades مع حزم kernel

يثبّت unattended-upgrades تحديثات الأمان في Ubuntu دون طلب تأكيد، وتصل حزم kernel عبر security pocket مثلها مثل بقية الحزم. وينتج عن ذلك أمران.

أولاً، تُثبَّت kernel الجديدة، لكنها لا تكون قيد التشغيل. لا تصبح kernel فعّالة إلا عند الإقلاع. يظهر الملف /var/run/reboot-required، ويحدّد /var/run/reboot-required.pkgs ما طلب إعادة التشغيل، لكن لا يُعاد تشغيل الخادم ما لم تكن قد فعّلت Unattended-Upgrade::Automatic-Reboot في /etc/apt/apt.conf.d/50unattended-upgrades.

cat /var/run/reboot-required.pkgs
grep -E 'Automatic-Reboot|Blacklist' /etc/apt/apt.conf.d/50unattended-upgrades

ثانياً، تخفي هذه الفجوة السبب. يمكن للخادم تثبيت kernel في مارس ثم إعادة التشغيل في يونيو لسبب مختلف تماماً، وبعد ذلك يفشل في الإقلاع. يكون التغيير الذي عطّل الإقلاع قد حدث قبل ثلاثة أشهر، لذلك لا يفسّر أي إجراء نفذته في ذلك اليوم المشكلة. تجد في /var/log/apt/history.log عملية التشغيل التي ثبّتت kernel التي يفشل الخادم بسببها الآن.

أعد التشغيل عمداً في يوم تختاره، مع فتح نافذة وحدة التحكم مسبقاً. تحوّل هذه العادة البسيطة انقطاعاً غامضاً إلى اختيار من قائمة يستغرق دقيقتين. إذا أردت الأتمتة من دون المفاجآت، فاترك التثبيت التلقائي مفعّلاً وأوقف إعادة التشغيل التلقائية، وراجع كيفية إعداد unattended-upgrades على Ubuntu لمعرفة الإعدادات الدقيقة. يؤدي تعليق حزم kernel باستخدام sudo apt-mark hold linux-image-generic إلى إيقافها بالكامل، كما يوقف إصلاحات أمان kernel في الوقت نفسه، لذلك تعامل مع ذلك كمقايضة قررت إجراءها، لا كإجراء أمان.

FAQ

كيف أشغّل نواة أقدم على VPS لا يحتوي على لوحة مفاتيح؟

افتح وحدة تحكم المزوّد (VNC أو serial)، وفعّل إعادة تشغيل قسرية من لوحة التحكم، لأنك لا تستطيع تسجيل الدخول لإعادة التشغيل بطريقة سليمة. أثناء إعادة تشغيل الجهاز، اضغط Esc بشكل متكرر، أو اضغط باستمرار على Shift عند استخدام إقلاع BIOS قديم، لإبقاء قائمة GRUB ظاهرة. اختر "Advanced options for Ubuntu"، ثم اختر الإدخال الموجود أسفل أحدث نواة. بعد ظهور مطالبة تسجيل الدخول، شغّل uname -r للتأكد من النواة المستخدمة، وشغّل dpkg -l 'linux-image-*' لمعرفة النوى الأخرى المثبّتة. ابدأ التشخيص فقط بعد عودة النظام إلى العمل.

لماذا لا يعرض VPS قائمة GRUB إطلاقاً؟

تضبط صور السحابة عادةً مهلة GRUB على القيمة 0 في ملف ضمن /etc/default/grub.d/، لذلك تبدأ أحدث نواة من دون إتاحة وقت للضغط على أي مفتاح. اضبط GRUB_TIMEOUT=10 وGRUB_TIMEOUT_STYLE=menu في /etc/default/grub، وأضف GRUB_TERMINAL="console serial" لكي تصل القائمة أيضاً إلى وحدة تحكم تسلسلية، ثم شغّل sudo update-grub. تحقّق باستخدام grep -r TIMEOUT /etc/default/grub /etc/default/grub.d/، لأن الملفات الموجودة في ذلك الدليل تُقرأ بعد الملف الرئيسي ويمكنها تجاوز تعديلاتك.

هل ينبغي أن أزيل النوى القديمة لتحرير مساحة في /boot؟

أزل أقدم النوى، واحتفظ بنواتين على الأقل. امتلاء /boot حالة فشل مستقلة، لأن إنشاء initramfs يفشل عندها، وتبقى لديك نواة لا تملك صورة صالحة للعمل. احذف الحزم باستخدام اسم الحزمة الدقيق بعد التحقق من uname -r، حتى لا تصبح النواة قيد التشغيل مرشحة للحذف. تجنّب استخدام sudo apt autoremove --purge بشكل شامل على جهاز لا يحتوي على لوحة مفاتيح، لأن قائمة النوى المحمية تُعاد توليدها عند كل تغيير في النواة، وقد يؤدي تشغيل الأمر في توقيت سيئ إلى بقائك مع نواة واحدة ومن دون إدخال احتياطي في القائمة.

هل يمكن أن تتسبب unattended-upgrades في تعطيل الإقلاع؟

يمكنها تثبيت نواة تفشل لاحقاً في الإقلاع، لكنها لا تعيد تشغيل الجهاز ما لم تُضبط Unattended-Upgrade::Automatic-Reboot على true في /etc/apt/apt.conf.d/50unattended-upgrades. النمط المعتاد هو فشل مؤجل: تُثبَّت النواة أثناء تشغيل تلقائي، ويظهر /var/run/reboot-required، ولا تظهر المشكلة إلا عند إعادة التشغيل التالية بعد أسابيع. أعد التشغيل عمداً مع إبقاء وحدة التحكم مفتوحة، واقرأ /var/log/apt/history.log لمعرفة أي تشغيل ثبّت النواة التي تقلع بها.