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

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

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

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

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

كيف أصل إلى وحدة التحكم (Console) عندما يتعطل SSH؟

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

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

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

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

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

عندما تظهر القائمة، اختر "Advanced options for Ubuntu". تعرض هذه القائمة الفرعية كل نواة مثبتة، بدءاً من الأحدث، مع خيار وضع الاسترداد (recovery mode) لكل منها. اختر المدخل العادي الثاني، وهو النواة التي تلي الأحدث مباشرة، واضغط Enter. وضع الاسترداد أمر مختلف؛ فهو يُقلع إلى نظام مستخدم واحد (single user) بحد أدنى من الخدمات، وهو مخصص لأعمال الإصلاح، وليس لإعادة تشغيل خدماتك.

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

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

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

قائمة GRUB لا تظهر أبداً. ماذا أفعل؟

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

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

عالج كلتا الحالتين بينما لا يزال الجهاز يعمل. عدّل ملف /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" القائمة إلى وحدة التحكم الرسومية وإلى المنفذ التسلسلي (serial port)، بحيث تظهر في أي عارض توفره لك لوحة التحكم الخاصة بك. تقوم وسائط النواة console= بالأمر نفسه لرسائل الإقلاع التي تلي ذلك. عشر ثوانٍ من التأخير في كل إقلاع هي ثمن زهيد مقابل قائمة يمكنك الوصول إليها فعلياً في الساعة الثانية صباحاً.

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

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

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

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

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

lvm vgchange -ay
ls /dev/mapper
exit

يعيد الأمر exit التحكم إلى سكربت initramfs، الذي يعيد محاولة التحميل. إذا أقلع النظام بعد ذلك، فهذا يعني أن صورة initramfs الجديدة تفتقد إلى مكونات LVM، ويكون الإصلاح هو إعادة بناء تلك الصورة بدلاً من تعديل النواة.

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

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

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

هناك نمط إضافي ليس فشلاً في الإقلاع على الإطلاق. إذا وصلت إلى صدفة الجذر (root shell) التي تخبرك بأن النظام في وضع الطوارئ، فهذا يعني أن النواة أقلعت ولكن مساحة المستخدم (userspace) توقفت. يعني هذا عادةً وجود سطر خاطئ في /etc/fstab أو نظام ملفات فشل في عملية الفحص. نفذ الأمر journalctl -xb في تلك الصدفة واقرأ اسم الوحدة التي فشلت.

هل حزمة النواة معطوبة، أم ملف initramfs؟

يبدو هذان الأمران متطابقين من وحدة التحكم (console) ويتطلبان إصلاحات مختلفة. أقلع باستخدام النواة القديمة، ثم قارن بين الملفات.

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 الأخير هو للتحقق. وجود ملف بحجم طبيعي يعني أن الصورة موجودة الآن. إذا كانت صورة النواة نفسها تالفة، أو أظهر dpkg -l الحزمة في أي حالة غير ii، أعد تثبيت الحزمة:

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

الإصلاح من وضع الإنقاذ عند فشل إقلاع النواة

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

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 بقائمة من حزم النواة التي يجب ألا يحذفها تلقائياً. اقرأ قائمتك الخاصة:

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

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

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

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

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

التقط لقطة (Snapshot) قبل الترقية

تُعد اللقطة التي يتم التقاطها قبل apt upgrade مسار الاستعادة الوحيد الذي لا يعتمد على إقلاع أي شيء. تؤدي استعادتها إلى إعادة القرص إلى الحالة التي كان فيها النواة (kernel) القديمة هي الافتراضية، ويمكنك حينها إعادة محاولة الترقية مع إبقاء وحدة التحكم (console) مفتوحة. لقطات الجهاز قيد التشغيل تكون متوافقة مع حالة الانهيار (crash consistent)، وهذا يعني أنها تلتقط حالة القرص كما لو أن الطاقة قد انقطعت عنه، لذا أوقف تشغيل الخادم أولاً إذا كان مزود الخدمة لديك يدعم اللقطات دون اتصال (offline snapshot). اللقطة ليست نسخة احتياطية، لأنها عادةً ما تعيش على نفس البنية التحتية التي يوجد عليها المجلد الذي تنسخه. فهم الفرق بين لقطات VPS والنسخ الاحتياطي الحقيقي يحدد أياً منهما سينقذك عندما يكون الفشل أكبر من مجرد مشكلة في النواة.

هذا الأمر بالغ الأهمية عند ترقية الإصدار، حيث تتغير النواة، وأدوات initramfs، ومحمل الإقلاع (bootloader)، وإعدادات GRUB دفعة واحدة. التقط اللقطة مباشرة قبل البدء في ترقية Ubuntu 24.04 إلى 26.04، وليس في الليلة السابقة، لضمان تطابق نقطة الاستعادة مع حالة الجهاز التي توشك على تغييرها.

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

تُثبّت أداة unattended-upgrades في Ubuntu تحديثات الأمان تلقائياً دون تدخل منك، وتصل حزم النواة عبر مستودع الأمان (security pocket) كغيرها من الحزم. يترتب على ذلك نتيجتان.

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

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

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

FAQ

كيف يمكنني الإقلاع باستخدام نواة (kernel) أقدم على خادم VPS دون لوحة مفاتيح؟

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

لماذا لا يظهر لي أي أثر لقائمة GRUB على خادم VPS الخاص بي؟

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

هل يجب عليّ إزالة النوى القديمة لتوفير مساحة في /boot؟

أزل الأقدم منها واحتفظ باثنتين على الأقل. امتلاء /boot يمثل نمط فشل بحد ذاته، لأن عملية إنشاء initramfs ستفشل حينها، وستبقى مع نواة لا تملك صورة عمل صالحة. قم بالإزالة (purge) باستخدام اسم الحزمة الدقيق بعد التحقق من 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 لمعرفة أي عملية تحديث هي التي ثبّتت النواة التي تحاول الإقلاع بها.