محتوای آموزشی وبلاگ نت‌آرام
سرور را ریبوت کرده‌اید، اما به‌جای بالا آمدن برنامه‌ها، کنسول پیام
You are in emergency mode نشان می‌دهد. یکی از علت‌های ممکن این است که لینوکس می‌خواهد دیسکی را با شناسه‌ای که در /etc/fstab نوشته شده متصل کند، ولی آن شناسه دیگر پیدا نمی‌شود. این اتفاق ممکن است پس از تعویض دیسک، بازیابی نسخه پشتیبان یا تغییر تنظیمات مانت رخ دهد.Emergency Mode علت‌های دیگری هم دارد؛ بدون خواندن خطا نمی‌توان گفت حتماً fstab مقصر است. این راهنما برای زمانی است که گزارش بوت به اتصال فایل‌سیستم یا UUID اشاره می‌کند. دستورها در کنسول خود سرور اجرا می‌شوند، چون در این وضعیت SSH ممکن است هنوز فعال نباشد. پیش از هر تغییر، از اطلاعات و روش بازیابی مطمئن شوید و از فرمت‌کردن یا اجرای تعمیرهای ناشناخته خودداری کنید.
۱. وارد کنسول شوید و خطای اصلی را بخوانید
در پنل ارائه‌دهنده سرور مجازی، کنسول یا VNC سرور را باز کنید. اگر سیستم برای ورود به حالت نگهداری رمز حساب مدیر می‌خواهد، با مجوز لازم وارد شوید. اگر کنسول ندارید یا فایل‌سیستم اصلی بالا نیامده است، از حالت Rescue ارائه‌دهنده و راهنمای همان محیط استفاده کنید؛ مسیر فایل‌های سیستم اصلی در محیط Rescue ممکن است با مسیرهای این مقاله متفاوت باشد.
در محیطی که systemd و گزارش آن در دسترس است، خطاهای بوت فعلی را ببینید:
کد / دستورjournalctl -xb -p err --no-pager
به پیام‌هایی مانند
کد / دستورFailed to mount، Timed out waiting for device و نام مسیر یا UUID دقت کنید. برای دیدن سرویس‌ها و مانت‌های شکست‌خورده:systemctl --failed
مسیر شکست‌خورده را یادداشت کنید. اگر گزارش به خطای ورودی‌خروجی، خرابی کنترلر یا فایل‌سیستم اشاره می‌کند، مسئله فقط یک UUID اشتباه نیست و به بررسی سلامت و بکاپ نیاز دارد.
۲. فایل fstab و دستگاه‌های واقعی را کنار هم بگذارید
کد / دستورcat /etc/fstab
هر خط فعال معمولاً منبع، مسیر مانت، نوع فایل‌سیستم و گزینه‌ها را مشخص می‌کند. برای مثال، خط فرضی زیر می‌گوید یک فایل‌سیستم ext4 باید در
کد / دستور/backup متصل شود:UUID=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee /backup ext4 defaults 0 2
این UUID نمونه است و نباید در سرور شما کپی شود. برای دیدن دستگاه‌ها و شناسه‌های واقعی:
کد / دستورlsblk -o NAME,SIZE,FSTYPE,UUID,MOUNTPOINT
و برای اطلاعات بیشتر، با دسترسی مدیر:
کد / دستورsudo blkid
در خروجی‌ها، دیسک، پارتیشن، نوع فایل‌سیستم و UUID را با مستندات سرور یا پنل ارائه‌دهنده تطبیق دهید. اگر دو دیسک کلون‌شده UUID تکراری دارند، دستگاه درست را از روی شماره ردیف حدس نزنید. اگر دیسک مورد انتظار اصلاً دیده نمی‌شود، ابتدا اتصال یا تخصیص آن را از سمت پلتفرم و سلامت سخت‌افزار بررسی کنید؛ تغییر UUID در fstab دیسک غایب را برنمی‌گرداند.
برای دیدن اینکه ریشه سیستم روی چه چیزی قرار دارد:
کد / دستورfindmnt -n -o SOURCE,FSTYPE,OPTIONS /
اگر خط مشکل‌دار مربوط به
/، /boot یا مسیر ضروری سرویس است، حذف یا کامنت‌کردن آن می‌تواند بوت یا داده‌ها را به خطر بیندازد. در این حالت از روش بازیابی مناسب سیستم‌عامل و ارائه‌دهنده کمک بگیرید و ابتدا هویت دستگاه را مشخص کنید.۳. پیش از ویرایش نسخه پشتیبان بسازید
اگر فایل‌سیستم ریشه اجازه نوشتن می‌دهد، یک نسخه از فایل فعلی بسازید:
کد / دستورsudo cp -an /etc/fstab /etc/fstab.before-uuid-fix
گزینه
کد / دستور-n نسخه هم‌نام موجود را جایگزین نمی‌کند؛ اگر چنین فایلی از قبل دارید، نام تازه‌ای انتخاب کنید. وجود بکاپ را ببینید:sudo ls -l /etc/fstab.before-uuid-fix
اگر سیستم به دلیل خطای دیسک یا فایل‌سیستم به حالت فقط‌خواندنی رفته، برای نوشتن تنظیمات آن را کورکورانه read-write نکنید. ابتدا علت خطا و سلامت داده را بررسی کنید. در برخی محیط‌های نگهداری، ریشه سالم صرفاً به‌طور موقت read-only مانت شده است. پس از تأیید این وضعیت و نبود خطای سخت‌افزاری یا نیاز به تعمیر فایل‌سیستم، برای همین محیط می‌توانید از کنسول دستور زیر را اجرا کنید:
کد / دستورsudo mount -o remount,rw /
در پوسته‌ای که از قبل با root وارد شده‌اید ممکن است
sudo لازم نباشد. سپس دوباره findmnt -n -o SOURCE,FSTYPE,OPTIONS / را بزنید و وجود rw را ببینید. اگر remount خطا داد یا گزارش I/O دارید، آن را با گزینه‌های اجباری تکرار نکنید؛ بازیابی و بررسی فایل‌سیستم را از محیط مناسب و با بکاپ انجام دهید. پس از قابل نوشتن شدن ریشه، دستور کپی پشتیبان بالا را دوباره اجرا و وجود فایل را تأیید کنید.۴. UUID اشتباه را فقط پس از شناسایی دیسک درست اصلاح کنید
اگر دیسک موردنظر واقعاً موجود است و با شواهد مطمئن فهمیده‌اید UUID فایل‌سیستم آن عوض شده، فایل را باز کنید:
کد / دستورsudo nano /etc/fstab
فقط UUID خط همان مانت را با UUID واقعی همان فایل‌سیستم جایگزین کنید. مسیر مانت، نوع فایل‌سیستم و دیگر گزینه‌ها را بدون دلیل تغییر ندهید. در nano با Ctrl+O و Enter ذخیره و با Ctrl+X خارج شوید. اگر
nano موجود نیست، از ویرایشگر نصب‌شده‌ای که کار با آن را می‌دانید استفاده کنید.اگر دیسک غایب مربوط به یک مقصد غیراصلی مثل بکاپ است و مطمئن هستید سرویس مهمی برای داده زنده به آن وابسته نیست، می‌توانید برای بازگرداندن بوت، با گذاشتن
# در ابتدای همان خط آن را موقتاً غیرفعال کنید. این کار داده دیسک را حذف نمی‌کند، اما تا زمان اتصال دوباره، آن مقصد در دسترس نخواهد بود. اگر برنامه بکاپ بدون مانت در همان پوشه بنویسد، ممکن است دیسک اصلی پر شود؛ پس کار بکاپ را تا رفع مقصد متوقف نگه دارید. هرگز خط ریشه یا مسیر حیاتی را صرفاً برای رد شدن از خطا کامنت نکنید.۵. فایل را بررسی و فقط مانت مربوط را آزمایش کنید
در نسخه‌هایی از
کد / دستورfindmnt که گزینه verify دارند:sudo findmnt --verify --verbose
هشدارهای نحوی و مسیرهای مشکل‌دار را بخوانید و اصلاح کنید. موفقیت این فرمان تضمین نمی‌کند همه دیسک‌ها سالم یا هر سرویس قابل استفاده است. اگر فایل را در یک سیستم مبتنی بر systemd تغییر داده‌اید، تعریف واحدها را بازخوانی کنید:
کد / دستورsudo systemctl daemon-reload
برای یک مقصد غیرحیاتی که دستگاه و تعریف آن تأیید شده است، همان مسیر را جداگانه آزمایش کنید:
کد / دستورsudo mount /backup
این مثال فقط وقتی مناسب است که خط
/backup فعال و درست باشد. اگر آن را موقتاً کامنت کرده‌اید یا منبعش در دسترس نیست، انتظار موفقیت نداشته باشید. به‌جای اجرای بی‌هدف mount -a، ابتدا اثر هر مانت را بشناسید؛ آن دستور ممکن است چند فایل‌سیستم دیگر را هم تحت تأثیر قرار دهد.برای تأیید منبع متصل‌شده:
کد / دستورfindmnt -M /backup -o TARGET,SOURCE,FSTYPE,OPTIONS
منبع و نوع فایل‌سیستم را با آنچه انتظار دارید مقایسه کنید. اگر خطا به I/O یا خرابی فایل‌سیستم اشاره دارد، از راهنمای فایل‌سیستم فقط‌خواندنی کمک بگیرید. اجرای
fsck روی فایل‌سیستم در حال استفاده یا انتخاب دستگاه اشتباه می‌تواند به داده آسیب بزند؛ قبل از هر تعمیر از بکاپ و روش مخصوص همان فایل‌سیستم مطمئن شوید.۶. راه‌اندازی و آزمون نهایی
وقتی خطای اصلی را رفع کرده‌اید و مسیر بازگشت در اختیار دارید، در زمان مناسب سرور را با روش معمول ریبوت کنید:
کد / دستورsudo reboot
کنسول را باز نگه دارید. پس از بالا آمدن، دوباره
systemctl --failed و دستور findmnt مربوط به مقصد را اجرا کنید. سپس اتصال SSH و خود برنامه‌ای را که از آن دیسک استفاده می‌کند امتحان کنید. اگر مانت بکاپ را موقتاً غیرفعال کرده‌اید، برنامه بکاپ را تا زمان اتصال و تأیید مقصد درست فعال نکنید.اگر همچنان به حالت اضطراری برمی‌گردید، پیام جدید را ثبت کنید: ممکن است UUID مشکل اول بوده و اکنون خطای دیگری مثل دیسک غایب یا فایل‌سیستم آسیب‌دیده مانده باشد. در راهنمای عیب‌یابی fstab مایکروسافت برای ماشین لینوکسی نیز نمونه‌های خطا و بازیابی توضیح داده شده‌اند؛ مراحل پلتفرمی آن را بدون تطبیق با ارائه‌دهنده خود اجرا نکنید.
این عیب‌یابی می‌تواند هم برای سرور مجازی ایران و هم برای سرور اختصاصی ایران کاربرد داشته باشد؛ هنگام انتخاب، دسترسی به کنسول و روش بازیابی دیسک را متناسب با محیط خود بررسی کنید.
برچسب‌ها:
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام