गलती से नाम बदलने / usr करने के बाद, मैं इसे वापस कैसे बदलूँ?

Question

मैंने गलती से निर्देशिका का नाम बदला /usrमें /usr_bak।

मैं इसे वापस बदलना चाहता हूं, इसलिए मैं सिस्टम को कमांड को खोजने की अनुमति देने के लिए पथ /usr_bak/binको जोड़ता हूं ।$PATHsudo

लेकिन अब sudo mv /usr_bak /usrमुझे त्रुटि देता है:

sudo: error while loading shared libraries: libsudo_util.so.0: cannot open shared object file: No such file or directory

वहाँ नाम बदलने के लिए एक रास्ता है /usr_bakके रूप में /usrप्रणाली फिर से स्थापित करने के अलावा?

Comments

यह कौन सा ओएस है? मुझे आश्चर्य है कि sudoलाइब्रेरी चरण में भी कैसे मिला, यह आमतौर पर है /usr/bin/और कमांड-नहीं-पाया त्रुटि के साथ विफल होना चाहिए। इसके अलावा, क्या आपके पास रूट पासवर्ड सेट है?

— मुरु

@ मुरु यह उबंटू है। आप ठीक कह रहे हैं, मुझे इस बारे में not foundपहले ही त्रुटि हो गई थी इसलिए मैंने नए रास्ते /usr_bak/binको जोड़ दिया $PATHऔर अब मुझे अपनी पोस्ट में यह त्रुटि मिली ...

— यव्स

@ user1717828 यह जटिल है। मुझे उबंटू 17.04 पर, उबंटू 16.04 पर विकसित एक परियोजना को संकलित करना है। इसलिए मैं सोच रहा हूं कि क्या मैं /usrउबंटू 16.04 की कॉपी कर सकता हूं ताकि /usrउबंटू को 17.10 से अधिलेखित कर सकूं ...

— यव्स

क्या आपने इस तरह के कठोर परिवर्तनों के बजाय परियोजना को संकलित करने के लिए एक वीएम का उपयोग करने पर विचार किया है?

— केविन

आप वर्चुअलबॉक्स को हेडलेस मोड में चला सकते हैं । किसी अन्य मशीन पर अतिथि को स्थापित करना, या पहले से कॉन्फ़िगर किया गया सबसे आसान हो सकता है।

— केविन

Answer 1

चूंकि आपने उबंटू में डिफ़ॉल्ट रूप से रूट, उपयोग suऔर busybox, के लिए एक पासवर्ड सेट किया है। सभी suआवश्यक पुस्तकालय में हैं /lib। बिजीबॉक्स उपयोगिताओं का एक संग्रह है जो सांख्यिकीय रूप से जुड़ा हुआ है, इसलिए लापता पुस्तकालयों को समस्या नहीं होनी चाहिए। करना:

su -c '/bin/busybox mv /usr_bak /usr'

(जबकि बिजीबॉक्स में भी एक suएप्लेट होता है, /bin/busyboxबाइनरी सेटुइड नहीं होता है और इसलिए जब तक रूट के रूप में नहीं चलाया जाता है) काम नहीं करता है।

यदि आपके पास रूट पासवर्ड नहीं है, तो आप शायद यहां गिल्स के समाधान का उपयोग कर सकते हैंLD_LIBRARY_PATH , या (गाइल्स कहते हैं कि यह सेटो बायनेरिज़ जैसे सुडो के साथ काम नहीं करेगा) रिबूट को बूट करें init=/bin/busyboxऔर कर्नेल पैरामीटर के साथ बूट करने के लिए GRUB मेनू को संपादित करें और ले जाएं फ़ोल्डर वापस।

Comments

अब, गलती से नाम न बदलें /lib।

— स्लीपब्लैंक

LD_LIBRARY_PATHके बाद से sudo चलाने के लिए मदद नहीं करेगा sudo। यदि इसकी लाइब्रेरी सही जगह पर नहीं हैं, तो sudo तब तक काम नहीं करेगा जब तक रूट इसकी मरम्मत नहीं करता।

— गाइल्स

@Yves ऐतिहासिक नोट: यूनिक्स के पुराने स्वाद (जो कि लिनक्स से बहुत पुराने हैं) में /sbinउस तरह के परिदृश्य के लिए सांख्यिकीय रूप से जुड़े बायनेरिज़ का एक छोटा संग्रह शामिल था : "मैं कुछ गतिविधि कर रहा हूँ जहाँ रनटाइम लाइब्रेरीज़ को चारों ओर से घेर लिया जाएगा लेकिन अभी भी फ़ाइलों में हेरफेर करने की आवश्यकता है। " मूल रूप से बिजीबॉक्स का आविष्कार करने से पहले एक ही दृष्टिकोण था। (इस फैशन में उपलब्ध आदेशों की संख्या बहुत सीमित थी, क्योंकि वे सांख्यिकीय रूप से जुड़े हुए बायनेरिज़

— अपस्कर्ट थे

@ यदि आप का नाम बदला गया है /lib, तो आपको संभवतः init=/bin/busybox

— मुरु

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

— पीटर कॉर्ड्स

Answer 2

मुरू के जवाब के अलावा :

• आप अपने सिस्टम को सुधारने के लिए कुछ बचाव बूट USB कुंजी का उपयोग कर सकते हैं; जैसे अगर आपके सिस्टम कुछ डेबियन या Ubuntu है, बचाव मोड में स्थापना यूएसबी कुंजी बूट, और उचित कर mountऔर mvऔर umount।

• इस तरह की गलतियों को और अधिक आसानी से ठीक करने में सक्षम होने के लिए, मैं आम तौर पर कई अंतर्निहित कमांडों के साथ एक स्थिर शेल स्थापित करता हूं (विशेष रूप से कुछ cp, rmऔर इसी mvतरह के बिलिन के साथ) जैसे कि sash(यह डेबियन और उबंटू में पैक किया गया है, और सैश-3.8 के रूप में भी उपलब्ध है । tar.gz इन सोर्स फॉर्म) और बूट विथ init=/bin/sashग्रब।

^{पुनश्च: sashथोड़ा छोटी गाड़ी है, और पूरी तरह से पॉज़िक्स आज्ञाकारी नहीं है, लेकिन फिर भी बहुत उपयोगी है।}

Comments

क्या आप यह समझा सकते हैं कि कई अंतर्निहित कमांड के साथ एक स्थिर शेल कैसे स्थापित किया जाए? क्या कुछ मैनुअल है?

— यव्स

डेबियन या उबंटू पर apt-get install sash:। लेकिन आप sash-3.8.tar.gz को भी डाउनलोड कर सकते हैं और उसे संकलित कर सकते हैं।

— बेसिल स्टारीनेविच

मैं इस तरह की समस्याओं के लिए एक कस्टम ग्रब प्रविष्टि के साथ hdd पर एक liveiso रखता हूं। जटिल होने की आवश्यकता नहीं है, बस एक लाइव ओएस बूट करें और फ़ाइलों को स्वतंत्र रूप से हेरफेर करें :)

— FreeSoftwareServers

Answer 3

मुझे लगता है कि सबसे सुरक्षित तरीका यूएसबी, सीडी या डीवीडी बूटेड ओएस (डेबियन, उबंटू, स्यूस, आदि) का उपयोग करके रिबूट करना है। फिर ड्राइव युक्त समस्याओं को माउंट करें और नाम बदलें।

सुरक्षित रूप से लापता / usr / / lib के साथ एक माइनफील्ड में बूट करने की तुलना में सुरक्षित।

Comments

आप Grub / HDD से सीधे ISO की बूट कर सकते हैं USB / DVD आदि की कोई आवश्यकता नहीं है। सुंदर निफ्टी ट्रिक ग्रब में कॉल लूपबैक है।

— FreeSoftwareServers

Answer 4

मैं एक ऐसी ही समस्या है जहाँ मैं नाम बदलकर में भाग /usr/binकरने के लिए /usr/bin_bkp(के रूप में आदेश नहीं मिला कुछ परीक्षण के लिए और फिर मैं नाम बदलने के लिए सक्षम नहीं था sudoमानक निर्देशिका है जिसमें /usr/bin) और फिर मैं के लिए गया था /usr/bin_bkpनिर्देशिका मैन्युअल रूप से (फ़ाइल प्रबंधक का प्रयोग ) और राइट क्लिक पर अधिकांश फ़ंक्शन (नाम बदलने सहित) अक्षम हैं।

फिर मैंने निम्नलिखित कमांड की कोशिश की और इसने इस मुद्दे को ठीक कर दिया

$/usr/bin_bkp/sudo mv /usr/bin_bkp/ /usr/bin/

मैंने वर्तमान मार्ग से सूडो का आह्वान किया और यह काम कर गया, अब सब कुछ सामान्य हो गया है।

OS: Xubuntu 14.04

Answer 5

मैं अभी यह कोशिश नहीं कर सकता (और मुझे यकीन नहीं है कि मैं चाहता हूं), लेकिन ऐसा लगता है कि यह अपने आप को एक नया "/ usr" बनाने के लिए एक कड़ी के रूप में काम करना चाहिए (न कि एक नरम लिंक) आपके लिए " / usr_bak, फिर "usr_bak" हटाएं

ln /usr_bak /usr
rm /usr_bak

फ़ाइल सिस्टम में "ln" ( बिना "-s" तर्क के) द्वारा बनाई गई हार्ड लिंक दोनों usr और usr_bak निर्देशिकाओं को समान रूप से प्रश्न में निर्देशिकाओं के लिए समान रूप से मान्य लिंक बनाना चाहिए। "rm" सिर्फ एक लिंक को हटाता है जिसे आपने इसे हटाने के लिए कहा था, न कि दोनों को। चूंकि सामग्री के लिए अभी भी एक वैध लिंक है, उन्हें "/ usr" शेष लिंक के माध्यम से सुलभ रहना चाहिए।

Comments

मैं इस धारणा के तहत था कि लिनक्स (या कम से कम उबंटू) निर्देशिकाओं के लिए कठिन लिंक की अनुमति नहीं देता है। उदाहरण के लिए, askubuntu.com/questions/210741/…

— क्रिस बूचार्ड

@ क्रिस: ठीक है, लिनक्स निर्देशिका हार्डलिंक (के अलावा .और अनुमति नहीं देता है .., इसलिए एक निर्देशिका पर लिंक गिनती आपको प्रथम-स्तरीय उप-संख्या की संख्या बताती है)। इसके अलावा, rmनिर्देशिकाओं पर काम नहीं करता है, आपको उपयोग करना होगा rmdir। ( lnऔर rmनिर्देशिकाओं पर सहानुभूति पर काम करते हैं, लेकिन हम एक वास्तविक निर्देशिका के बारे में बात कर रहे हैं)। इसके अलावा, इस समस्या का समाधान नहीं होता है, क्योंकि यह की आवश्यकता है rootजैसे mvक्योंकि पर अनुमतियों की,/ । यदि आप इसे चला सकते हैं, तो आप mvएक सामान्य व्यक्ति की तरह भाग सकते हैं ।

— पीटर कॉर्ड्स

हार्डलिंक्स से लेकर डाइरेक्टरी तक सभी पर समर्थित नहीं हैं (सभी?) यूनीक क्योंकि सॉफ्टवेयर के लिए यह बहुत मुश्किल है कि अनन्त लूप्स का पता लगाने के लिए एक रिकर्सिव फाइल सिस्टम क्रॉल करें। यह संभव है अगर सॉफ़्टवेयर देखे गए सभी इनोड्स का ट्रैक रखता है और यह एक इनकोड जागरूक फाइल सिस्टम (यानी FAT32 / NTFS) को क्रॉल कर रहा है, लेकिन प्रतीकात्मक लिंक के लिए जाँच करना और उन्हें ट्रैवर्स करना आसान नहीं है। फ़ाइल प्रकार की जाँच करने के लिए lstat (2) के लिए एक त्वरित कॉल की आवश्यकता है।

— पेंग्विन 359

@Pryftan, मेरी ln(1)डेबियन पर यह -d/ -F/ --directoryविकल्प के लिए कहता है: " सुपरयुजर को कड़ी लिंक निर्देशिकाओं पर प्रयास करने की अनुमति दें (ध्यान दें: सिस्टम प्रतिबंधों के कारण संभवतः विफल हो जाएगा, यहां तक ​​कि सुपरयूज़र के लिए भी") । तो आप कोशिश करने के लिए स्वतंत्र हैं, लेकिन आपका फाइल सिस्टम शायद आपको ऐसा नहीं करने देगा।

— टोबे स्पाइट

@TobySpeight एक और विचार: सिमिलिंक (7) भी देखें जो कहता है: हार्ड लिंक निर्देशिकाओं (फाइलसिस्टम ट्री के भीतर लूप की संभावना को रोकने के लिए, जो कई कार्यक्रमों को भ्रमित नहीं करेगा) को संदर्भित नहीं कर सकते हैं और विभिन्न कंप्यूटर सिस्टम पर फ़ाइलों का उल्लेख नहीं कर सकते हैं (क्योंकि फाइल सिस्टम के अंदर इनोड संख्या अद्वितीय नहीं है)। इससे मुझे लगता है कि हार्ड लिंक का प्रयास वास्तव में कुछ और घटित करने का तरीका हो सकता है जो कि होता है अर्थात् फ़ंक्शन को कहा जाता है, लेकिन यह बिल्कुल विफल रहता है क्योंकि यह एक निर्देशिका है। (फाइलसिस्टम संदर्भ वह है जो मैं एक अन्य टिप्पणी में सोच रहा था)

— प्रिफैटन