टीएल; डीआर यह जल्दी रिबूट करके तय किया जा सकता है । तब CD-ROM काम करेगा और अतिथि परिवर्धन स्थापित करने योग्य होगा:
sudo reboot
वर्चुअलबॉक्स के साथ कर्नेल को जोड़ने के लिए "सबसे अच्छा" क्रम है:
apt-get update
apt-get upgrade (or apt-get dist-upgrade)
reboot
(re)install VirtualBox Additions on the new kernel that is now running
apt-get autoremove
(अगले-से-नवीनतम पुराने कर्नेल को सुरक्षा कारणों से ऑटो-हटाया नहीं जा सकता है, जिससे आपको "वापस जाने" की अनुमति मिल सके)।
ये कैसे हुआ? (पिछले लंबे उत्तर)
यदि आप इस तरह की समस्या उत्पन्न करेंगे तो:
- कर्नेल को अपग्रेड करें (.66 से .67 तक कहें)
- चलाएं
apt-get autoremoveऔर किसी तरह चल रहे कर्नेल को हटा दें, या मैन्युअल रूप से "पुराने" कर्नेल को हटा दें, इस प्रकार /lib/modules/kernel.66 से सभी मॉड्यूल हटा दें
- रिबूट न करें, जिससे "पुराना" .66 कर्नेल चालू रहे। लोड किए गए मॉड्यूल मेमोरी में रहते हैं और सब कुछ काम करता है, लेकिन .66 मॉड्यूल हटाए जाने के बाद से कोई नया मॉड्यूल लोड नहीं किया जा सकता है।
- कुछ भी करने की कोशिश करें जिसके लिए एक मॉड्यूल लोड करने की आवश्यकता होती है जो अभी तक लोड नहीं किया गया था
और वर्चुअलबॉक्स आईएसओ स्थापित करने के लिए ठीक उसी की आवश्यकता हो सकती है - ISO9660 समर्थन मॉड्यूल लोड करना।
अनुरोधित मॉड्यूल अब ऑटोलॉइड नहीं हो सकता है, क्योंकि चल रहे कर्नेल (.66) /lib/modules/kernel.66 में कुछ भी नहीं मिलता है। मॉड्यूल मौजूद है , लेकिन यह /lib/modules/kernel.67 में है, जिनमें से वर्तमान .66 कर्नेल के बारे में कुछ भी नहीं जानता (और यह बेमेल मॉड्यूल लोड करने के लिए अनुशंसित नहीं है)।
अनाम कर्नेल को पुनर्स्थापित करने से निश्चित रूप से चल रहे कर्नेल मॉड्यूल को फिर से स्थापित किया जा सकेगा, जिससे ...6.6/.../isofs.ko फिर से उपलब्ध होगा और रिबूट अनावश्यक हो जाएगा। यह स्थापित कर्नेल का एक डाउनग्रेड है और अपडेट समस्या बनी रहेगी (नीचे देखें)।
है यही कारण है कि, जब आप परिवर्धन सीडी चलाने के लिए, इसके लिए स्थापित हो जाएगा चल 0.66 गिरी, नहीं अद्यतन .67 कर्नेल (जो अभी भी नहीं चल रहा है)।
यदि आप ऐसी स्थिति में हैं, तो आप निश्चित रूप से इसे रिबूट करके भी ठीक कर सकते हैं (नए .67 चलने वाले कर्नेल को इसके मॉड्यूल मिलेंगे), और संभवत: नए कर्नेल से संबंधित मॉड्यूल को लोड करके ( isofsजो बहुत स्थिर है), जब तक कि आप न हों एक महत्वपूर्ण कर्नेल उन्नयन अभी भी संगत होगा ( यह अभी भी अनुशंसित नहीं है! ):
# mount /dev/cdrom /mnt
mount: unknown filesystem type 'iso9660'
यह उपर्युक्त रूट त्रुटि है जो आपको मिल रही है ("अज्ञात फाइलसिस्टम प्रकार")।
# uname -a
Linux virtual 3.13.0-66-generic ...
इसलिए हम जांचते हैं कि मॉड्यूल का कौन सा संस्करण स्थापित है। यह होना चाहिए ।66:
# ls /lib/modules
3.13.0-67-generic
... लेकिन केवल एक निर्देशिका है और यह .67 (.66 निर्देशिका हो सकती है, लेकिन खाली है; इस मामले du -sh /lib/modules/*में बताएगा कि विभिन्न निर्देशिकाओं द्वारा कितनी जगह ली गई है, खाली लोगों और पूर्ण लोगों के बीच बताने की अनुमति है)।
पुरानी कर्नेल छवि को बिना री-ग्रब के पुनः स्थापित करने से वास्तविक समस्या ठीक नहीं होगी
आप अपने मॉड्यूल और हेडर के साथ .66 कर्नेल को पुनर्स्थापित करें। अब आपके पास दोनों गुठली हैं, grubनए सेट को लोड करने के लिए ।67।
ISO CD-ROM को माउंट किया जा सकता है (क्योंकि मॉड्यूल अब मौजूद है) और VBox मॉड्यूल संकलित करेगा (क्योंकि हेडर स्थापित किए गए हैं)।
यह चल रहे .66 कर्नेल के लिए मॉड्यूल संकलित करेगा, और वे काम करेंगे ... थोड़ी देर के लिए।
पहले रिबूट पर, आप अपने आप को .67 कर्नेल के साथ पाएंगे जिसमें कोई वर्चुअलबॉक्स जोड़ नहीं होगा।
पुरानी कर्नेल छवि को री-ग्रब और री-बूट के साथ फिर से इंस्टॉल करना भी वास्तविक समस्या को ठीक नहीं करेगा
ऊपर के रूप में, आप रिबूट करते हैं और खुद को एक डाउनग्रेड किए गए कर्नेल के साथ पाते हैं। बहुत जल्द, उबंटू इसे अपग्रेड करने की कोशिश करेगा और आप वापस आ जाएंगे जहां आपने शुरू किया था (नीचे देखें: "डाउनग्रेड कर्नेल")।
आईएसओ मॉड्यूल में पैचिंग भी वास्तविक समस्या को ठीक नहीं करेगी
संभावना है कि हम ISO9660 मॉड्यूल को समान रूप से लोड कर सकते हैं, क्योंकि गुठली 66 और 67 के बीच कोई काम नहीं किया गया था और बाइनरी अनिवार्य रूप से अपरिवर्तित है, इसलिए हम कोशिश करते हैं:
# insmod /lib/modules/3.13.0-67-generic/kernel/fs/isofs/isofs.ko
त्रुटियाँ नहीं। इसने काम कर दिया। कर्नेल .66 कर्नेल से लोड मॉड्यूल ।67। आइए फिर से कोशिश करें कि CD-ROM माउंट करें:
# mount /dev/cdrom /mnt
mount: block device /dev/sr0 is write-protected, mounting read-only
यह अभी भी मदद नहीं करेगा, क्योंकि सीडी स्थापित किया जा रहा है वर्चुअलबॉक्स अतिरिक्त, जिसके लिए चल रहे कर्नेल शीर्षकों को स्थापित करना आवश्यक है। यदि चल रहे कर्नेल मॉड्यूल अब नहीं हैं, तो संभावना है कि न तो कर्नेल हेडर होंगे।
इसके अलावा, नए संकलित वर्चुअलबॉक्स मॉड्यूल को कहीं भी जाने की जरूरत नहीं होगी, क्योंकि .66 मॉड्यूल निर्देशिका को साफ किया गया है।
लेकिन कहते हैं कि आप सभी को ठीक करते हैं: आपने अनिवार्य रूप से एक महंगा (और आंशिक) कर्नेल डाउनग्रेड किया है, और अतिरिक्त के मामले में, शेष .66 कर्नेल के साथ जोड़ अपग्रेड पर खो जाएंगे।
कर्नेल को अपग्रेड करना कुछ समय के लिए काम करेगा ...
अगर हम को दूर .67 गिरी और उसके जगह में मॉड्यूल के साथ 0.66 गिरी को पुनर्स्थापित, चीजें थोड़ी देर के लिए hunky डोरि हो जाएगा। ऊपर "बल आईएसओ मॉड्यूल" समाधान के रूप में, आवश्यक कोई रिबूट नहीं।
और कोई रिबूट कुछ भी नहीं खोएगा, क्योंकि कोई परिवर्धन-चुनौती वाला कर्नेल स्थापित नहीं है।
लेकिन इस तरह से कर्नेल अभी भी "अपग्रेड की जाने वाली" सूची में होगा, और यही समस्या जल्द या बाद में उत्पन्न होने के लिए बाध्य है।
दी, आप अब इसे अपनी पसंद के कुछ और उपयुक्त क्षणों में उत्पन्न कर सकते हैं, जो कि बहुत अधिक मूल्य का हो सकता है।
बस रिबूट!
रीबूटिंग, हाल ही में .67 कर्नेल सक्रिय हो जाएगा और इसके सभी मॉड्यूल और हेडर हैं।
इसलिए, रिबूट के बाद , अतिथि अतिरिक्त काम करेगा, और अपग्रेड "लेगा" होगा।
