आज मैंने Ubuntu 14.04 से 16.04 तक अपने एक सर्वर को आगे बढ़ाने का फैसला किया। उत्पादन सर्वर पर ऐसा करने की अनुशंसा नहीं की जाती है, क्योंकि कई समस्याएं हैं जो गलत हो सकती हैं। सर्वोत्तम प्रथाएं हमेशा संकेत देती हैं कि प्रतिस्थापन के रूप में किसी अन्य सर्वर को स्पिन करना, या एक अस्थायी सर्वर जाने का सबसे सुरक्षित तरीका है। उस ने कहा, जो चीजों को करने में आनंद नहीं लेता है, जो किया जाना चाहिए।
अपग्रेड बहुत अच्छी तरह से चला गया, एक चकाचौंध अपवाद के साथ, libvirt-bin ठीक से अपग्रेड नहीं हो सका। यहां स्थिति को ठीक करने के लिए कदम उठाए गए हैं और साथ ही वे कदम भी नहीं उठाए गए हैं।
प्रारंभिक परीक्षण में sudo dpkg –configure -a के साथ समस्या को ठीक करना था, वहां कोई भाग्य नहीं। मैंने एप्टीट्यूड ऑटो रिज़ॉल्वर का उपयोग करने का भी प्रयास किया, फिर शुद्ध और पुन: स्थापित किया। इसके अलावा कोई भाग्य नहीं।
समस्या की जड़ में जाने के लिए, मूर्खतापूर्ण तरीके से अनुमान लगाने की बजाय मैं भागा
sudo journalctl -xe
जैसा कि एपरमोर में एक बग के ऊपर दिखाया गया है, लिबावर्ट-बिन को अब चलाने की अनुमति नहीं है, क्योंकि यह अब कॉन्फ़िगर नहीं किया गया था (मजाकिया तौर पर मैं इसे बता सकता था)।
यहाँ समस्या को कैसे ठीक किया जाए, और समस्या की जड़ क्या है। सबसे पहले हमें एपर्मर पार्सर कैश को शुद्ध करने की आवश्यकता है, क्योंकि इसमें डेटा स्टोर किया गया है जो कि लिवरविर्ट-बिन शुरू करने में असमर्थ है।
sudo apparmor_parser –purge-cache
अगला हम libvirt-bin को शुरू करने से रोकने वाले नियम को हटा देते हैं।
फिर हम आगे बढ़ते हैं और इसे प्रतिस्थापित करते हैं।
अंत में, हम पुनः आरंभ करने के लिए libvirt बताने के लिए, और सभी अच्छे होंगे।
sudo systemctl पुनरारंभ libvirt-bin
Libvirt-bin की स्थिति की जांच करने के लिए निम्नलिखित कमांड दर्ज करें
sudo सेवा libvirt-bin स्थिति
यह libvirt-bin की एक छोटी सी स्टेट जांच का उत्पादन करेगा, जिसमें दिखाया गया है कि ऊपर उल्लिखित प्रक्रिया ने चाल चली। अब हम अपनी आभासी मशीनों को फिर से चला सकते हैं!
वर्तमान में मैं जिन अन्य त्रुटियों की जांच कर रहा हूं, उन्हें अपग्रेड करने के साथ ही समाधान भी लागू किया जा सकता है:
एलएसबी शुरू करने में विफल: मेल ट्रांसपोर्ट एजेंट को हटा दें। यह एक उपसर्ग त्रुटि थी, जिसे मशीन पूरी तरह से बूट होने से पहले हल किया गया था।
snd_hda_intel 0000: 00: 1f.3: i915_bpo घटक मास्टर (-19) जोड़ने में विफल। यह एक साउंड कार्ड की त्रुटि है, अलसा को अपग्रेड करके ठीक किया जा सकता है (मैं सर्वर से ध्वनि का उपयोग करने की योजना नहीं करता हूं, इसलिए यह प्रदर्शन को प्रभावित नहीं करता है)।
अंततः dev-disk-by x2duuid-E7A1 x2dCC4A.device: देव देव-डिस्क-बाय x2duuid-E7A1 x2dCC4A.device अलग-अलग sysfs के साथ दो बार दिखाई दिए। जाहिर है, मेरे EFI विभाजन का बैकअप इसे पूरी तरह से उसी UUID के रूप में पंजीकृत करने के लिए पर्याप्त था। NVMe ड्राइव (प्राइमरी) में एक विभाजन UUID होता है, हालाँकि RAID (बैकअप) नहीं होता है। इसे ठीक करने के लिए मैं प्राथमिक ड्राइव को अकेला छोड़ दूंगा और UUIDgen का उपयोग करके बैकअप ड्राइव के UUID को बदल दूंगा और फिर ट्यून 2 एफएस / dev / sdx -U नया -id-संख्या-से-uuidgen।
2 मिनट पढ़ा
