टैब रीडिंग और टर्मिनल विंडो को बेतरतीब ढंग से बंद करके 'केवल-पढ़ने के लिए फ़ाइल सिस्टम' त्रुटि


28

पहले केवल कमांड के साथ एक विषमता है cd। यदि मैं टाइप करता हूं cd, तो एक स्थान, फिर Tabउपलब्ध निर्देशिकाओं को देखने के लिए दबाएं , मुझे यह त्रुटि संदेश मिलता है:

bash: यहाँ-दस्तावेज़ के लिए अस्थायी फ़ाइल नहीं बना सकते: केवल-पढ़ने के लिए फ़ाइल सिस्टम

अधिक परेशानी वाला मुद्दा टर्मिनल विंडो का यादृच्छिक समापन है। यह cdविषमता का परीक्षण करते हुए हुआ है , git statusऔर इस तरह और इस तरह की सरल चीजों को करने वाले किसी अन्य सर्वर में ssh'd है । [संपादित करें] ऐसा लगता है कि अगर मैं 31 बार दर्ज करता हूं तो यह टर्मिनल विंडो के ऑटो समापन (अब 3 बार सत्यापित) को ट्रिगर करता है।

मैंने हाल ही में पिछले सप्ताह 12.04 से 14.04 तक अपग्रेड किया था, और यह व्यवहार पूरे दिन नहीं हुआ था जिसे मैंने अपग्रेड करने के बाद उपयोग किया था। उस दिन के बाद से इस कंप्यूटर पर कुछ भी करने का यह पहला प्रयास है।

कृपया कोई अन्य जानकारी जो मैं प्रदान कर सकता हूं, सलाह दें और इसे हल करने के लिए मुझे क्या करना होगा।


प्रश्न शीर्षक को अधिक वर्णनात्मक बनाने के लिए बस एक अनुकूल अनुस्मारक, जो बेहतर प्रतिक्रिया प्राप्त करने में मदद करता है: "विषम टर्मिनल व्यवहार" बहुत वर्णनात्मक नहीं है।
thomasrutter

मैं इसकी सराहना करता हूं।
ताकामफिन

अपनी समस्या का बेहतर निदान करने के लिए, क्या आप मुझे बता सकते हैं कि क्या आप उस डिफ़ॉल्ट विभाजन का उपयोग कर रहे हैं जिसे उबंटू ने स्थापित किया है, क्या आप संपूर्ण डिस्क एन्क्रिप्शन या LVM का उपयोग कर रहे हैं, और क्या आपने अपने fstab के लिए कुछ भी किया है? mountकमांड का आउटपुट क्या है ?
थोमसट्रेटर

माउंट आउटपुट: gist.github.com/anonymous/74dc62ccd5602d1e9742
Takamuffin

यह प्रदान करने के लिए धन्यवाद - ऐसा लगता है कि माउंट के समय में जिस तरह से माउंट कॉन्फ़िगर किए गए हैं और कोई समस्या नहीं है, लेकिन तब से / (रूट) माउंट के साथ त्रुटियों के साथ कोई समस्या नहीं है? remount-roनिर्दिष्ट करता है कि जड़ विभाजन रीड-ओनली कुछ फाइल सिस्टम त्रुटियों की स्थिति में के रूप में remounted किया जाएगा। रिकवरी या लाइव सीडी से फेक करना अच्छा होगा।
thomasrutter

जवाबों:


16

मैंने रिकवरी मोड में रिबूट किया और निर्देशों का पालन किया जो सिस्टम ने मुझे दिया था। मैं भाग fsckगया /dev/sda2, और इस समस्या को ठीक कर दिया।


13

Read-only file systemत्रुटि प्रमुख सुराग यहाँ है। मुझे लगता है कि आपके घर की निर्देशिका, जहां bash आपके कमांड इतिहास और इसके आगे के स्टोर को स्टोर करने की कोशिश करता है, एक रीड-ओनली पार्टीशन के अंदर है।

मुझे लगता है कि यह हर 32 कमांड पर एक बार डिस्क पर आपके हाल के कमांड इतिहास को अपडेट करने की कोशिश करता है, यही कारण है कि यह आपके द्वारा एक सत्र में 32 वें कमांड पर टाइप करने में विफल हो रहा है।

अब, एक विभाजन को केवल पढ़ने के रूप में माउंट किया जा सकता है, यदि आप इसे जानबूझकर करते हैं, लेकिन इसे केवल पढ़ने के लिए भी माउंट किया जा सकता है, अगर कोई त्रुटि थी - यह बाद वाला व्यवहार आमतौर पर रूट विभाजन के लिए डिफ़ॉल्ट है।

यदि आपका रूट विभाजन केवल रीड-माउंटेड है, तो आपको आश्चर्य होगा कि आप अन्य समस्याओं का सामना नहीं कर रहे हैं।

आप पुनर्प्राप्ति मेनू से पुनर्प्राप्ति और डिस्क की जांच करने का प्रयास कर सकते हैं। कंप्यूटर के बूट के रूप में प्रेस और होल्ड को शिफ्ट करें, दाईं ओर BIOS स्क्रीन गायब होने के बाद और उबंटू लोगो दिखाई देने से ठीक पहले।


1
वही समस्या थी। रीबूटिंग का काम किया। धन्यवाद।
श्वेतहाट

4

यह सटीक मुद्दा मेरे लिए भी हुआ।

यह रुक-रुक कर होता है।

तो मैं अंत में इसके साथ पर्याप्त था और ओएस को पुनर्स्थापित करने का फैसला किया - ubuntu-gnome 14.04 (साफ)।

यह तय हो गया! कम से कम कुछ दिनों के लिए .. फिर वही समस्या फिर से आ गई ...

इसलिए मैं फ्राई के पास गया और एक नया hdd (सीगेट) प्राप्त किया।

अब तक अच्छा (6 महीने और गिनती)।

साइड नोट: स्टॉक hdd तोशिबा था


उबंटू पूछने के लिए आपका स्वागत है। चूंकि यह प्रश्न का उचित उत्तर नहीं है, इसलिए कृपया इसे हटा दें।
आर्किसमैन पाणिग्रही

2
यही मेरा उत्तर है। आपका क्या उत्तर है?
phtn458

2
मैं जो कहना चाहता था वह यह है कि ओएस को फिर से स्थापित करना या एक नई हार्ड डिस्क खरीदना एक उचित समाधान नहीं है। आप अन्य पोस्ट पर टिप्पणी करना चाह सकते हैं और जब आप पर्याप्त प्रतिष्ठा (15) लेंगे तो आप टिप्पणी कर पाएंगे।
अर्चिसमैन पाणिग्रही

10
@ArchismanPanigrahi "डिस्क खराब है, एक नया प्राप्त करें" एक उत्तर है।
सेठ

1
वाह। तो उन सभी उत्तोलन ने उत्तर दिया और नए hdd (?)
पवन

2

जैसा कि दूसरों ने बताया है, केवल-पढ़ने के लिए एक /tmpफ़ाइल सिस्टम आगे की समस्याओं का कारण बनता है।

31 लाइनों के लिए, यह gnome-terminalआंतरिक से संबंधित है ।

यह एक तथाकथित "रिंग" में, स्मृति में कुछ निश्चित रेखाएं रखता है। बाकी, जो लाइनें इस रिंग से बाहर स्क्रॉल करती हैं, उन्हें "स्ट्रीम" में रखा जाता है। सूक्ति-टर्मिनल के पुराने संस्करणों में स्ट्रीम बहुत सीधे सीधे एक फ़ाइल के तहत लिखी गई थी /tmp, नए संस्करणों में बफ़रिंग, संपीड़न और एन्क्रिप्शन से पहले इसे लिखा जाता है। (मैं अपने सिर के ऊपर से याद नहीं रख सकता कि क्या फ़ाइल के तहत फ़ाइल /tmpतब खोली जाती है जब डेटा का पहला हिस्सा स्ट्रीम में लिखा जाता है, या जब स्ट्रीम पहली बार वास्तव में लिखने की कोशिश करता है /tmp, तो यह एक मामूली कार्यान्वयन विवरण है।)

रिंग का आकार हमेशा दो की शक्ति होता है (प्रत्येक स्लॉट में टर्मिनल की 1 लाइन होती है; 1 स्लॉट को छोड़कर तकनीकी कारणों से इसका उपयोग नहीं किया जाता है), और टर्मिनल की ऊंचाई बढ़ने के कारण हर बार इसे दोगुना किया जाता है ( लेकिन कभी पीछे नहीं हटता)। जैसे, 24 लाइनों की डिफ़ॉल्ट ऊंचाई के साथ रिंग में आउटपुट की अंतिम 31 लाइनें होती हैं, बाकी धारा (अंततः /tmp) स्ट्रीम में जाती है । यदि आप विंडो की ऊँचाई को 40 रेखाएँ कहते हैं, तो इन-मेमोरी रिंग एक बार में अधिकतम 63 प्रविष्टियों को समायोजित करने के लिए बढ़ेगी।

आप जो अनुभव करते हैं वह यह है कि स्ट्रीम को स्टोर gnome-terminalकरने के लिए एक फ़ाइल खोलने की कोशिश करता है /tmp, और यहां अप्रत्याशित विफलता के कारण बाहर निकलता है। डिफ़ॉल्ट से अधिक लंबी विंडो के साथ प्रयास करें; दर्ज 63 (या शायद 127) बार दबाने के बाद यह दुर्घटनाग्रस्त हो जाएगा।

कहा जा रहा है, /tmp(1777 अनुमतियों के साथ) लिखने योग्य होना चाहिए।


1

मेरी समस्या यह थी कि एक प्रक्रिया 100% सीपीयू के साथ चल रही थी और शायद सभी डिस्क संसाधनों (कुछ बैकअप प्रक्रिया: यूआर-बैकअप) ले ली।

एक बार मैंने इसे मार दिया, सब ठीक हो गया। इसलिए मुझे लगता है कि आईओ पर एक बोतल-गर्दन इस त्रुटि का कारण बन सकती है, भले ही पर्याप्त जगह हो और आपके पास लिखित अनुमति हो।

(जेस्सी 18/03/16 के साथ रास्पबेरी पाई)

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.