این راهنما برای افرادی که vps دارند و به کنسول آن یا VNC دسترسی ندارند و برای افرادی که به طور خاص از سرویس EC2 آمازون استفاده میکنند مفید و قابل استفاده است.
شرح و بررسی مسئله
فهرست مندرجات
سیمپتومها
۱- وقتی به ویپیاس لاگین یا اساساچ کردید با این پیغام مواجه شدید:
.*** /dev/xvda1 should be checked for errors ***
این ارور به طور مشخص میگه پارتیشن اول دیسک xvda مشکل داره و برای حل این مشکل باید کامند fsck روی این پارتیشن اجرا شه:
fsck /dev/xvda1
۲- موقع ویرایش یک فایل این ارور رو میگیرین:
Read only file system
نگاه کردن به dmesg نشانههای بهتری از مشکل بهتون میده و میگه مشکل نوعن سختافزاریست.
دلایل بروز مشکل
فایلسیستمهای xfs کمتر از ext4 این مشکل رو پیدا میکنن برای همینه که توزیعهایی مثه سنت در نسخههای جدیدترشون به صورت پیشفرض موقع نصب xfs رو پیشنهاد میکنن.
یکی از عوامل موثر دیگر تغییر دادن سایز پارتیشنهاست. یکی دیگر از دلایل میتواند منتقل شدن ماشین مجازی یا دیسکهای روی آن از یک دیسک فیزیکی به یک دیسک فیزیکی دیگر باشد. مثلا وقتی یک هارد سرور بسوزد و شما آن را با یک هارد سالم تعویض کنید سختافزاری که دیسک ماشین مجازی شما روی آن قرار دارد تغییر میکند و برای همین شما در اولین بوت ماشین مجازیتان با این ارور مواجه خواهید شد.
راهحلهای تیریویا و شکست خورده
قبلا هم این مشکل رو تو ESX دیده بودم که بعد از یه مدت دیسک مشکل پیدا میکنه ولی اونجا وقتی این مشکل پیش میومد موقع بوتشدن گیر میکرد و یه شل میداد که از همونجا میشد این کامند رو ران کرد و مشکل حل میشد اما اینجا سیستم درست بوت شده که میشه این ارور رو تو ولکام مسیج سرور دید. اگر دستور بالا رو توی ترمینال وارد کنید بهتون ارور میده و اجرا نمیشه دلیلش اینه که پارتیشن مشکلدار مانت شده و شما هم نمیتونید این پارتیشن رو آنمانت کنید چون همین سیستمعاملی که الان بهش وصلید و میخواید این دستور رو توش وارد کنید روی این پارتیشنه و نمیتونید خودتون رو آنمانت کنید:
/dev/xvda1 is mounted.
برای حل این مشکل یک راه غیراصولی و بد وجود داره و اونم اینه که سیستم رو فورس کنیم که بدون آنمانت کردن فایل سیستم رو فیکس کنه. اما ور رفتن با فایلسیستم وقتی که مانت شده و در حال استفادس ممکنه بهش آسیب بزنه. یک راه اصولیتر اینه که به سیستم بگیم وقتی ریبوت میشه قبل از اینکه سیستمعامل کامل بالا بیاد این چک رو انجام بده. اینکار با قرار دادن یک فایل خالی با یک نام بهخصوص در دایرکتوری اسلش سرور قابل انجامه. اما این روش هم مشکل داره. اگر قبلن با همین مشکل روی کامپیوتر شخصیتون برخورد کرده باشید میدونید قبل اینکه سیستم کامل بوت شه ازتون میخواد برای فیکس کردن مشکل کلید F رو فشار بدید و برای ایگنور کردن کلید I ولی ما تا وقتی سیستم کامل روشن نشه نمیتونیم بهش ssh بزنیم و کلید F یا I رو فشار بدیم و عملن به اون state دسترسی نداریم. راه اصولی حل این مشکل موضوعیه که در این مقاله میخوام بهش بپردازم.
راهحل
فعال کردن امکان چک کردن فایل سیستم روت
فایل /etc/fstab را باز کنید:
nano /etc/fstab
یک خط مشابه این مشاهده میکنید:
LABEL=cloudimg-rootfs / ext4 defaults,discard 0 0
مقدار fs_passno برای فایلسیستم ریشه را از صفر به یک تغییر دهید:
LABEL=cloudimg-rootfs / ext4 defaults,discard 0 1
مقدار دیفالت fs_passno صفر است که میگوید هنگام بوت نباید فایلسیستم را با fsck چک کند. همانطور که گفته شد موقع بوت ممکن است سیستم سوال کند که آیا میخواهی با fsck فیکس کنم (در نسخههای دسکتاپ) یا به ما شل روت بدهد که خودمان دستور fsck را در آن وارد کنیم (در نسخههای سرور) و ما موقع بوت به سرور دسترسی نداریم که جوابش را بدهیم یا کنسولی نداریم که در شل روت کامند فوق را قبل از بوت و مانت شدن دیسک وارد کنیم و به همین خاطر تو مرحله بوت گیر میکند اما یک کردن این متغیر میگوید وقتی لازم بود، این چک از طریق fsck انجام شود.
تنظیم fsck برای فیکس اتوماتیک مشکل
گام بعد اینست که به سیستم بگویید مشکلی که fsck پیدا میکند را به طور اتوماتیک حل کند. برای این منظور فایل زیر را باز کنید:
nano /etc/default/rcS
این خط را پیدا کنید:
FSCKFIX=no
و به این تغییر دهید:
FSCKFIX=yes
ریبوت و اطمینان از حل شدن مشکل
حال برای اینکه زمان آخرین چک فایل سیستم را بفهمید دستور زیر را وارد کنید:
tune2fs -l /dev/xvda1 | grep "Last checked"
زمان اعلام شده را یک جا سیو کنید و سیستم را ریبوت کنید:
reboot
دوباره زمان آخرین چک فایل سیستم را به دست آورید و با زمان قبلی اعلام شده مقایسه کنید. اگر زمان اعلام شده درست بود یعنی دیسک فیکس شده و میتوانید تنظیمات تغییر داده در /etc/default/rcS و /etc/fstab را به حالت اولیه برگردانید.