हेडलेस Pi की बूट विफलता को नेटवर्क विफलता से अलग पहचानना

कार्ड बाहर निकाला जाता है, इससे पहले कि किसी ने पूछा हो कि चार में से कौन-सी चीज़ वास्तव में विफल हुई। VPN या नेटवर्क बदलने के बाद Pi ने जवाब देना बंद कर दिया, और रीफ्लैश ही बचा हुआ एकमात्र कदम लगता है। ऐसा शायद ही होता है: लीज़ बदल सकती है, sshd रुक सकता है, या उत्तर ऐसे मार्ग से निकल सकता है जिसे आप ट्रेस नहीं कर सकते, और इनमें से हर एक का अपना समाधान है। उपयोगी काम यह है कि आपने जो देखा उसे उससे अलग करें जो आपने मान लिया।

चार परिणाम, एक नहीं

बूट होना, पता मिलना, सुनना और पहुँच में होना—ये चार अलग परिणाम हैं, और इनमें से कोई भी विफल हो सकता है जबकि बाकी अभी भी कायम हों। बोर्ड पूरी तरह बूट होकर भी नेटवर्क पर कभी न दिखे। वह ऐसे पते के साथ दिख सकता है जिसकी किसी ने उम्मीद नहीं की, या सही पता रखते हुए SSH बंद हो सकता है। वह तीनों सही कर सकता है और फिर भी पहुँच से बाहर रह सकता है, क्योंकि उत्तर गलत गेटवे से बाहर जाते हैं।

रीफ्लैश की प्रवृत्ति उन चारों को एक ही सवाल में समेट देती है, इसीलिए वह अक्सर एक चलता-फिरता Pi देती है और यह कोई स्पष्टीकरण नहीं कि असल में क्या टूटा।

सबूत वास्तव में कहाँ ख़त्म होते हैं

कुछ भी छूने से पहले तीन बातें लिखें: आख़िरी बार काम करने वाला पता और अपलिंक, क्या बदला गया, और पहला ऐसा काम जो रुक गया। जो होस्टनाम अब रिज़ॉल्व नहीं होता, जो SSH कनेक्शन समय-सीमा पर रुक जाता है, और जो TCP कनेक्शन अस्वीकार होता है—ये तीन अलग अवलोकन हैं जो तीन अलग परतों की ओर इशारा करते हैं। विफल ping एक पते की पहुँच जाँचता है और ऊपर बताए हर कारण से विफल होता है, जिसमें वह बोर्ड भी शामिल है जो कभी शुरू ही नहीं हुआ। इसीलिए वह बूट परीक्षण की जगह नहीं ले सकता।

अगर स्थानीय डिस्प्ले या रिकवरी कंसोल उपलब्ध हो तो उसका उपयोग करें, क्योंकि वह जिस सवाल का जवाब देता है वह यह है कि मशीन अपने ऑपरेटिंग सिस्टम तक पहुँचती है या नहीं। रीफ्लैश केवल यही सवाल हल करता। अगर बोर्ड उस चरण से पहले ही विफल हो जाए, तो स्क्रीनशॉट न होने से हार्डवेयर ख़राबी का अनुमान लगाने के बजाय प्लेटफ़ॉर्म के रिकवरी दस्तावेज़ का पालन करें, और निदान के तौर पर बिजली खींचना बंद करें।

चालू सिस्टम पर पहुँच मार्ग फिर से बनाएँ

मौजूदा अपलिंक और पता नेटवर्क कॉन्फ़िगरेशन के मालिक के ज़रिए खोजें, फिर उसकी तुलना राउटर की मौजूदा क्लाइंट सूची और SSH क्लाइंट द्वारा इस्तेमाल किए गए पते से करें। सहेजा हुआ होस्टनाम या पुरानी DHCP लीज़ हफ़्तों तक कल के गंतव्य की ओर इशारा कर सकती है। फिर पुष्टि करें कि sshd सक्षम है, किसी मौजूद पते पर सुन रहा है, और प्रशासन नेटवर्क से अनुमत है। Raspberry Pi की SSH मार्गदर्शिका सर्वर सक्षम करने और मौजूदा पते से जुड़ने को दो अलग चरण मानती है, और नया Raspberry Pi OS इंस्टॉल SSH को डिफ़ॉल्ट रूप से बंद रखता है।

होस्टनाम को किसी दूसरी मशीन की ओर मोड़ा जा सकता है, और बदली हुई इमेज अपनी चाबी के साथ आती है, इसलिए चेतावनी को क्लिक करके आगे बढ़ने के बजाय किसी ऐसे रास्ते से फ़िंगरप्रिंट जाँचें जिस पर आप पहले से भरोसा करते हैं। चेतावनी मिटाना ही वह तरीका है जिससे अस्थायी पता-बदलाव स्थायी भरोसा-समस्या बन जाता है। अगर चाबी की पूछ ही एकमात्र लक्षण हो, तो आप पहुँच का नहीं, पहचान का सवाल देख रहे हैं।

बोर्ड को दोष देने से पहले उत्तर का मार्ग खोजें

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

सबसे सस्ती जाँच उत्तर को निकलते देखना है: Pi पर पूछें कि कौन-सा मार्ग प्रशासक का पता ले जाएगा और उसकी तुलना उस इंटरफ़ेस से करें जिस पर अनुरोध आया था। वहाँ असंगति पूरे लक्षण को समझा देती है और एक ही आदेश की लागत लेती है।

एक बार में एक सीमा, और रीफ्लैश कब सही है

मौजूदा स्थिति सुरक्षित रखने के बाद उसके मालिक के ज़रिए कॉन्फ़िगरेशन ठीक करें। नेटवर्क मैनेजर बदलना, फ़ायरवॉल ख़ाली करना और स्थिर पता अनुमान लगाना—ये तीन बदलाव अगले अवलोकन को बेकार कर देते हैं। अगर सबूत VPN के मार्ग या फ़िल्टरिंग की ओर इशारा करते हैं, तो उसी क्लाइंट की अपनी रोक या मरम्मत प्रक्रिया पर लौटें, सहमत रिकवरी योजना के भीतर काम करें; नियंत्रित तुलना और ऐसे होस्ट पर सुरक्षा बंद करना—जिसे आपने समझाया नहीं—दो अलग बातें हैं।

रीफ्लैश एक सोचा-समझा रिकवरी विकल्प है, जो डेटा, पहचान और विफल चरण को समझने के बाद लिया जाता है। लॉगिन न मिलना डिफ़ॉल्ट रूप से इसे नहीं भड़काना चाहिए।

कॉन्फ़िगरेशन रिकॉर्ड ऐसी जगह रखें जहाँ Pi के बिना पढ़ा जा सके, और वापस आने का ऐसा रास्ता रखें जो उस सुरंग से न गुज़रे जिसे आप बदलने वाले हैं। फिर क्रम से काम करें: स्थानीय कंसोल से चरण की पुष्टि करें, मौजूदा पता खोजें, लिसनर और उसकी नीति जाँचें, उत्तर का मार्ग खोजें, और एक बार में एक चीज़ बदलें। अगर बोर्ड कभी ऑपरेटिंग सिस्टम तक नहीं पहुँचा, तो अगला कदम नेटवर्क नहीं, रिकवरी दस्तावेज़ है।