হেডলেস Pi-এর বুট ব্যর্থতা ও নেটওয়ার্ক ব্যর্থতার পার্থক্য বোঝা

চারটি বিষয়ের মধ্যে আসলে কোনটি ব্যর্থ হয়েছে, কেউ তা জিজ্ঞাসা করার আগেই কার্ডটি কেস থেকে বেরিয়ে আসে। VPN বা নেটওয়ার্ক বদলের পর Pi উত্তর দেওয়া বন্ধ করেছে, আর রিফ্ল্যাশই একমাত্র উপায় বলে মনে হচ্ছে। তা খুব কমই হয়: লিজ সরে যেতে পারে, sshd থেমে যেতে পারে, অথবা উত্তর এমন পথে বেরোতে পারে যা আপনি অনুসরণ করতে পারেন না, এবং এদের প্রত্যেকের নিজস্ব সমাধান আছে। কাজের অংশ হলো যা আপনি দেখেছেন তার সঙ্গে যা আপনি ধরে নিয়েছেন তার পার্থক্য করা।

চারটি ফলাফল, এক নয়

বুট, ঠিকানা, শোনা আর পৌঁছানো—এই চারটি আলাদা ফলাফল, এবং অন্যগুলো ঠিক থাকলেও যেকোনো একটি ব্যর্থ হতে পারে। একটি বোর্ড নিখুঁতভাবে বুট হয়ে নেটওয়ার্কে কখনো নাও দেখা দিতে পারে। এটি এমন ঠিকানা নিয়ে দেখা দিতে পারে যা কেউ আশা করেনি, অথবা সঠিক ঠিকানা ধরে রেখে SSH বন্ধ থাকতে পারে। তিনটিই ঠিক করে তবুও অপ্রাপ্য থাকতে পারে, কারণ উত্তরগুলো ভুল গেটওয়ে দিয়ে বেরোয়।

রিফ্ল্যাশের প্রবৃত্তি ওই চারটিকে একটি প্রশ্নে নামিয়ে আনে, তাই এটি প্রায়ই একটি কাজ করা Pi দেয় কিন্তু কী আসলে ভেঙেছিল তার কোনো ব্যাখ্যা দেয় না।

প্রমাণ আসলে কোথায় শেষ হয়

কিছুতে হাত দেওয়ার আগে তিনটি জিনিস লিখে রাখুন: সর্বশেষ যে ঠিকানা আর আপলিংক কাজ করেছিল, কী বদলানো হয়েছিল, আর কোন কাজটি প্রথমে থেমে গিয়েছিল। যে হোস্টনেম আর রিজলভ হয় না, যে SSH সংযোগ সময় শেষে ব্যর্থ হয়, আর যে TCP সংযোগ প্রত্যাখ্যাত হয়—এরা তিনটি আলাদা পর্যবেক্ষণ, তিনটি আলাদা স্তরের দিকে ইশারা করে। ব্যর্থ ping একটি ঠিকানার প্রাপ্যতা পরীক্ষা করে আর উপরের প্রতিটি কারণেই ব্যর্থ হয়, যার মধ্যে আছে কখনো চালু না হওয়া বোর্ডও। তাই এটি বুট পরীক্ষার বিকল্প হতে পারে না।

স্থানীয় ডিসপ্লে বা রিকভারি কনসোল থাকলে তা ব্যবহার করুন, কারণ এটি যে প্রশ্নের উত্তর দেয় তা হলো মেশিনটি তার অপারেটিং সিস্টেম পর্যন্ত পৌঁছায় কি না। রিফ্ল্যাশ কেবল এই প্রশ্নটিই সমাধান করত। বোর্ড যদি ওই স্তরের আগেই ব্যর্থ হয়, তবে স্ক্রিনশট না থাকা থেকে হার্ডওয়্যার ত্রুটি অনুমান না করে প্ল্যাটফর্মের রিকভারি ডকুমেন্টেশন অনুসরণ করুন, আর ডায়াগনস্টিক হিসেবে পাওয়ার খোলা বন্ধ করুন।

চলমান সিস্টেমে অ্যাক্সেস পথ আবার গড়ুন

বর্তমান আপলিংক ও ঠিকানা নেটওয়ার্ক কনফিগারেশনের মালিকের মাধ্যমে খুঁজুন, তারপর তা রাউটারের বর্তমান ক্লায়েন্ট তালিকা এবং SSH ক্লায়েন্ট যে ঠিকানা ব্যবহার করেছিল তার সঙ্গে মেলান। সংরক্ষিত হোস্টনেম বা পুরোনো DHCP লিজ সপ্তাহের পর সপ্তাহ গতকালের গন্তব্যে ইশারা করতে পারে। এরপর নিশ্চিত করুন যে sshd চালু, বিদ্যমান কোনো ঠিকানায় শুনছে, এবং প্রশাসনিক নেটওয়ার্ক থেকে অনুমোদিত। Raspberry Pi-এর SSH নির্দেশিকা সার্ভার চালু করা আর বর্তমান ঠিকানায় সংযোগ করা—এই দুইকে দুটি আলাদা ধাপ হিসেবে দেখে, আর নতুন Raspberry Pi OS ইনস্টলে SSH ডিফল্টে বন্ধ থাকে।

হোস্টনেম অন্য মেশিনে পুনর্নির্দেশ করা যায়, আর প্রতিস্থাপন ইমেজ নিজের কী নিয়ে আসে, তাই সতর্কবার্তা ক্লিক করে পেরিয়ে না গিয়ে ইতিমধ্যে বিশ্বস্ত কোনো পথে ফিঙ্গারপ্রিন্ট যাচাই করুন। সতর্কবার্তা মুছে ফেলাই সাময়িক ঠিকানা বদলকে স্থায়ী বিশ্বাস-সমস্যায় পরিণত করার উপায়। কী প্রম্পটই যদি একমাত্র লক্ষণ হয়, তবে আপনি প্রাপ্যতার নয়, পরিচয়ের প্রশ্ন দেখছেন।

বোর্ডকে দোষ দেওয়ার আগে উত্তরের পথ অনুসরণ করুন

VPN রুট নির্বাচন বদলাতে পারে অথচ ভৌত লিংক সংযুক্ত থাকে, আর ঠিক তখনই Pi চালু, শোনা অবস্থায় থেকেও অপ্রাপ্য হয়। অনুরোধ আসে আর উত্তর এমন একটি টানেল দিয়ে বেরোয় যা প্রশাসকের ক্লায়েন্ট পার হতে পারে না। স্থানীয় কনসোল ও শোনা সকেট ফেরার পথ সম্পর্কে কিছুই প্রমাণ করে না, তাই নিশ্চিত করুন কোন ইন্টারফেস উত্তর বহন করে আর কোন গেটওয়ে বেছে নেয়। প্রশাসক আসলে যে নেটওয়ার্কে আছেন তার সঙ্গে তা মেলান, কারণ এই ব্যর্থতাই অন্যদের চেয়ে বেশি মৃত বোর্ড হিসেবে ভুল নির্ণয় হয়।

সবচেয়ে সস্তা পরীক্ষা হলো উত্তর বেরোনো দেখা: Pi-তে জিজ্ঞাসা করুন প্রশাসকের ঠিকানা কোন রুট বহন করবে, আর অনুরোধ যে ইন্টারফেসে এসেছিল তার সঙ্গে তা মেলান। সেখানে অমিল থাকলে পুরো লক্ষণটাই ব্যাখ্যা হয় আর খরচ একটি কমান্ড।

একবারে একটি সীমা, আর কখন রিফ্ল্যাশ ঠিক

বর্তমান অবস্থা সংরক্ষণ করে তার মালিকের মাধ্যমে কনফিগারেশন ঠিক করুন। নেটওয়ার্ক ম্যানেজার বদলানো, ফায়ারওয়াল ফ্লাশ করা আর স্ট্যাটিক ঠিকানা আন্দাজ করা—এই তিনটি পরিবর্তন পরের পর্যবেক্ষণকে অকেজো করে দেয়। প্রমাণ যদি VPN-এর রুট বা ফিল্টারিংয়ের দিকে ইশারা করে, তবে সেই ক্লায়েন্টের নিজস্ব থামানো বা মেরামতের রুটিনে ফিরে যান, সম্মত রিকভারি পরিকল্পনার ভেতরে কাজ করুন; নিয়ন্ত্রিত তুলনা আর এমন হোস্টে সুরক্ষা বন্ধ করা—যার ব্যাখ্যা আপনি দেননি—দুটি আলাদা বিষয়।

রিফ্ল্যাশ একটি সচেতন রিকভারি সিদ্ধান্ত, যা ডেটা, পরিচয় আর কোন স্তর ব্যর্থ হয়েছে তা বোঝার পরে নেওয়া হয়। লগইন না পাওয়া মাত্রই ডিফল্টে এটিই ঘটানো উচিত নয়।

কনফিগারেশন রেকর্ড এমন জায়গায় রাখুন যা Pi ছাড়াই পড়া যায়, আর ফেরার এমন পথ রাখুন যা আপনি যে টানেল বদলাতে যাচ্ছেন তার মধ্য দিয়ে যায় না। তারপর ক্রমে কাজ করুন: স্থানীয় কনসোল থেকে স্তর নিশ্চিত করুন, বর্তমান ঠিকানা খুঁজুন, লিসেনার ও তার নীতি দেখুন, উত্তরের পথ অনুসরণ করুন, আর একবারে একটি জিনিস বদলান। বোর্ড যদি কখনোই অপারেটিং সিস্টেমে না পৌঁছায়, তবে পরের ধাপ নেটওয়ার্ক নয়, রিকভারি ডকুমেন্টেশন।