रिबूट पर बल fsck.ext4, लेकिन वास्तव में "जबरदस्ती"

Question

मेरे Ubuntu 10.04 सर्वरों में से एक मुझे परेशान कर रहा है। जब मैं fsck.ext4 -n /dev/sda5इसे चलाता हूं तो मुझे बताता है कि फ्री इनोड काउंट, फ्री ब्लॉक काउंट और बहुत कुछ में त्रुटियां हैं।

मैंने कोशिश की है:

touch /forcefsck

यह भी आज़माया:

shutdown -rF now

और फिर भी, रिबूट के बाद, मुझे त्रुटियाँ दिखाई देती हैं।

मैं भी बस अपने eeePC netbook, Ubuntu 10.10 पर जाँच की, और एक ही मुद्दा है!

मैं रिबूट के लिए वास्तव में "मजबूर" "जबरदस्ती" "अपने फाइल सिस्टम को" / "" फाइलसिस्टम के fsck को कैसे ठीक कर सकता हूं?

स्पष्टता: मैं चलाता हूं fsck.ext4 -nक्योंकि यह एक माउंटेड फाइल सिस्टम है, यह जांचने के लिए कि क्या त्रुटियां हैं। यह मुझे बताता है कि वहाँ हैं। मैंने सोचा था कि बूट-अप प्रक्रिया के दौरान हर 30 m ऑटोमैटिक रूट फाइल सिस्टम में त्रुटियों का ध्यान रखने के लिए ठीक है। लेकिन यह मेरे मामले में ऐसा नहीं करता है। मैं एक LiveCD के साथ रिबूट कर सकता हूं और त्रुटियों को ठीक कर सकता हूं, और फिर दोबारा रिबूट कर सकता हूं, लेकिन यह लाइव सर्वर के लिए कुछ गंभीर डाउनटाइम है। एक रिबूट, ऑटो fsck, फिर जारी रखना बूटिंग एक लाइव सर्वर पर बहुत अधिक टिकाऊ है, और मेरा मानना ​​है कि सही व्यवहार होना चाहिए।

अतिरिक्त जानकारी: यहाँ आउटपुट है। यह कुछ ऐसा दिखता है कि ऑटोफोक ठीक होगा, है ना?

root@server:~# fsck.ext4 -n /dev/sda5
e2fsck 1.41.11 (14-Mar-2010)
Warning!  /dev/sda5 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
/dev/sda5 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong (1849368, counted=1948909).
Fix? no

Free inodes count wrong (545504, counted=552134).
Fix? no


/dev/sda5: ********** WARNING: Filesystem still has errors **********

/dev/sda5: 116752/662256 files (0.2% non-contiguous), 795324/2644692 blocks

Comments

उबंटू सर्वर संस्करण क्या आप उपयोग कर रहे हैं?

— 15

10.04। मैं अपने प्रश्न का संपादन करूंगा।

— उरोकमोहन

मुझे नहीं लगता कि आप वास्तव में ऐसा कर सकते हैं, वास्तव में आप मैन्युअल रूप से चेक करने से बेहतर हो सकते हैं।

— RolandiXor

क्षमा करें, लेकिन मुझे अभी भी अधिक जानकारी की आवश्यकता है। क्या आप आरोहित फाइलसिस्टम पर fsck कर रहे हैं? क्या आप LiveCD से बूट कर सकते हैं और फिर से जांच सकते हैं (आपके / dev / sda5 के साथ अनमाउंट)?

— 15

क्या यह संभव नहीं है कि फाइल सिस्टम नहीं बल्कि हार्ड ड्राइव टूटे? किस मामले में यह उम्मीद की जाएगी कि ext4 त्रुटियों को ठीक नहीं कर रहा है और साथ ही यह कुछ खराब क्षेत्रों में भी होगा।

— Stefano Palazzo

Answer 1

E2fsck मैन पेज से:

"ध्यान दें कि सामान्य रूप से माउंटेड फाइल सिस्टम पर e2fsck चलाना सुरक्षित नहीं है। केवल एक अपवाद है अगर -n विकल्प निर्दिष्ट किया गया है, और -c, -l या -L विकल्प निर्दिष्ट नहीं हैं। हालांकि, भले ही यह सुरक्षित हो। ऐसा करने के लिए, e2fsck द्वारा मुद्रित परिणाम मान्य नहीं हैं यदि फाइलसिस्टम आरोहित है। यदि e2fsck पूछता है कि क्या आपको एक फाइलसिस्टम की जाँच करनी चाहिए जो आरोहित है, केवल सही उत्तर '' नहीं '' है। केवल विशेषज्ञ जो वास्तव में हैं। वे किसी भी अन्य तरीके से इस सवाल का जवाब देने पर विचार कर रहे हैं। "

तो अगर आप fsck के साथ माउंटेड FS की जांच करते हैं, तो भी n विकल्प का उपयोग करके परिणाम बिल्कुल भी मान्य नहीं हो सकता है। माउंटेड फाइल सिस्टम की जाँच न करें। एक लाइव-सीडी / लाइव-यूएसबी का उपयोग करें।

यदि आप माउंट होने के दौरान फाइल सिस्टम की जांच नहीं करते हैं, तो मुझे समझ में नहीं आता है कि आपको इसका उपयोग करने की आवश्यकता क्यों है, आप touch /forcefsckइसे अनमाउंट कर सकते हैं और इसे ठीक कर सकते हैं। लेकिन अगर यह मामला है और एक तय के बाद भी आपके एफएस में त्रुटियां हैं तो आप उपयोग करने पर विचार कर सकते हैं:

e2fsck -cy /dev/sda5

हार्ड ड्राइव से संबंधित समस्या को ठीक करेगा जिसे खराब ब्लॉक कहा जाता है (यह एक लंबा समय लगेगा)।

यदि आप एक माउंटेड फ़ाइल सिस्टम की जांच करना चाहते हैं, तो मुझे नहीं पता कि कैसे आगे बढ़ना है, लेकिन मुझे लगता है कि आपको एक और प्रश्न बनाना चाहिए।

Comments

आप सही हैं, फाइलसिस्टम आरोहित है। और निश्चित रूप से मुझे अनमाउंट होने पर fsck करने की आवश्यकता है। लेकिन मैं चेंज-एन चलाते हुए जाँच करता हूं कि माउंट किए बिना, बदलाव किए बिना, और यह बताता है कि त्रुटियां हैं। और रिबूट पर fsck उन्हें ठीक नहीं करना चाहिए ???

— उरूकॉम

मैंने अभी देखा कि आप पहले वाक्य में क्या कहते हैं: fsck -n एक माउंटेड फाइल सिस्टम पर मान्य क्यों नहीं होगा? अगर एक घुड़सवार फाइल सिस्टम में विश्वसनीय तरीके से त्रुटियां हैं तो मैं कैसे जांच सकता हूं?

— उरकोम

आप e2fsck मैन पेज की जाँच कर सकते हैं जो कहता है: "ध्यान दें कि सामान्य रूप से माउंटेड फाइल सिस्टम पर e2fsck चलाना सुरक्षित नहीं है। केवल एक विकल्प निर्दिष्ट किया जाता है, यदि -n विकल्प निर्दिष्ट किया जाता है, और -c, -l, या -L विकल्प। निर्दिष्ट नहीं है। हालाँकि, भले ही ऐसा करना सुरक्षित है, फिर भी e2fsck द्वारा मुद्रित परिणाम मान्य नहीं हैं यदि फाइल सिस्टम को आरोहित किया गया है। यदि e2fsck पूछता है कि क्या आपको एक फाइलसिस्टम की जाँच करनी चाहिए जो आरोहित है, एकमात्र सही उत्तर है '' कोई '' नहीं। केवल विशेषज्ञ जो वास्तव में जानते हैं कि वे क्या कर रहे हैं, इस प्रश्न का उत्तर किसी अन्य तरीके से देना चाहिए। "

— Nyamiou द गैलेनथ्रोपे

मुझे नहीं पता कि माउंटेड फ़ाइल सिस्टम की जाँच कैसे करें शायद आपको एक और प्रश्न बनाना चाहिए।

— Nyamiou द गैलेनथ्रोपे

क्या आप अपने उत्तर में उन दो अंतिम टिप्पणियों को जोड़ सकते हैं? तब मैं इसे स्वीकार करूंगा। मुझे नहीं पता था कि, इसीलिए ... मुझे लगता है कि यह इसलिए है क्योंकि fsck -n जर्नल को प्रोसेस नहीं करता है, इसलिए फाइलसिस्टम स्थिति वहां रखे नवीनतम परिवर्तनों को देखे बिना असंगत है।

— ०

Answer 2

मुझे पता है कि यह वास्तव में एक पुराना धागा है, लेकिन मुझे हाल ही में इस समस्या को हल करना था इसलिए मैं पोस्ट करना चाहता था कि बूटअप के दौरान ओएस के साथ पाई गई समस्याओं को ठीक करने के लिए ओएस को कैसे मजबूर किया जाए (12.04 के लिए)।

आपको कमांड चलाने की आवश्यकता है sudo touch /forcefsck। यह अगले बूट पर एक fsck प्रदर्शन करने का कारण होगा। आप fvar के परिणाम को /var/log/boot.log में देख सकते हैं।

हालाँकि, आपको इस बात की गारंटी नहीं है कि fsck कुछ भी ठीक कर देगा। ऐसा करने के लिए, आपको फ़ाइल / etc / default / rcS को संपादित करना होगा। उस फ़ाइल के अंत में एक पंक्ति है:

FSCKFIX=no

इसे निम्न में बदलना होगा:

FSCKFIX=yes

यह -y विकल्प के साथ fsck को चलाने के समान प्रभाव पड़ेगा जो उन सभी फ़िक्सेस को लागू करेगा जो लागू होना संभव है और यह उपयोगकर्ता इंटरैक्शन के लिए नहीं पूछेगा।

यह आपको fsck को चलाने की अनुमति देगा, जैसे कि ओपी बिना किसी लाइव डिस्क से बूटिंग का सहारा लिए बिना पूछ रहा था जो कि विशेष रूप से तब संभव नहीं होता जब आप रिमोट सिस्टम पर होते हैं।

Comments

मेरे उबंटू EC2 उदाहरण पर sudo touch /forcefsckऔर sudo shutdown -rकमांड के साथ इस प्रविष्टि को संपादित करने से फ़ाइल सिस्टम समस्याओं और लॉगिन पर चेक चेतावनी को सफलतापूर्वक हल किया गया। आसान और गैर-विघटनकारी - चियर्स।

— c.gutierrez

सर्वर फॉल्ट पर भी यही सवाल पूछा गया था, और यह जवाब भी एक था जो मेरे लिए काम करता था, उबंटू 14.04 सिस्टम पर। बस कर sudo touch /forcefsckऔर फिर रिबूटिंग नहीं किया; संपादन rcSआवश्यक था।

— तैमू लीस्ती

Answer 3

sudo touch /forcefsck
sudo reboot

आपको एक टाइपो मिला है- आप स्पर्श कर रहे हैं / forcefcsk। "C" और "s" की अदला-बदली होती है। FileSystemChecK के लिए fsck कम है।

Comments

यह मेरे लिए काम नहीं करेगा क्योंकि रूट फाइलसिस्टम को केवल मेरे द्वारा ठीक करने की त्रुटियों के कारण पढ़ा जाता है fsck! चिकन और अंडे की समस्या जिसे केवल liveCD के माध्यम से हल किया जा सकता है या ड्राइव को दूसरी मशीन में खींच सकता है।

— एचडीवी

Answer 4

आप एक fsck को बल नहीं दे सकते / जो मरम्मत करेगा क्योंकि विभाजन उपयोग में है। एक अलग विभाजन या लाइव सीडी से चेक चलाने का प्रयास करें।

Comments

बहुत सही है, लेकिन विभाजन के उपयोग से पहले बूट पर स्वचालित fsck होना चाहिए, ठीक "/" पर त्रुटियों को ठीक करने में सक्षम होने के लिए। नहीं तो बात क्या है?

— उरकोम

मेरा मानना ​​है कि चेक उपयोग से पहले होता है, हालांकि, यह एक सलाहकार की जांच से अधिक है। यह आपको तय करना है कि त्रुटियों को कैसे ठीक किया जाए। एक आसान जाँच है जब / etc / fstab देख रहा है। "/" को एक अलग चेक मिलता है फिर अन्य विभाजन।

— चार्ली-ताका

यह रूट पिवोट होने से पहले होता है? अर्थात। INITIAL राम डिस्क।

— मैकेंज़्म

Answer 5

आपके पास निम्न तरीके से किए गए संशोधन हो सकते हैं:

Tune2fs -c 5 -i 10 / dev / sda1

-cदौड़ने से पहले माउंट की अधिकतम संख्या है fsckऔर दौड़ने से पहले -iकी अधिकतम संख्या है fsck।

इस मामले में हर 5 दिनों या हर 10 दिनों में, जो भी पहले हो, किया जाएगा।

मेरे पास दो कंप्यूटर हैं, एक लिनक्स SuSE 13.2 के साथ और दूसरा लिनक्स मिंट 18.0 के साथ और दोनों में यह पूरी तरह से काम करता है।

Comments

स्वचालित रूप में फ़ॉर्म और टिप्पणियां इस प्रकार हैं: Tune2fs -c 5 -i 10 / dev / sda1 जहाँ: -c fsck चलाने से पहले mounts की अधिकतम संख्या है: -i fsck से पहले अधिकतम दिनों की संख्या है इस मामले में हर 5 दिनों या हर 10 दिनों में, जो भी पहले हो, किया जाएगा। मेरे पास दो कंप्यूटर हैं, एक लिनक्स SuSE 13.2 के साथ और दूसरा लिनक्स MInt 18.0 के साथ और दोनों पूरी तरह से काम करते हैं।

— hk3jld

स्वचालित रूप में फ़ॉर्म और टिप्पणियां इस प्रकार हैं: Tune2fs -c 5 -i 10 / dev / sda1 जहाँ: -c fsck चलाने से पहले mounts की अधिकतम संख्या है: -i fsck से पहले अधिकतम दिनों की संख्या है इस मामले में हर 5 दिनों या हर 10 दिनों में, जो भी पहले हो, किया जाएगा। मेरे पास दो कंप्यूटर हैं, एक लिनक्स SuSE 13.2 के साथ और दूसरा लिनक्स MInt 18.0 के साथ और दोनों पूरी तरह से काम करते हैं। मुझे अंग्रेजी नहीं

— आती है

क्या यह उबंटू पर भी काम करता है?

— जॉर्ज उदेन

Answer 6

touch /forcefsckअकेले यह सुनिश्चित नहीं करता कि मेरा सिस्टम fsckअगले बूट पर चले । मुझे भी दौड़ने की जरूरत थी:

sudo tune2fs -c 1 /dev/<my partition>

जैसे

sudo tune2fs -c 1 /dev/sda1

अधिक स्पष्टीकरण मैंने पाया है: रिबूट के बाद फाइलसिस्टम की जांच करने के लिए फोर्स फोक्स कैसे करें