بوت لینوکس چیست؟ مراحل Boot از BIOS و GRUB تا systemd و عیب‌یابی

فرض کن یه سرور لینوکسی داری که تا دیروز بدون دردسر بالا می‌اومد. امروز روشنش می‌کنی، چراغ‌ها روشن می‌شن، لوگوی سازنده رو می‌بینی، بعد هم صفحه سیاه می‌مونه. اولین فکری که به ذهنت می‌رسه چیه؟ «لینوکس خراب شده»؟ خیلی وقت‌ها همین جمله باعث می‌شه مسیر عیب‌یابی رو اشتباه بریم؛ چون هنوز نمی‌دونیم خرابی دقیقاً کجای راه اتفاق افتاده. اگه لوگو رو دیدی ولی صفحه ورود نیومده، همین آخرین تصویر یه سرنخ برای بررسی بوت لینوکس هست؛ نه تشخیص قطعی.

ببین، بوت لینوکس یه اتفاق تک‌مرحله‌ای نیست. چند بخش مختلف باید کارشون رو درست انجام بدن تا در نهایت صفحه ورود یا سرویس‌های سیستم آماده بشن. اگه هر کدوم از این بخش‌ها متوقف بشن، علامت متفاوتی می‌بینی. قرار نیست توی این درس همه دستورهای نجات سرور رو حفظ کنی؛ می‌خوام یاد بگیری از همون علامت اول، سؤال درستی بپرسی.

یه نکته مهم هم از اول روشن کنیم : این آموزش جزو مسیر LPIC-1 نابغه‌هاست و مستقیماً به هدف 101.2 آزمون رسمی مربوط می‌شه. بنابراین هم اسم اجزا و ترتیب کارشون مهمه، هم اینکه بتونی رخدادهای بوت رو از لاگ‌ها بخونی. بخش دست‌کاری جدی GRUB، پارتیشن‌ها و بازیابی سیستم خراب، تمرین مستقل و محیط آزمایشگاهی می‌خواد؛ اینجا اول پایه تشخیص رو می‌سازیم.

بوت لینوکس چیست؟ جواب کوتاه و روشن

بوت لینوکس یعنی مجموعه کارهایی که از روشن‌شدن دستگاه شروع می‌شن و به آماده‌شدن سیستم‌عامل برای استفاده می‌رسن. ممکنه آخر این مسیر یه دسکتاپ ببینی، ممکنه فقط یک صفحه ورود متنی داشته باشی و ممکنه هیچ تصویری نبینی ولی سرور از راه شبکه به درخواست‌ها جواب بده. بنابراین رسیدن به دسکتاپ معیار قطعی موفق‌بودن بوت نیست.

به زبان ساده، سخت‌افزار اول آماده می‌شه، Firmware راه‌اندازی رو جلو می‌بره، یک برنامه راه‌انداز یا سازوکار مشابه هسته لینوکس رو اجرا می‌کنه، هسته سخت‌افزار و حافظه رو آماده می‌کنه، محیط اولیه فایل‌ها رو تحویل می‌ده و در نهایت سیستم مدیریت سرویس‌ها برنامه‌های مورد نیاز رو بالا میاره. همه سیستم‌ها عیناً یک زنجیره ندارن؛ ولی این نقشه برای درک بیشتر نصب‌های معمول لینوکس نقطه شروع خوبیه. وقتی می‌خوای بوت لینوکس رو عیب‌یابی کنی، ترتیب همین مراحل مشخص می‌کنه کدوم ابزار و کدوم گزارش واقعاً به دردت می‌خوره.

اول یه پرونده واقعی‌نما باز کنیم : سرور «نقشه‌خانه»

فرض کن یه مجموعه خیالی به اسم «نقشه‌خانه» داریم که نقشه‌های قدیمی شهر رو اسکن می‌کنه. فایل‌ها روی یک سرور لینوکسی نگهداری می‌شن و کارمندها صبح که میان، از پنل داخلی تصاویر رو پیدا می‌کنن. اسم سرور رو هم گذاشتیم atlas-node. قرار نیست ادعا کنم چنین مجموعه‌ای واقعاً وجود داره؛ این یه محیط آموزشی ساخته‌شده برای همین مقاله‌ست.

حالا تصور کن دیشب سیستم به‌روزرسانی شده و امروز پنل نقشه‌ها باز نمی‌شه. یکی از همکارها می‌گه «بوت لینوکس مشکل داره». ولی اپراتور دستگاه می‌گه صفحه ورود لینوکس رو دیده و حتی با حساب خودش وارد شده. همین یک شاهد ساده مسیر بررسی رو عوض می‌کنه : وقتی ورود به سیستم انجام شده، بخش مهمی از بوت موفق بوده و باید سراغ سرویس برنامه، شبکه یا دیسک بریم، نه اینکه بی‌دلیل GRUB رو از نو نصب کنیم.

چند روز بعد، همین سرور در یک سناریوی آزمایشی دیگه به صفحه emergency mode می‌رسه و روی کنسول پیام مربوط به Mount یک دیسک داده ظاهر می‌شه. این بار موضوع با خرابی پنل فرق داره. پس در طول درس دو پرونده رو جدا نگه می‌داریم : «لینوکس بالا اومده ولی برنامه کار نمی‌کنه» و «بوت در مرحله آماده‌سازی سیستم متوقف شده».

مرحله اول : BIOS و UEFI دقیقاً چه نقشی دارن؟

وقتی دکمه پاور رو می‌زنی، سیستم‌عامل هنوز اجرا نشده. Firmware دستگاه باید سخت‌افزار پایه رو آماده کنه و مسیر راه‌اندازی رو تشخیص بده. توی سیستم‌های قدیمی‌تر معمولاً اسم BIOS رو می‌شنیدی؛ روی خیلی از سیستم‌های جدید UEFI داریم. این دو رو نمی‌شه فقط دو اسم برای یک چیز کاملاً یکسان دونست؛ مدل بوت و امکاناتشون تفاوت داره. پس وقتی بوت لینوکس هنوز از مرحله Firmware رد نشده، بررسی سرویس‌های داخل سیستم‌عامل کمکی بهت نمی‌کنه.

توی حالت قدیمی BIOS با دیسک‌های MBR، اجرای کد راه‌انداز به ساختارهای ابتدای دیسک وابسته بود. در بوت متداول UEFI، Firmware می‌تونه فایل اجرایی EFI رو از EFI System Partition یا همون ESP اجرا کنه. بنابراین اگه یه جایی آموزش دیدی که «هر لینوکسی حتماً اول MBR رو اجرا می‌کنه»، بدون اون توضیح برای تمام سیستم‌های جدید درست نیست.

یه اشتباه رایج اینه که هر توقفی قبل از صفحه ورود رو گردن کرنل بندازیم. اگه Firmware هیچ دیسک قابل بوتی پیدا نکرده باشه، اصلاً ممکنه هنوز به مرحله اجرای هسته لینوکس نرسیده باشیم. پیام‌هایی مثل No bootable device بیشتر نشونه بررسی مسیر Firmware، دیسک و Boot Entry هستن؛ نه اثبات خراب‌شدن فایل‌های لینوکس.

برای شروع لازم نیست وارد تنظیمات BIOS/UEFI بشی و چیزی رو تغییر بدی. اول باید مدل بوت سیستم فعلیت رو بشناسی. در یک نصب لینوکس معمولی، وجود مسیر /sys/firmware/efi معمولاً نشون می‌ده سیستم فعلی با UEFI بوت شده؛ نبودن این مسیر در محیط‌های کانتینری، Live یا شرایط خاص به‌تنهایی سند قطعی درباره Firmware میزبان نیست.

if [ -d /sys/firmware/efi ]; then
  printf 'Boot mode: UEFI\n'
else
  printf 'UEFI firmware directory not visible here\n'
fi

خروجی این دستور فقط درباره محیطی حرف می‌زنه که الان داخلش هستی. اگه توی کانتینر یا WSL اجراش کنی، نتیجه رو نباید بدون فکر به مادربرد دستگاه اصلی تعمیم بدی. همین حساسیت روی محدوده اعتبار مشاهده، یکی از فرق‌های مهم کار حرفه‌ای با حفظ‌کردن دستورهاست.

مرحله دوم : Bootloader و GRUB چه کاری انجام می‌دن؟

حالا فرض کن Firmware مسیر درست رو پیدا کرده. باید راهی برای تحویل کنترل به هسته لینوکس وجود داشته باشه. در خیلی از توزیع‌ها این کار با GRUB 2 انجام می‌شه. GRUB می‌تونه فهرست گزینه‌های راه‌اندازی رو نشون بده، نسخه مناسب هسته رو انتخاب کنه و پارامترهای مورد نیاز رو به Kernel بده. البته همه نصب‌های لینوکس الزاماً GRUB ندارن؛ Bootloaderهای دیگه و روش‌های بوت مستقیم EFI هم وجود دارن. اگه بوت لینوکس همین‌جا متوقف شده باشه، باید نشونه‌های Bootloader رو بررسی کنی؛ نه برنامه‌ای که هنوز فرصت اجرا پیدا نکرده.

اگه دستگاه دو سیستم‌عامل داشته باشه، ممکنه منوی GRUB رو زیاد دیده باشی. اما نبودن منو به معنی نبودن Bootloader نیست؛ خیلی از نصب‌ها منو رو پنهان می‌کنن یا زمان انتظار کوتاهی دارن. این تفاوت ساده جلوی یک سوءتفاهم بزرگ رو می‌گیره.

فرق منوی GRUB با grub rescue چیه؟

وقتی منوی معمول GRUB رو می‌بینی، یعنی دست‌کم بخش مهمی از Bootloader اجرا شده. اما وقتی مستقیم به grub rescue> می‌رسی، احتمالاً GRUB نتونسته مؤلفه‌های لازم برای ورود به حالت عادی رو بارگذاری کنه. این نشونه با پیام initramfs فرق داره؛ چون این دو به مراحل مختلف زنجیره مربوط می‌شن.

وسوسه‌انگیزه که از اینترنت چند دستور grub-install یا grub-mkconfig کپی کنی. ولی تا وقتی مشخص نکردی سیستم BIOS داره یا UEFI، مسیر ESP کجاست، چیدمان دیسک چطوره و آخرین تغییر چه بوده، این کار می‌تونه مشکل رو بدتر کنه. برای همین در این درس آگاهانه دستور بازنویسی Bootloader نداریم.

مرحله سوم : Kernel چه زمانی وارد بازی می‌شه؟

وقتی Bootloader هسته رو اجرا می‌کنه، مسئولیت کم‌کم به Kernel منتقل می‌شه. هسته لینوکس کارهایی مثل مدیریت حافظه، زمان‌بندی پردازش‌ها، راه‌اندازی درایورهای لازم و آماده‌سازی دسترسی به سخت‌افزار رو انجام می‌ده. تا این مرحله هنوز نباید انتظار داشته باشی همه سرویس‌های برنامه‌ات راه افتاده باشن. این تفکیک موقع عیب‌یابی بوت لینوکس مهمه؛ چون خطای هسته با خطایی که بعداً در سرویس‌ها رخ می‌ده یکی نیست.

اگه سیستم بالا اومده، می‌تونی نسخه هسته در حال اجرا رو بدون تغییر دادن چیزی ببینی. دستور زیر نسخه Kernel فعال رو گزارش می‌ده؛ نه الزاماً نسخه‌ای رو که دیشب نصب کردی یا نسخه‌ای رو که دفعه بعد اجرا خواهد شد.

uname -r

مثلاً خروجی نمایشی 6.8.0-xx-generic یعنی یک رشته نسخه از هسته فعاله. عدد دقیقش به توزیع و به‌روزرسانی بستگی داره. وقتی دنبال مشکل بعد از آپدیت هستی، این سرنخ مهمه؛ اما خودش دلیل خرابی رو ثابت نمی‌کنه.

پارامترهای Kernel رو کجا ببینیم؟

هسته موقع راه‌اندازی می‌تونه پارامترهایی دریافت کنه؛ مثل اطلاعاتی درباره مسیر فایل‌سیستم ریشه یا گزینه‌های رفتاری. توی سیستم در حال اجرا، خط فرمان هسته رو از مسیر زیر می‌بینی. این فقط مشاهده‌ست و هیچ تنظیمی رو تغییر نمی‌ده.

cat /proc/cmdline

توی خروجی ممکنه گزینه‌هایی مثل root=UUID=...، ro یا quiet ببینی. معنی root= با «کاربر root» فرق داره : اینجا درباره محل فایل‌سیستم ریشه حرف می‌زنیم. ضمن اینکه وجود یک گزینه در خروجی الزاماً ثابت نمی‌کنه همون گزینه باعث خرابی شده؛ باید با وضعیت دیسک و لاگ‌ها مقایسه‌اش کنیم.

مرحله چهارم : initramfs چیست و چرا بعضی سیستم‌ها همون‌جا گیر می‌کنن؟

ببین، Kernel برای دسترسی به فایل‌سیستم اصلی ممکنه به ماژول یا ابزارهایی نیاز داشته باشه که هنوز روی دیسک اصلی در دسترسش نیستن. اینجا محیط اولیه‌ای به نام initramfs به کار میاد : یک فایل‌سیستم موقت که می‌تونه ابزارهای لازم برای آماده‌کردن ریشه اصلی، فعال‌سازی دیسک رمزگذاری‌شده یا شناسایی تجهیزات ذخیره‌سازی رو در اختیار فرایند راه‌اندازی بذاره. پس اگه در بوت لینوکس به پوسته اضطراری این محیط رسیدی، قبل از هر تعمیر باید مسیر فایل‌سیستم ریشه رو بررسی کنی.

وقتی کار این محیط تموم شد، کنترل به سیستم اصلی منتقل می‌شه. پس initramfs خودِ فایل‌سیستم اصلی تو نیست. اگه پیام مربوط به شل اضطراری initramfs رو دیدی، باید احتمال‌هایی مثل در دسترس نبودن دستگاه ریشه، ناسازگاری اطلاعات شناسایی دیسک یا خرابی فایل‌سیستم رو با احتیاط بررسی کنی؛ نه اینکه فوراً نتیجه بگیری GRUB خرابه.

نکته ظریفش اینه که همه توزیع‌ها دقیقاً از ابزار یا پیام یکسان استفاده نمی‌کنن. روی یک سیستم ممکنه نام dracut رو ببینی، روی یکی دیگه ابزارهای initramfs متفاوت باشن. هدف ما تشخیص «مرحله‌ای که گیر کرده» است، نه حفظ متن یک پیغام خاص.

مرحله پنجم : init و systemd سیستم رو چطور آماده می‌کنن؟

وقتی محیط ریشه اصلی آماده شد، سیستم باید سرویس‌ها و بخش‌های لازم رو راه‌اندازی کنه. روی خیلی از توزیع‌های امروزی، این نقش با systemd انجام می‌شه. معمولاً فرایند اصلی مدیریت سیستم شناسه PID 1 داره و بقیه واحدهای سیستمی رو هماهنگ می‌کنه. اما اگه سیستم با init دیگری ساخته شده باشه، لازم نیست PID 1 حتماً systemd باشه. یعنی موفق بودن مراحل اولیه بوت لینوکس هنوز تضمین نمی‌کنه همه Unitها و سرویس‌های مورد نیاز هم آماده شده باشن.

به زبان خودمونی، تا اینجا موتور روشن شده؛ حالا نوبت اینه بخش‌های مختلف ساختمان برق بگیرن و کار کنن. ممکنه خود لینوکس بالا اومده باشه ولی سرویس وب هنوز آماده نشده باشه. به همین خاطره که گفتیم «سیستم بوت شده» با «همه برنامه‌ها سالم کار می‌کنن» یک گزاره نیست.

ps -p 1 -o pid=,comm=
cat /proc/1/comm

خروجی روی یک سرور معمولی مبتنی بر systemd غالباً اسم systemd رو نشون می‌ده. ولی داخل کانتینر ممکنه PID 1 یک برنامه دیگه باشه؛ چون فضای پردازش اون محیط از میزبان جدا شده. پس این آزمایش رو در جای درست تفسیر کن.

Target در systemd یعنی چی؟

توی systemd، Target یک نقطه هماهنگی برای مجموعه‌ای از Unitهاست. مثلاً multi-user.target معمولاً به محیط چندکاربره غیرگرافیکی اشاره می‌کنه و graphical.target هدف مرتبط با محیط گرافیکیه. ولی اینکه یک Target فعال شده، به‌تنهایی سلامت تک‌تک سرویس‌های کسب‌وکار رو تضمین نمی‌کنه.

این موضوع رو با Runlevelهای قدیمی SysVinit مقایسه می‌کنن، اما تبدیل یک‌به‌یک همه رفتارهای اون دو مدل دقیق نیست. برای شروع، مهمه بدونی چرا یک ماشین سروری می‌تونه بدون دسکتاپ کاملاً درست کار کنه.

systemctl get-default
systemctl is-system-running

دستور اول Target پیش‌فرض رو در سیستم مبتنی بر systemd نشون می‌ده و دستور دوم یک نمای کلی از وضعیت مدیر سیستم می‌ده. اگه خروجی degraded دیدی، الزاماً به معنی شکست کامل بوت نیست؛ ممکنه یک یا چند Unit شکست خورده باشن و بقیه سیستم همچنان کار کنه. در محیط بدون systemd هم ممکنه دستور اصلاً قابل استفاده نباشه.

بیایم مسیر بوت رو مثل یک پرونده شواهد بررسی کنیم

من برای این درس یک مدل ساده طراحی کردم که اسمش رو می‌ذاریم «پرونده پنج ایستگاه». هر وقت کسی گفت لینوکس بالا نمیاد، قبل از اجرای دستور تعمیر، این پنج سؤال رو ازش می‌پرسیم : آخرین چیزی که روی صفحه دیده چی بوده؟ آیا منوی بوت داشته؟ آیا Kernel پیام داده؟ آیا صفحه ورود دیده شده؟ آیا مشکل فقط مربوط به یک سرویسه؟ این سؤال‌ها جای لاگ رو نمی‌گیرن؛ کمک می‌کنن بفهمیم اول کدوم لاگ رو بخونیم. گاهی پاسخ فقط یکی از این سؤال‌ها معلوم می‌کنه بررسی بوت لینوکس باید از Firmware شروع بشه یا از systemd.

آزمایش اول : بدون تغییر سیستم، شواهد بوت فعلی رو بخون

اگه Ubuntu، Debian یا هر توزیع مبتنی بر systemd روی ماشین واقعی یا VM داری، این بخش رو همون‌جا اجرا کن. عمداً سراغ دستورهای فقط‌خواندنی می‌ریم. ممکنه برای دیدن بعضی رکوردهای Journal به مجوز اضافه نیاز داشته باشی؛ اگه دسترسی نداری، قرار نیست همین حالا دسترسی سیستم رو تغییر بدی.

uname -r
cat /proc/cmdline
ps -p 1 -o pid=,comm=

الان از این سه فرمان سه جور داده گرفتی : نسخه هسته فعال، پارامترهای راه‌اندازی و مدیر فرایند اصلی. هیچ‌کدوم به‌تنهایی سالم بودن بوت قبلی رو ثابت نمی‌کنن. فقط یک تصویر ابتدایی از محیط فعلی می‌دن.

journalctl --list-boots
journalctl -b -p warning --no-pager

فرمان اول فهرست Bootهایی رو که Journal واقعاً ازشون رکورد داره نشان می‌ده؛ ممکنه به خاطر غیرپایدار بودن لاگ‌ها یا تنظیمات سیستم فقط بوت فعلی قابل مشاهده باشه. فرمان دوم پیام‌های سطح Warning و شدیدترِ بوت فعلی رو می‌خونه. حواست باشه Warning لزوماً خطای بحرانی یا علت اصلی مشکل نیست؛ بعضی هشدارها با وجود اجرای سالم سیستم ثبت می‌شن.

journalctl -b -1 -p warning --no-pager

اینجا -1 یعنی «بوت قبلیِ موجود در Journal»، نه الزاماً «دیروز». اگه رکوردی ذخیره نشده باشه، دستور هم نمی‌تونه زمان رو به عقب برگردونه. این فرق ساده وقتی دنبال خطای بعد از آپدیت هستی خیلی به کارت میاد. وقتی بوت لینوکس رو بعد از یه آپدیت بررسی می‌کنی، زمان بوت ثبت‌شده رو هم با ساعت وقوع مشکل تطبیق بده.

systemctl --failed
systemctl list-units --type=service --state=failed

اینا فقط فهرست Unitهای شکست‌خورده رو نمایش می‌دن. خالی بودن لیست به معنی نبودن هر نوع مشکل نیست؛ ممکنه مشکل بیرون از systemd باشه یا سرویسی از نظر سیستم فعال به نظر بیاد اما وظیفه اصلی خودش رو انجام نده.

تفاوت dmesg و journalctl رو بدون؛ هر کدوم یه تکه از ماجرا رو می‌گن

یه سؤال رایج اینه که «برای مشکل بوت، dmesg بزنم یا journalctl؟» جوابش به چیزی بستگی داره که می‌خوای پیدا کنی. دستور dmesg پیام‌های حلقه ثبت وقایع Kernel رو نشون می‌ده و برای بررسی اتفاق‌های سطح هسته و دستگاه‌ها مفیده. در مقابل، journalctl روی سیستم‌های مبتنی بر systemd می‌تونه رخدادهای هسته، سرویس‌ها و بخش‌های دیگه رو با فیلترهای دقیق‌تر در اختیارمون بذاره. برای عیب‌یابی بوت لینوکس معمولاً کنار هم گذاشتن پیام‌های Kernel و رخدادهای سرویس‌ها تصویر دقیق‌تری می‌ده.

فرض کن توی «نقشه‌خانه» دیسک آرشیو شناسایی نشده. دیدن پیام‌های هسته می‌تونه بگه دستگاه ذخیره‌سازی اصلاً شناخته شده یا نه، ولی برای فهمیدن اینکه چرا یک Mount یا Unit شکست خورده باید گزارش‌های systemd رو هم بررسی کنی. این دو ابزار رقیب نیستن؛ هر کدوم شواهد متفاوتی رو قابل مشاهده می‌کنن.

dmesg --level=err,warn | tail -n 40
journalctl -k -b -p warning --no-pager

اگه dmesg خطای مجوز داد، معنیش خراب بودن Kernel نیست. بعضی سیستم‌ها دسترسی خواندن پیام‌های هسته رو محدود می‌کنن و ممکنه تو با حساب معمولی نتونی خروجی رو ببینی. ضمن اینکه بافر پیام‌های Kernel محدود و ممکنه در طول زمان بازنویسی بشه؛ پس برای بررسی رویدادهای بوت قبلی، وجود Journal پایدار اهمیت پیدا می‌کنه.

یک گزارش بوت خوب باید چه اطلاعاتی داشته باشه؟

وقتی می‌خوای برای یک همکار یا تیم فنی مشکل رو گزارش کنی، فقط نگوی «سرور بوت نمی‌شه». بهتره زمان اتفاق، آخرین تصویری که دیده شده، تغییرات قبل از خرابی، محیط BIOS/UEFI یا VM، نسخه Kernel در صورت دسترسی و خطای دقیق لاگ رو ثبت کنی. حتی یک عکس واضح از پیام grub rescue از ده خط توضیح مبهم مفیدتره.

توی پرونده فرضی ما، یک گزارش خوب این شکلیه : «بعد از به‌روزرسانی، دستگاه به منوی Firmware و Kernel رسیده، سپس در systemd emergency mode به خاطر شکست Mount مسیر /srv/maps متوقف شده. شناسه دیسک و لاگ Mount هنوز باید بررسی بشن.» این گزارش نمی‌گه «آپدیت حتماً مقصر بوده»؛ فقط زمان‌بندی و شواهد رو کنار هم می‌ذاره تا نفر بعدی بدون حدس بی‌جا ادامه بده.

آزمایش دوم : بوت چرا کند شده؟

فرض کن سرور «نقشه‌خانه» بالا میاد، ولی بیشتر از قبل طول می‌کشه تا آماده بشه. اینجا به‌جای حدس درباره خراب‌شدن دیسک، زمان مرحله‌های بوت رو نگاه می‌کنیم. روی سیستم‌های مبتنی بر systemd، ابزار systemd-analyze برای این بررسی مفیده.

systemd-analyze time
systemd-analyze blame
systemd-analyze critical-chain

فرمان time زمان‌بندی کلی رو گزارش می‌کنه، blame بعضی Unitها رو براساس مدت فعال‌سازی فهرست می‌کنه و critical-chain وابستگی‌های زمانی مسیر مهم راه‌اندازی رو نشون می‌ده. اما عدد بالای blame به‌تنهایی یعنی «همین سرویس مقصر قطعی کندی»؟ نه؛ بعضی Unitها منتظر منابع یا Unitهای دیگه می‌مونن، بعضی هم با این روش اصلاً زمان‌سنجی قابل‌مقایسه ندارن.

برای مثال، اگه یک Mount منتظر دیسک جداشده باشه، تأخیر ممکنه روی چند بخش دیگه اثر بذاره. بدون دانستن وابستگی‌ها، غیرفعال کردن تصادفی سرویس‌ها کار درستی نیست. در درس بعدی LPIC-1 درباره خود systemd و مدیریت سرویس‌ها مفصل‌تر کار می‌کنیم؛ اینجا فقط ابزار مشاهده رو معرفی می‌کنیم. اگه مسیر critical-chain یه وابستگی رو نشون داد، برای عیب‌یابی بوت لینوکس زمان‌بندی اون زنجیره رو با تغییرات اخیر سیستم مقایسه کن.

خطاهای معروف بوت لینوکس رو قاطی نکن

۱. صفحه No bootable device

وقتی دستگاه می‌گه هیچ گزینه‌ای برای بوت پیدا نکرده، هنوز نمی‌تونیم نتیجه بگیریم فایل‌سیستم لینوکس خراب شده. اول باید بررسی بشه دیسک دیده می‌شه یا نه و ورودی بوت Firmware کجاست. تغییر ناگهانی حالت UEFI/Legacy هم ممکنه کاری کنه سیستم مسیر قبلی رو پیدا نکنه.

۲. صفحه grub rescue

وقتی به grub rescue> می‌رسی، دست‌کم بخش GRUB اجرا شده ولی حالت عادی در دسترس نیست. مشکل ممکنه از مسیر فایل‌های GRUB، پارتیشن یا تغییر چیدمان دیسک باشه. در این شرایط استفاده از دستورهای اینترنتی بدون تطبیق با نوع نصب می‌تونه ریسک داشته باشه.

۳. پیام Kernel panic

وقتی Kernel panic می‌بینی، هسته به وضعیتی رسیده که نمی‌تونه با اطمینان ادامه بده. اما خود عبارت Kernel panic به‌تنهایی علت رو نمی‌گه. متن همراهش، وضعیت درایورها، دیسک ریشه، نسخه هسته و تغییرات اخیر مهمن. یک Panic با پیام مربوط به Mount ریشه، پرونده متفاوتی از خرابی یک ماژول خاص داره.

۴. صفحه initramfs یا dracut emergency shell

وقتی وارد محیط اضطراری initramfs می‌شی، معمولاً مشکل در آماده‌کردن محیط ریشه است. شاید مسیر ریشه پیدا نشده، شاید دیسک رمزگذاری‌شده باز نشده یا یک فایل‌سیستم نیاز به بررسی داره. اینجا اجرای بی‌برنامه ابزار تعمیر فایل‌سیستم روی دیسک واقعی بدون نسخه پشتیبان و شناخت وضعیت، تصمیم امنی نیست.

۵. حالت systemd emergency یا سرویس شکست‌خورده

وقتی systemd به emergency mode رسیده، به این معنی نیست که کل بوت از ابتدا شکست خورده. اتفاقاً به مرحله‌ای رسیده‌ایم که اطلاعات لازم برای بررسی Unitها و Mountها ممکنه در دسترس باشه. وضعیت دیسک‌هایی که در /etc/fstab تعریف شدن، یکی از سرنخ‌هاست؛ اما بدون شاهد نباید اون فایل رو ویرایش کنیم.

پرونده «نقشه‌خانه» رو با شواهد حل کنیم

حالا برگردیم به همون مجموعه فرضی. فرض کن اپراتور می‌گه صفحه ورود اومده، اما پنل آرشیو اجرا نشده. اولین فرضیه ما نباید خرابی GRUB باشه. اول وضعیت سرویس، فایل لاگ برنامه و اتصال به دیتابیس رو بررسی می‌کنیم. در این حالت بخش مهمی از مسیر بوت با موفقیت طی شده و مشکل احتمالاً مربوط به مرحله‌ای بعد از بوت پایه است.

اما در سناریوی دوم، کنسول پیام مربوط به شکست Mount داده و وارد Emergency Mode شده. اینجا پرونده رو این‌طور ثبت می‌کنیم : «Firmware دستگاه رو بالا آورده، Kernel اجرا شده و systemd هم به مرحله تلاش برای Mount رسیده؛ پس اول دنبال دلیل شکست Mount بگرد.» این هنوز تشخیص قطعی علت نیست، ولی محدوده جست‌وجو رو خیلی کوچک می‌کنه.

systemctl --failed
journalctl -b -p err --no-pager
lsblk -f
findmnt --verify

فرمان‌های بالا برای جمع‌آوری شواهدن. findmnt --verify پیکربندی Mount رو بررسی می‌کنه، ولی ممکنه هشدارهایی درباره وضعیت فعلی بده که نیاز به تفسیر دارن. lsblk -f هم نمایی از دستگاه‌ها، فایل‌سیستم‌ها و شناسه‌ها می‌ده. هیچ‌کدوم رو به معنی مجوز تغییر شناسه دیسک، فرمت یا تعمیر خودکار در نظر نگیر.

فرض کنیم لاگ آزمایشی چنین پیامی رو نشون بده : Failed to mount /srv/maps. مهم‌ترین کار اینه که بفهمیم این مسیر به چه دستگاهی وابسته‌ست و اون دستگاه الان دیده می‌شه یا نه. اگه دیسک USB از دستگاه جدا شده باشه، با نصب دوباره GRUB چیزی درست نمی‌شه. اگه دیسک هست ولی شناسه‌اش با تنظیمات نمی‌خونه، باز هم مسئله جای دیگه‌ست. این همون جور فکر کردنه که می‌خوام از این درس با خودت ببری.

آزمایش آفلاین : از روی نشونه، مرحله احتمالی رو پیدا کن

برای اینکه بدون خطر خراب کردن بوت سیستم تمرین کنیم، یه برنامه کوچیک Python می‌نویسیم. این برنامه هیچ دستور مدیریتی اجرا نمی‌کنه، دیسکی رو دست‌کاری نمی‌کنه و به شبکه وصل نمی‌شه. فقط چند «نشانه فرضی» می‌گیره و می‌گه بررسی اولیه رو از کجا شروع کنیم. دقت کن این یک ابزار تشخیصی واقعی نیست؛ یک تمرین دسته‌بندی مرحله‌های بوت برای دانشجوست.

cases = {
    "no_boot_device": "Firmware / boot entry",
    "grub_rescue": "Bootloader",
    "initramfs_prompt": "Kernel / early userspace / root filesystem",
    "emergency_mode": "systemd / mounts / units",
    "login_ok_app_down": "Application / service after base boot",
}

for clue, first_check in cases.items():
    print(f"{clue} -> {first_check}")

no_boot_device -> Firmware / boot entry
grub_rescue -> Bootloader
initramfs_prompt -> Kernel / early userspace / root filesystem
emergency_mode -> systemd / mounts / units
login_ok_app_down -> Application / service after base boot

حالا ازت می‌خوام برای هر مورد، یک سؤال تکمیلی بنویسی. مثلاً برای grub_rescue بپرس «قبل از این مشکل پارتیشن‌ها جابه‌جا شدن؟» و برای login_ok_app_down بپرس «سرویس برنامه فعاله و به پورت مورد انتظار گوش می‌ده؟» یادت باشه خروجی برنامه فقط مرحله احتمالی رو پیشنهاد می‌ده و جای لاگ یا بررسی واقعی سیستم رو نمی‌گیره.

هفت اشتباه رایج موقع عیب‌یابی بالا نیامدن لینوکس

اشتباه اول اینه که «صفحه سیاه» رو معادل خرابی Kernel بدونیم. صفحه سیاه ممکنه از نمایشگر، درایور گرافیک، مدیر ورود یا مرحله‌های قبلی بیاد. بدون شواهد مرحله رو تعیین نکن. اشتباه دوم هم اینه که برای هر مشکلی سراغ GRUB بریم؛ درحالی‌که گاهی GRUB کار خودش رو کاملاً درست انجام داده.

اشتباه سوم، اجرا کردن بی‌برنامه fsck یا فرمان‌های تغییر دیسکه. بعضی عملیات تعمیر باید روی فایل‌سیستم Unmountشده انجام بشن و ممکنه ریسک از دست رفتن داده داشته باشن. اشتباه چهارم، تغییر چند تنظیم هم‌زمانه؛ وقتی بعداً سیستم بالا بیاد یا خراب‌تر بشه، دیگه نمی‌فهمی کدوم تغییر اثر گذاشته.

اشتباه پنجم اینه که خروجی systemd-analyze blame رو حکم قطعی علت کندی بدونیم. اشتباه ششم، قاطی کردن بوت موفق با سالم بودن برنامه است. اشتباه هفتم هم نادیده گرفتن آخرین تغییر : آپدیت Kernel، تغییر تنظیمات Mount، وصل یا جدا کردن دیسک، یا جابه‌جایی تنظیمات Firmware ممکنه سرنخ بسیار مهمی باشن، ولی خودِ هم‌زمانی هنوز اثبات علت نیست.

از کجا بفهمیم دستورات آموزشی رو روی سیستم خودمون می‌تونیم اجرا کنیم؟

قبل از هر تمرین باید محیطت رو بشناسی. اگه داخل ماشین مجازی هستی، Snapshot گرفتن قبل از تغییرات بزرگ کار منطقیه. اگه روی سرور واقعی کار می‌کنی، حتی دستورهایی که به نظر ساده میان باید با سطح دسترسی و حساسیت داده سنجیده بشن. در این درس فرمان‌های عملی عمدتاً برای مشاهده‌ان؛ دستورهایی مثل نصب مجدد Bootloader، بازنویسی فایل‌سیستم یا تغییر Target پیش‌فرض رو عمداً اجرا نمی‌کنیم.

اگه سیستم واقعاً بالا نمیاد، ممکنه دسترسی به journalctl هم نداشته باشی. اون موقع روش کار بسته به داشتن کنسول، Live Environment، دسترسی ارائه‌دهنده سرور و نوع نصب عوض می‌شه. این تفاوت رو فراموش نکن؛ آموزش یک دستور که فقط روی سیستم بالااومده کار می‌کنه، معجزه‌ای برای ماشین کاملاً خاموش نیست.

این درس LPIC-1 دقیقاً کجای مسیر یادگیری قرار می‌گیره؟

طبق سرفصل رسمی LPI، موضوع 101.2 Boot the System شامل ترتیب بوت از BIOS/UEFI، Bootloader، Kernel، initramfs، آشنایی با init و systemd و بررسی رخدادها با ابزارهایی مثل dmesg و journalctl هست. ما همین نقشه رو مبنا قرار دادیم، ولی تلاش کردیم هر قسمت رو به یک سؤال عیب‌یابی واقعی وصل کنیم، نه اینکه فقط اسم‌ها رو حفظ کنی.

اگه درس‌های مسیر رایگان Linux Essentials رو گذروندی، احتمالاً الان با Terminal، فایل‌سیستم و Permissionها آشنایی داری. اینجا یک قدم جلوتر رفتیم : داری رفتار کل ماشین رو از لحظه روشن‌شدن تا آماده‌شدن سرویس‌ها بررسی می‌کنی. درس بعدی LPIC-1 روی مدیریت سرویس‌ها با systemd و systemctl تمرکز خواهد داشت و قرار نیست دوباره همین مسیر Firmware تا Kernel رو تکرار کنه.

اگه هم می‌خوای این بحث رو همراه با تمرین‌های عمیق‌تر، مدیریت واقعی سرویس‌ها، مشکلات بوت و سایر بخش‌های LPIC-1 دنبال کنی، سرفصل‌ها و نمونه تدریس دوره کامل LPIC-1 نابغه‌ها رو ببین. لازم نیست همین الان چیزی بخری؛ اول مطمئن شو این مدل یادگیری و سطح آموزشی با هدفت هماهنگه.

تمرین نهایی : قبل از دیدن پاسخ، خودت تصمیم بگیر

تمرین اول : سرور روشن می‌شه و صفحه grub rescue> رو می‌بینی. بین «بررسی Bootloader» و «بررسی سرویس وب» کدوم اولویت داره و چرا؟ تمرین دوم : لاگ نشون می‌ده یک Mount شکست خورده و سیستم به Emergency Mode رفته. از بین UUID، دیسک فیزیکی، تنظیمات سرویس وب و فونت ترمینال، کدوم سرنخ‌ها رو زودتر بررسی می‌کنی؟

تمرین سوم : کاربر به لینوکس وارد شده، ولی برنامه داخلی باز نمی‌شه. آیا باید این وضعیت رو بدون بررسی بیشتر «بوت ناموفق» بنامیم؟ تمرین چهارم : خروجی systemd-analyze blame برای یک سرویس زمان بالایی نشون می‌ده. آیا می‌تونی فوراً اون سرویس رو غیرفعال کنی؟ اگر نه، چه شواهد دیگه‌ای لازم داری؟

پاسخ راهنما : در تمرین اول GRUB به مرحله مربوط نزدیک‌تره. در تمرین دوم شناسه دستگاه، موجود بودن دیسک و وابستگی Mountها مهمن. در تمرین سوم بوت پایه احتمالاً انجام شده و باید مسیر سرویس برنامه رو جدا بررسی کرد. در تمرین چهارم زمان بالای فعال‌سازی به‌تنهایی دلیل کافی برای حذف سرویس نیست؛ باید وابستگی‌ها و اثرش روی کارکرد سیستم رو هم فهمید.

سؤال‌های متداول درباره بوت لینوکس

منابع معتبر برای بررسی بیشتر

برای اینکه تفاوت اصطلاحات و رفتار سیستم‌ها رو درست یاد بگیری، این منابع رسمی و فنی رو مبنا قرار بده : معرفی رسمی LPIC-1 و اهداف نسخه ۵ آزمون، راهنمای منوی GRUB، مراحل بوت در مستندات systemd، مستندات journalctl و مستندات systemd-analyze. توضیح‌ها و مثال‌های این صفحه مستقل نوشته شدن و این لینک‌ها برای راستی‌آزمایی و مطالعه عمیق‌ترن.