हाल ही में एक कॉर्पोरेट कंप्यूटर पर स्टार्टअप के दौरान क्रैश

Question

कुछ हालिया अपडेट के बाद, मेरा कंप्यूटर अब बूट नहीं है! यहाँ मैं निर्धारित कर सकता हूँ:

• यह एक बहुत ही हालिया कंप्यूटर है जो मुझे कॉर्पोरेट आईटी द्वारा प्रदान किया गया था। इसमें हाल ही में Intel CPU (Skylake जनरेशन) है।
• कंप्यूटर Ubuntu 16.04 चलाता है।
• कंप्यूटर ने मार्च में कुछ समय सही ढंग से बूट किया। समस्या संभवतः सॉफ़्टवेयर अद्यतन या हार्डवेयर बग के कारण है।
• मेरे पास एक और कंप्यूटर 16.04 चल रहा है जिसमें बहुत ही समान सॉफ्टवेयर इंस्टॉल किए गए हैं (मैंने इस्तेमाल किया apt-clone), और यह ठीक काम करता है। इसमें अलग-अलग हार्डवेयर हैं (amd64, लेकिन अलग-अलग सीपीयू, अलग-अलग GPU, आदि)।
• कर्नेल शुरू होता है, initrd सही तरीके से काम करता है। जब मैं ग्राफिक्स मोड में एक स्प्लैश स्क्रीन के साथ बूट करता हूं, तो मुझे मेरे डीएम-क्रिप्ट वॉल्यूम के लिए पासवर्ड के लिए संकेत मिलता है, और आखिरी चीज जो मैं देखता हूं वह यह है कि यह सफलतापूर्वक घुड़सवार है।
• लॉगिन प्रॉम्प्ट प्राप्त करने से पहले हैंग होता है। जब कंप्यूटर हैंग होता है, तो यह एक मुश्किल हैंग होता है। यहां तक ​​कि Alt+ SysRqकोई जवाब नहीं देता। सीपीयू जाहिर तौर पर 100% पर आ गया है क्योंकि प्रशंसकों को पूर्ण विस्फोट होता है।
• मेरे पास अभी भी वह कर्नेल है जिसे मैं रिबूट करने से पहले चला रहा था। जब मैं ग्रब मेनू में इस कर्नेल का चयन करता हूं, तो मुझे वही लॉकअप मिलता है। तो ऐसा लगता है कि यह एक पहले से मौजूद कर्नेल बग है, जो किसी और चीज से ट्रिगर हो जाता है - लेकिन क्या?
• यदि मैं स्प्लैश स्क्रीन को बंद कर देता हूं ( ग्रब में कमांड लाइन splashसे हटाता linuxहूं), तो मुझे कई सेवाएं शुरू होती हैं, फिर यह लॉक हो जाता है।

• ग्रब में कमांड लाइन init=/bin/shको जोड़कर मैं एक रूट शेल प्राप्त कर सकता हूं linux। मैं भी जोड़कर आगे बढ़ सकता हूं

  systemd.unit=basic.target systemd.shell
  

  यह कई सेवाओं को शुरू करता है और tty9 पर एक रूट शेल चलाता है।

• यदि मैं systemctl start multi-user.targetउस मूल शेल से चलाता हूं , तो कंप्यूटर लॉक हो जाता है। तो संभवतः समस्या इन सेवाओं में से एक द्वारा शुरू हो रही है।
• मैं systemctl list-dependencies multi-user.targetयह देखने के लिए दौड़ा कि क्या सेवाएं शुरू होंगी। मैंने मैन्युअल रूप से सूचीबद्ध निर्भरता को एक-एक करके शुरू किया, और सब कुछ ठीक होने लगा।

तो यह हार्डवेयर बग की तरह दिखता है (क्योंकि यह एक कंप्यूटर पर होता है लेकिन दूसरे पर नहीं) जो किसी सॉफ्टवेयर द्वारा ट्रिगर हो जाता है। लेकिन क्या सॉफ्टवेयर? चूंकि कंप्यूटर इतनी मेहनत से बंद होता है, मुझे कोई लॉग नहीं मिल सकता है। मुझे कोई उपयोगी कंसोल आउटपुट भी नहीं मिल सकता है।

---

उपयोगी डिबगिंग तकनीक:

• Alt+ SysRq: जादू SysRq कुंजी , जो आपको आपातकालीन रिबूट जैसी चीजें करने देती है। यह कर्नेल को बहुत कम स्तर पर एक्सेस करता है, इसलिए यह सभी लेकिन सबसे खराब क्रैश में काम करता है। मेरे मामले में, Alt+ SysRqजवाब नहीं देता है, जो दर्शाता है कि दुर्घटना कितनी गहरी है।
• बूट मापदंडों को संशोधित करने के लिए, Shiftपावर को स्विच करने के बाद कुछ सेकंड दबाकर रखें । BIOS को कीबोर्ड को इनिशियलाइज़ करने के बाद, लेकिन ऑपरेटिंग सिस्टम के बूट से पहले आपको इसे दबाना होगा। इससे ग्रब मेनू दिखाई देता है।
• ग्रब मेनू पर, eमेनू प्रविष्टि के लिए कमांड लाइन संपादित करने के लिए दबाएँ । लिनक्स बूट मापदंडों को बदलने के लिए, उस रेखा पर नेविगेट करें जो इसके साथ शुरू होती है linux। एक आधुनिक उबंटू पर, आपको "उबंटू के लिए उन्नत विकल्प" के तहत पुरानी गुठली मिलेगी। कमांड लाइन में वांछित परिवर्तन करने के बाद, बूट करने के लिए Ctrl+ दबाएँ x। आपके द्वारा यहां किए गए कोई भी परिवर्तन केवल इस बूट के लिए हैं, वे डिस्क पर सहेजे नहीं गए हैं।
• linuxकमांड लाइन पर कुछ उपयोगी विकल्प :
  • quiet nosplashलगभग सभी बूट संदेश छुपाता है। बूट के दौरान कंसोल पर संदेश प्राप्त करने के लिए उन्हें हटा दें, जिससे समस्याओं का निदान करने का कोई भी मौका होना आवश्यक है।
  • recoveryआपको लगभग बिना सेवाओं के एक रूट शेल देता है। आपको रूट पासवर्ड जानना होगा। "पुनर्प्राप्ति मोड" मेनू प्रविष्टि इसका उपयोग करती है।
  • init=/bin/shआपको बिना किसी सेवाओं के साथ एक रूट शेल देता है। सामान्य बूट को फिर से शुरू करने के लिए, चलाएं exec init। आप इस बिंदु पर systemd विकल्प पास कर सकते हैं, जैसे exec init --unit=basic.targetinit और कुछ सेवाएं शुरू करने के लिए (ध्यान दें कि यह लॉग इन करने का कोई तरीका शुरू नहीं करता है, इसलिए आपके पास एक और कंसोल पर चलने वाला शेल बेहतर होगा)। ध्यान दें कि रूट फाइलसिस्टम को केवल पढ़ने के लिए माउंट किया गया है; mount -o remount,rw /इसे लिखने में सक्षम होने के लिए दौड़ें ।
  • systemd.unit=basic.targetसेवाओं का एक बहुत ही बुनियादी सेट शुरू करता है। ध्यान दें कि इसमें लॉग इन करने का कोई तरीका शामिल नहीं है! systemctl set-default basic.targetरूट प्रॉम्प्ट पर चलाकर आप इसे डिफ़ॉल्ट बना सकते हैं । मूल डिफ़ॉल्ट लक्ष्य को पुनर्स्थापित करने के लिए, चलाएं systemctl set-default graphical.target(या systemctl set-default multi-user.targetबिना GUI वाले सर्वर के लिए)।
  • systemd.debug-shelltty9 पर एक रूट शेल शुरू करता है। systemctl enable debug-shellरूट प्रॉम्प्ट पर चलाकर आप इसे प्रत्येक बूट के लिए सक्षम कर सकते हैं । समस्या को हल करने के बाद इसे अक्षम करना न भूलें systemctl disable debug-shell। T9 पर स्विच करने के लिए Alt+ दबाएँ F9।
  • फेडोरा सिस्टमड टिप्स , आर्क लिनक्स बूट समस्या युक्तियां भी देखें ।

Answer 1

समस्या

यह पता चला है कि मेरी समस्या (कुछ?) स्काइलेक सीपीयू और हाल के लिनक्स कर्नेल पर नवीनतम इंटेल माइक्रोकोड के बीच एक ज्ञात मुद्दा है, जो मुख्य रूप से sssd द्वारा ट्रिगर किया गया है । देखें उबंटू बग # 1759920 "इंटेल-माइक्रोकोड 3.20180312.0 लॉगिन स्क्रीन पर लॉकअप का कारण बनता है (w / linux छवि 4.13.0-37-सामान्य)" , और भी अन्य कीड़े जो बाहर बारी के एक नंबर एक ही मुद्दे के बारे में होना करने के लिए जैसे कि Ubuntu बग # 1746806 "sssd AWS c5 और m5 इंस्टेंस को क्रैश करता प्रतीत होता है, 100% CPU का कारण बनता है" और Ubuntu बग # 1746418 "सिस्टम को जमा देता है जब लिनक्स-इमेज-4.15.0-32-जेनेरिक स्थापित करने के बाद Xorg शुरू होता है" । आप इस बग का सामना करने की संभावना रखते हैं यदि:

• आपके पास बहुत हालिया इंटेल सीपीयू है। जहाँ तक मैं बता सकता हूँ, यह बग केवल Skylake CPUs पर ही उत्पन्न होता है ।
• आपके पास इंटेल-माइक्रोकोड पैकेज स्थापित है। एक पहले से परीक्षण किए गए कर्नेल के लिए मेरे लिए काम नहीं किया क्योंकि मैं केवल उस कर्नेल को पहले के माइक्रोकोड के साथ चलाऊंगा।
• आपका कंप्यूटर उपयोगकर्ता प्रमाणीकरण के लिए एक कॉर्पोरेट नेटवर्क (आमतौर पर LDAP या सक्रिय निर्देशिका) से जुड़ा हुआ है। हालाँकि बग को ट्रिगर करने के अन्य तरीके हैं, लेकिन sssd को चलाना सबसे सामान्य अपराधी लगता है। Xorg के दुर्घटनाग्रस्त होने की भी खबरें हैं ।

यह बग जनवरी 2018 में प्रकाशित स्पेक्टर सुरक्षा समस्या के लिए शमन के कारण है। कुछ कर्नेल कोड और कुछ प्रोसेसर माइक्रोकोड के बीच असंगति है जो कुछ परिस्थितियों में लॉक-अप का कारण बनता है।

मरम्मत कैसे करें

1. यदि आप सामान्य रूप से बूट नहीं कर सकते हैं, तो आपको ग्रब प्रॉम्प्ट पर कर्नेल कमांड लाइन को संपादित करना होगा। मूल शेल प्राप्त करने के लिए स्पष्टीकरण और संभावित तरीकों के लिए प्रश्न देखें।
2. इस विशिष्ट बग के लिए एक समाधान कर्नेल कमांड लाइन ( 1746418/14 , 1759920/56 ) के noibpbपैरामीटर को जोड़ना है । यह आपको सामान्य रूप से बूट करने और कुछ मरम्मत करने देना चाहिए। यह भेद्यता शमन को निष्क्रिय करता है जो समस्या का कारण बनता है, जिसका अर्थ है कि आपका कंप्यूटर अब कुछ हमलों की चपेट में है। वे स्थानीय हमले हैं, यानी हमलावर को आपकी मशीन पर कोड चलाने की आवश्यकता है, लेकिन ये हमले संभवतः वेब ब्राउज़र में जावास्क्रिप्ट के माध्यम से किए जा सकते हैं। यदि आपके पास कोई अन्य रास्ता नहीं है, तो आप कर्नेल कमांड लाइन में जोड़कर इसे स्थायी बना सकते हैं जब तक कि आप एक निश्चित कर्नेल प्राप्त नहीं कर सकते।
   
   noibpb
3. उबंटू में, 23 अप्रैल 2018 के सप्ताह को फिक्स होने की उम्मीद है , जो कि संभवतः 4.4.0-117 और 4.13.0-39 कर्नेल होगा। इस बीच, टायलर हिक्स ने 4.4 और 4.13 के लिए परीक्षण कर्नेल प्रकाशित किया है ।

मैंने समस्या का निदान कैसे किया

मैंने कई चीजों की कोशिश की (सवाल देखें) और यह निर्धारित किया कि बग को पहुंचने basic.targetऔर पहुंचने के बीच कहीं ट्रिगर किया गया था multi-user.target। इसलिए मैंने डिफ़ॉल्ट सिस्टमड लक्ष्य को basic.target( systemctl set-default basic.target) में सेट किया और रूट शेल प्राप्त करने के लिए debug-shellसेवा ( systemctl enable debug-shell) को सक्षम किया ।

मैं भाग गया systemctl list-dependencies multi-user.targetऔर मैन्युअल रूप से सूचीबद्ध निर्भरता को एक-एक करके शुरू किया। इससे दुर्घटना नहीं हुई।

सभी सेवाओं को सीधे systemd द्वारा प्रबंधित नहीं किया जाता है । कुछ के रूप में प्रबंधित कर रहे हैं कल का नवाब सेवाओं और कुछ के रूप में प्रबंधित कर रहे हैं SysVinit स्क्रिप्ट । नीचे दी गई शेल स्क्रिप्ट उन सभी को चलाती है। नोट: मैंने केवल एक बार इसका परीक्षण किया था, और यह डिजाइन द्वारा दुर्घटनाग्रस्त हो गया।

#!/bin/sh
wants=$(systemctl show -p Wants multi-user.target | sed 's/^Wants=//' | tr ' ' '\n' | sort)
log=/var/tmp/multi-user-steps-$(date +%Y%m%d-%H%M%S)

log () {
  echo "$* ..." | tee -a "$log"
  sync
  "$@"
  ret=$?
  echo "$* -> $ret" | tee -a "$log"
  sync
  return $ret
}

# systemd services
for service in $wants; do
  log systemctl start $service
  sleep 2
done

# upstart services
for conf in /etc/init/*.conf; do
  service=${conf##*/}; service=${service%.conf}
  log service ${service} start
  sleep 2
done

# sysvinit services
for service in /etc/rc3.d/S*; do
  log ${service} start
  sleep 2
done

मेरा कंप्यूटर शुरू करने के बाद क्रैश हो गया sssd। वहाँ से, "sssd linux kernel hang" पर एक वेब खोज ने मुझे https://bugs.launchpad.net/cloud-images/+bug/1746806 पर और निदान और समाधान के लिए प्रेरित किया ।

Comments

मैं इसमें भी भाग गया। मैंने इंटेल-माइक्रोकोड पैकेज को हटा दिया और इसे फिर से स्थापित होने से बचाने के लिए इसे ब्लैक लिस्ट कर दिया। माइक्रो-कोड जो समस्या का कारण बनता है वह स्थायी रूप से सीपीयू में नहीं जोड़ा जाता है। इसे हर बार फिर से लोड किया जाता है। इसलिए इसे लोड नहीं करना एक काम के रूप में भी काम करेगा। उस मामले में noipbp की जरूरत नहीं है और आपको अभी भी उपशमन मिलेंगे। मेरे मामले में यह सिस्टम कॉर्पोरेट प्रॉक्सी-सर्वरों की अतिरिक्त सुरक्षा के बिना सीधे इंटरनेट का सामना करने वाला अधिकांश समय है।

— Tonny

@ टोननी अन्य बग्स को ठीक करता है, जैसे कि यह , साथ ही ऐसे मुद्दे जो इंटेल का खुलासा नहीं करता है। हालांकि यह वास्तव में एक समाधान है, मैं असहज नहीं हूं कि माइक्रोकोड अपडेट लागू नहीं कर रहा हूं - सिवाय इसके कि स्पेक्टर / मेल्टडाउन लगता है कि एक को थोड़ा बाहर निकाल दिया गया है। मैं noipbpज्यादातर प्रभावित प्रणाली में बूट करने के तरीके के रूप में प्रस्ताव कर रहा हूं । मुझे लगता है कि कर्नेल को अपग्रेड करने के लिए यहां सबसे अच्छा फिक्स है।

— गाइल्स

मैं जानता हूं और मैं सहमत हूं। लेकिन नई गुठली अभी तक यहां नहीं हैं और कुछ समय के लिए मैं माइक्रोकोड वाले सिस्टम के लिए सबसे अधिक माइटिगेशन (माइक्रोकोड को छोड़कर) के साथ एक कार्य प्रणाली पसंद करता हूं, लेकिन कोई भी सॉफ्टवेयर मितली (जो कि माइक्रोकोड से अधिक कवर नहीं करता है)। माइक्रोकोड अपडेट के बारे में: इन नए स्काइलेक्स के लिए ऐसा लगता है कि स्पेक्टर / मेल्टडाउन फिक्स अब तक के एकमात्र माइक्रोकोड अपडेट हैं, इसलिए हम उनके बिना बहुत याद नहीं करते हैं। पुराने CPU के लिए यह एक और मामला है। बहुत सारे CPU इरेटा माइक्रोकोड अपडेट के साथ तय किए गए हैं। और मैं वास्तव में उन लोगों के बिना जाने के लिए घृणा करूंगा।

— Tonny