تشغيل خادم أوبونتو في وضع الطوارئ: دليل إنقاذ خطوة بخطوة

سيناريو توضيحي: يحتفظ كيسي بجهاز افتراضي يعمل بنظام أوبونتو سيرفر، والذي يدخل في وضع الطوارئ بعد إعادة التشغيل، وذلك بعد فترة وجيزة من إضافة وحدة تخزين بيانات اختيارية /etc/fstab. يمتلك كيسي إمكانية الوصول إلى سطر الأوامر، لكن ليس لديه جلسة SSH. يُعد تغيير وحدة التخزين مؤشرًا، وليس سببًا مؤكدًا: إذ يمكن أن يتبع وضع الطوارئ عدة حالات فشل في بدء التشغيل، لذا يتحقق كيسي من سجلات الجهاز الحالي قبل إجراء أي تغيير. تُظهر لوحات الطرفية أدناه تخطيطات نموذجية ومخرجات افتراضية، وليست عملية إصلاح أو اختبار حقيقية.

ما معنى وضع الطوارئ

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

أولاً، ميّز بين موجه الأوامر. عادةً ما يعرض موجه أوامر الطوارئ في systemd رسالة "مرحباً بك في وضع الطوارئ!" وقد يطلب كلمة مرور المستخدم الجذر للصيانة. أما موجه BusyBox، مثل `<using>`، (initramfs)فيعني أن عملية الإقلاع لم تنتقل بعد إلى نظام الملفات الجذر المُثبّت؛ بينما يشير موجه `<using>` grub>أو grub rescue>`<using>` إلى وجود مشكلة في مُحمّل الإقلاع. تتطلب هذه الحالات مسارات استعادة مختلفة. إذا كان حساب المستخدم الجذر مُقفلاً أو كان الخادم بعيداً، فاستخدم وحدة التحكم التسلسلية/VNC الخاصة بمزود الاستضافة أو بيئة الإنقاذ؛ عادةً لا يكون SSH متاحاً في هذه المرحلة. لا تضغط على Ctrl+D للمتابعة حتى تفهم سبب العطل المُبلغ عنه وتُصلحه.

إنقاذ خطوة بخطوة

1. احتفظ بإمكانية الوصول إلى وحدة التحكم وسجل العطل بالتحديد

ابقَ في وحدة التحكم الخاصة بالطوارئ. دوّن آخر عملية ربط فاشلة أو اسم الخدمة وأي مسار جهاز أو معرّف فريد عالمي (UUID) مطبوع أعلى الموجه. fstabمن المفيد مراجعة تعديل كيسي الأخير، ولكن لا تُعلّق على كل سطر فاشل أو تُشغّل أمر إصلاح بناءً على كلمة "طوارئ" فقط. إذا كان النظام جهازًا افتراضيًا، فأبقِ وحدة تحكم الموفر مفتوحة أثناء الإصلاح وإعادة التشغيل التالية.

2. اقرأ سجل بدء التشغيل الحالي والوحدات المعطلة

في حالة الطوارئ، قم بتشغيل:

journalctl -xb -p err --no-pager
systemctl --failed --no-pager

-bيُقيّد هذا الاستعلام سجل النظام على عملية الإقلاع هذه، -p errويُصفّي الأخطاء حسب الأولوية وما فوقها. ابحث عن أول خطأ ذي صلة، وليس فقط آخر سلسلة من رسائل "فشل التبعية". إذا فشلت وحدة ربط، فدوّن اسم الوحدة المُشفّر ومسارها المستهدف؛ وإذا فشلت خدمة، فحدّد ما إذا كانت سببًا أم مجرد نتيجة لفشل وحدة ربط. يُوثّق دليل أوبونتو journalctl(1)عملية الإقلاع وتصفية الوحدات.

3. تحقق من نقطة تثبيت الجذر والمساحة المتاحة

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

findmnt -no SOURCE,FSTYPE,OPTIONS /
df -h /
df -i /

في findmntالمخرجات، roيشير الرمز `--` إلى وضع القراءة فقط، بينما rwيشير الرمز `--` إلى وضع القراءة والكتابة. قد يكون جذر القراءة فقط مقصودًا خلال جزء من عملية الاستعادة، أو قد يعكس مشكلة في نظام الملفات. لا تقم بإعادة التحميل قسرًا كوضع القراءة والكتابة إذا سجلت سجلات النواة أخطاءً في الإدخال/الإخراج أو نظام الملفات. كما يمكن أن يتسبب نظام الملفات الممتلئ أو جدول inodes المستنفد في فشل خدمات وعمليات تحميل غير ذات صلة. يشرح findmnt(8)دليل أوبونتو كيفية فحص أنظمة الملفات المُحمّلة.

4. التحقق من صحة /etc/fstabمعرّفات الجهاز والتأكد منها

نظراً للتغييرات التي طرأت مؤخراً على برنامج Casey /etc/fstab، يرجى التحقق من كل من صيغته وما إذا كانت الأجهزة المشار إليها موجودة:

findmnt --verify --verbose
lsblk -f
blkid

findmnt --verify --verboseيتحقق من إدخالات ملف fstab بحثًا عن مشاكل في التحليل وسهولة الاستخدام. قارن كل إدخال UUID=في الصف المشتبه به مع مُعرّف UUID المُشار إليه بواسطة `<اسم الملف> lsblk -f` أو blkid`<اسم الملف>`. تحقق أيضًا من نقطة التحميل ونوع نظام الملفات والخيارات. قد يمنع مُعرّف UUID المنسوخ من قرص آخر، أو جهاز غير متصل، أو خيار غير صالح، إتمام عملية التحميل المطلوبة. لا تُخمّن اسم قسم مثل `<اسم القسم /dev/sda1>`؛ فقد تتغير أسماء الأجهزة بين عمليات إعادة التشغيل.

5. قم بتصحيح مشكلة التركيب المؤكدة فقط

إذا كان نظام الملفات الجذر قابلاً للكتابة، وحدد فحص fstab صفًا تالفًا، فقم بعمل نسخة احتياطية قبل التحرير:

cp -a /etc/fstab /etc/fstab.before-rescue
nano /etc/fstab

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

UUID=VERIFIED-UUID /srv/archive ext4 defaults,nofail,x-systemd.device-timeout=10s 0 2

استبدل العنصر النائب بمعرف UUID الحقيقي، واستخدم نوع نظام الملفات الفعلي. لا تُضِف هذا الخيار nofailإلى نظام الملفات الجذر أو نظام الإقلاع أو أي أنظمة ملفات أخرى ضرورية لتشغيل الجهاز أو تطبيقاته بشكل صحيح. مع هذا الخيار ، يستمر الإقلاع حتى في حال فشل عملية الربط، لذا قد تحتاج الخدمات التابعة إلى مزيد من الاهتمام. يوثّق دليل وحدة ربط نظامnofail Ubuntu systemd خيارات fstab هذه.

بعد التعديل، تحقق من صحة البيانات مرة أخرى قبل محاولة التثبيت:

findmnt --verify --verbose
systemctl daemon-reload
mount /srv/archive

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

6. لا تُجرِ تحقيقًا في خدمة فاشلة إلا إذا أشارت سجلات النظام إلى أحدها.

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

systemctl status example.service --no-pager
journalctl -u example.service -b --no-pager

استبدل example.serviceاسم الوحدة بالاسم الدقيق. تحقق مما إذا كان ملف التكوين أو الملف التنفيذي أو بيانات الاعتماد أو نقطة التحميل المطلوبة مفقودة. إذا كان العطل ناتجًا عن فقدان وحدة تخزين بيانات Casey، فأصلح نقطة التحميل هذه أولًا ثم أعد تقييم الخدمة. قد يؤدي تعطيل خدمة أساسية إلى إخفاء الأعراض مع ترك الخادم غير قابل للاستخدام.

7. تعامل مع أخطاء نظام الملفات كعملية إصلاح غير متصلة بالإنترنت

إذا أبلغ سجل النواة عن تلف في نظام الملفات أو أخطاء في إدخال/إخراج وحدة التخزين، فتوقف عن الكتابة حيثما أمكن، واحتفظ بنسخة احتياطية أو لقطة من النظام قبل الإصلاح. تأكد من الجهاز ونظام الملفات بدقة lsblk -f. بالنسبة لنظام ملفات الجذر، قم بالتمهيد إلى نظام الإنقاذ الخاص بالنظام أو وسائط استعادة/تشغيل أوبونتو، وتأكد من فصل القسم المستهدف، واستخدم أداة الفحص المناسبة لنظام الملفات هذا. بالنسبة لأنظمة ext2/3/4، هذه الأداة هي e2fsck. أما أنظمة XFS وBtrfs وغيرها فلها إجراءات مختلفة.

لا تقم بتشغيل fsckأي أمر e2fsckعلى نظام ملفات مُثبَّت، بما في ذلك جذر القراءة فقط المُثبَّت. يُحذِّر e2fsck(8)دليل أوبونتو من أن فحص نظام ملفات مُثبَّت غير آمن عمومًا وأن النتائج غير صالحة. إذا أبلغ القرص عن أخطاء إدخال/إخراج متكررة، فأعطِ الأولوية لاستعادة البيانات أو التواصل مع موفر التخزين بدلًا من محاولة الإصلاحات المتكررة.

8. أعد تشغيل الجهاز بشكل طبيعي وتحقق من النتيجة

بمجرد تصحيح السبب المؤكد، أعد تشغيل الجهاز من وحدة التحكم:

systemctl reboot

بعد بدء تشغيل أوبونتو، تحقق من الهدف الافتراضي المُكوّن، وحالة النظام الحالية، والوحدات الفاشلة، وعملية الإقلاع الجديدة:

systemctl get-default
systemctl is-system-running
systemctl --failed --no-pager
journalctl -b -p err --no-pager
findmnt --verify --verbose

إذا كنتَ تُصرّ على الاستمرار في عملية الإقلاع الحالية، systemctl defaultفسيطلب النظام من systemd بدء تشغيل الهدف الافتراضي المُكوّن. استخدم هذه الخاصية فقط بعد إصلاح الخطأ المُعطِّل؛ فهي لا تُصلح عملية تحميل غير صالحة أو نظام ملفات تالف. systemctl get-defaultيعرض هذا الأمر الهدف الافتراضي المُكوّن، systemctl is-system-runningويُبلغك ما إذا كان systemd يعتبر الحالة الحالية قيد التشغيل، أو مُتدهورة، أو غير ذلك. تعني عملية الاسترداد النظيفة أن أنظمة الملفات المتوقعة مُحمّلة، والخدمات المطلوبة نشطة، وأن حالة الطوارئ نفسها لا تتكرر بعد إعادة التشغيل.

إذا كان الموجه (initramfs)بدلاً من ذلك

لا تُطبّق خطوات systemd emergency-shell بشكلٍ أعمى في BusyBox initramfs. تحاول مرحلة initramfs تحديد موقع نظام الملفات الجذر الحقيقي وتركيبه قبل تسليم التحكم إلى النظام المُثبّت. سجّل الخطأ بدقة، وتحقق مما إذا كان الجهاز المتوقع موجودًا في ملفي `/usr/files` /devو` /dev/disk/by-uuid/usr/files`، وقارن قيمة سطر أوامر الإقلاع root=مع مُعرّف UUID الجذر الفعلي. إذا كان القرص أو وحدة التخزين المُشفّرة/LVM مفقودًا، فاستخدم أدوات التخزين والإنقاذ الخاصة بالمُزوّد ​​للتحقق من ذلك. قد تُؤدي إعادة بناء initramfs أو تغيير معلمات GRUB دون تحديد الجهاز المفقود إلى صعوبة استعادة النظام بعد الإقلاع.

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