सिस्टम समय परिवर्तन के साथ प्रयोग करने की अनुमति देते हुए मैं "मैन्युअल रूप से fsck रन" संदेशों से कैसे बच सकता हूं?

Question

मैं एक ऐसी प्रणाली के साथ काम कर रहा हूँ जहाँ हम उपयोगकर्ताओं को यदि वे चाहें तो तारीख और समय के साथ खेलने की अनुमति दे सकते हैं, और जहाँ मनमाने तरीके से रिबूट हो सकता है। यह ठीक है, एक बात को छोड़कर: यदि एक बड़ा समय पीछे की ओर कूदता है, तो रिबूट पर निम्न त्रुटि दिखाई देती है:

Checking filesystems
IMAGE2: Superblock last mount time (Tue Mar  1 17:32:48 2011,
        now = Thu Feb 24 17:34:29 2011) is in the future.

IMAGE2: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
        (i.e., without -a or -p options)

*** An error occurred during the file system check.
*** Dropping you to a shell; the system will reboot
*** when you leave the shell.

… और फिर बूट उपयोगकर्ता हैंग इनपुट के इंतजार में लटका रहता है, और कंसोल एक्सेस प्राप्त होने के बाद भी जारी रखने के लिए रूट पासवर्ड की आवश्यकता होती है।

यह निश्चित रूप से आदर्श से कम है। क्या कोई तरीका है कि आप चेक को छोड़ दें या चेक को रिबूट पर स्वचालित रूप से होने के लिए मजबूर करें?

Google ने केवल सहायता प्रदान की है जिसे हिट होने पर मैन्युअल रूप से fsck चलाने की आवश्यकता होती है / जब यह हिट होता है, जो कि मैं उसके बाद नहीं हूं। समय सेट करने के बाद मैन्युअल रूप से fsck चलाना काम नहीं करता क्योंकि फाइल सिस्टम अभी भी उस बिंदु पर मुहिम कर रहा है, और पूरी तरह से fsck को अक्षम करना आदर्श से कम है।

मैं RedHat 6 का उपयोग कर रहा हूं।

अपडेट : वर्तमान में मैं जिस समाधान के साथ जा रहा हूं, वह रिस्टूट पर fsck जाँच को अक्षम करने के लिए fstab को हैक करना है। मैं डिस्क का उपयोग करके अंतिम माउंट समय को संपादित करने की कोशिश करता हूं debugfs, जो ext3 ड्राइव के लिए ठीक काम करता है, लेकिन ext4 पर असंगत रूप से विफल प्रतीत होता है।

Answer 1

मैं e2fsckआखिरी माउंट समय या भविष्य में आखिरी बार लिखने के लिए विशिष्ट चेक को अक्षम करने के लिए हैकिंग का सुझाव देने जा रहा था । ये problem.c / problem.h में परिभाषित किए गए हैं , और सुपर . c में उपयोग किए जाते हैं । लेकिन देखने में, मुझे पता चला कि E2fsprogs 1.41.10 एक नया विकल्प जोड़ता है /etc/e2fsck.confजिसे टूटी_सिस्टम_क्लॉक कहा जाता है । यह वही लगता है जो आपको चाहिए, और चूंकि आप Red Hat Enterprise Linux 6 का उपयोग कर रहे हैं, आपके पास 1.41.12 होना चाहिए, जिसमें यह विकल्प शामिल है। आदमी पृष्ठ से:

   broken_system_clock
          The e2fsck(8) program has some hueristics that assume  that  the
          system clock is correct.  In addition, many system programs make
          similar assumptions.  For example, the UUID library  depends  on
          time  not going backwards in order for it to be able to make its
          guarantees about issuing universally unique ID’s.  Systems  with
          broken  system clocks, are well, broken.  However, broken system
          clocks, particularly in embedded systems, do exist.  E2fsck will
          attempt  to  use  hueristics to determine if the time can no tbe
          trusted; and to skip time-based checks if this is true.  If this
          boolean  is set to true, then e2fsck will always assume that the
          system clock can not be trusted.

हां, मैन पेज "हेयूरिस्टिक्स" को स्पेल नहीं कर सकता है। उफ़। लेकिन संभवतः कोड वैसे भी काम करता है। :)

Comments

यह शानदार लग रहा है, सहेजें कि मैन पेज का तात्पर्य केवल ext2 और ext3 को प्रभावित करता है, और मैं ext3 और ext4 के संयोजन का उपयोग कर रहा हूं। फिर भी, मैं इसे अभी आज़माता हूँ, जैसे कि यह काम करता है, यह वही है जो मैं देख रहा हूँ।

— me_and

यह काम करता हैं! सहित ext4 पर। धन्यवाद!

— मेरे_और

Answer 2

मुझे संदेह है कि इस चेक को विशेष रूप से हटाने का एक तरीका है, स्रोत कोड को संशोधित करना। Fsck से सभी त्रुटियों को अनदेखा करना खतरनाक लगता है, अगर कोई और समस्या थी तो क्या होगा?

इसलिए मैं निम्नलिखित वर्कअराउंड का सुझाव दूंगा: भविष्य में सिस्टम डेट को कुछ समय के लिए सेट करने के लिए बूट स्क्रिप्ट में बदलाव करें (जैसे कि 3238-बिट मशीन पर 2038-01-18) फस्क चलाने से ठीक पहले, और इसे हार्डवेयर से वापस पढ़ें घड़ी बाद में ( hwclock --hctosysऔर अधिक विकल्पों के साथ, आपके हार्डवेयर के आधार पर और हार्डवेयर घड़ी में GMT के उपयोग के आधार पर।)

Comments

क्या इसका मतलब यह नहीं होगा कि अगली बार एक खिड़की होगी जिसमें हम उसी बग को फिर से मार सकें? यानी अंतिम माउंट समय 2038-01-18 है, इसलिए यदि वर्तमान समय भी उसी पर सेट है, तो एक दौड़ की स्थिति है जिसमें हम (जहां तक ​​सिस्टम का संबंध है) अंतिम माउंट से पहले माउंट करने की कोशिश कर रहे हैं।

— me_and

@me_and: हाँ, मुझे डर है कि मेरा कीचड़ दुर्भावनापूर्ण उपयोगकर्ताओं के खिलाफ मदद नहीं करेगा। अगर आप के खिलाफ हो, पैचिंग fsck सबसे अच्छा विकल्प है।

— गिल्स एसओ- बुराई को रोकें '

Answer 3

ऐसा लगता है कि इसे एक वर्चुअल मशीन में चलाया जाना चाहिए, जहां आप अधिक नियंत्रण रख सकते हैं (या सिर्फ स्नैपशॉट पर वापस लौट सकते हैं)।

Comments

VM में भागना वास्तव में हमारे लिए कोई विकल्प नहीं है, और किसी भी स्थिति में केवल स्नैपशॉट पर निर्भर रहने का मतलब है कि हम उपयोगकर्ता द्वारा स्थापित किए गए अन्य सभी राज्य को हटा सकते हैं।

— मुझे_और

Answer 4

यहाँ एक समाधान है जो मेरे लिए बहुत काम आया:

/Etc/e2fsck.conf बनाएं:

[problems]

# Superblock last mount time is in the future (PR_0_FUTURE_SB_LAST_MOUNT).
0x000031 = {
preen_ok = true
preen_nomessage = true
}

# Superblock last write time is in the future (PR_0_FUTURE_SB_LAST_WRITE).
0x000032 = {
preen_ok = true
preen_nomessage = true
}

यहाँ इस तय पर अधिक:

http://stillstup.blogspot.com/2010/02/superblock-last-mount-time-is-in-future.html