লিনাক্স বুট সমস্যা এবং হার্ডওয়্যার ব্যর্থতা নির্ণয় করা

ইনফরমটেক ডিজিটাল » মানে » লিনাক্স বুট সমস্যা এবং হার্ডওয়্যার ব্যর্থতা নির্ণয় করা

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

আপনি যদি “root file system not found,” “No space left on device,” “EXT4-fs error,” “XFS: Metadata CRC error,” বা মারাত্মক Kernel Panic-এর মতো মেসেজের সম্মুখীন হন , তাহলে এখানে আপনি শিখবেন কীভাবে সেগুলোর অর্থ বুঝতে হয়, কোন কমান্ডগুলো ব্যবহার করতে হয় এবং কোন ক্রমে কাজগুলো করতে হয়। আমরা আরও দেখব কীভাবে নির্ধারণ করতে হয় যে সমস্যাটি সত্যিই সফটওয়্যার-সম্পর্কিত নাকি হার্ডওয়্যার (র‍্যাম, এসএসডি/এইচডিডি, নেটওয়ার্ক কার্ড, ইত্যাদি) তার শেষ পর্যায়ে রয়েছে, এবং সমস্যা সমাধানের সময় ডেটা হারানোর ঝুঁকি কীভাবে কমানো যায়।

লিনাক্সে বুট সমস্যার সাধারণ কারণসমূহ

এলোমেলোভাবে বিভিন্ন জিনিস নিয়ে ঘাঁটাঘাঁটি শুরু করার আগে, লিনাক্স কেন চালু হয় না বা ভুলভাবে চালু হয় তার সবচেয়ে সাধারণ কারণগুলো বুঝে নেওয়া ভালো । মূল কারণটি বুঝতে পারলে আপনার ঘণ্টার পর ঘণ্টা সমস্যা সমাধান এবং এমন সব সমাধান চেষ্টা করার সময় বাঁচবে, যেগুলো কোনো কাজেই আসে না।

প্রথম সমস্যাগুলো বুট ম্যানেজার এবং BIOS/UEFI কনফিগারেশন থেকে উদ্ভূত হয় : যেমন—ভুলভাবে তৈরি হওয়া GRUB এন্ট্রি, ডুয়াল বুট সেটআপে উইন্ডোজ ইনস্টল করার পর MBR ওভাররাইট হয়ে যাওয়া , আপনার ডিস্ট্রিবিউশনের সাথে Secure Boot-এর অসামঞ্জস্যতা, অথবা BIOS-এর ভুল ডিস্ক থেকে বুট করার চেষ্টা। এইসব ক্ষেত্রে, আপনি প্রায়শই GRUB মেনুটি দেখতেই পাবেন না, অথবা যখন আপনি আপনার লিনাক্স ডিস্ট্রিবিউশন নির্বাচন করবেন, তখন এটি ফ্রিজ হয়ে যাবে বা ফার্মওয়্যারে ফিরে যাবে।

আরেকটি গুরুত্বপূর্ণ ব্লক এর সাথে সম্পর্কিত। ডিস্ক এবং ফাইল সিস্টেমক্ষতিগ্রস্ত পার্টিশন, ত্রুটিপূর্ণ সেক্টর, EXT4 বা XFS ফাইলের ত্রুটি, সিস্টেম ডিস্ক পূর্ণ হয়ে যাওয়া, অথবা LVM ত্রুটি। এটি সাধারণত বুট করার সময় নিম্নলিখিত বার্তাগুলির মাধ্যমে প্রকাশ পায়, যেমন “মাউন্ট করতে ব্যর্থ /…","EXT4-fs ত্রুটি","XFS: আনমাউন্ট করুন এবং xfs_repair চালানঅথবা এমনকি জরুরি মোডে চলে যেতে পারে, যা আপনাকে কার্যকর করতে বলবে journalctl -xb.

কার্নেল আপডেট বা ত্রুটিপূর্ণভাবে প্রয়োগ করা প্যাচের পরেও সমস্যা হওয়া খুবই সাধারণ । অসম্পূর্ণ ডাউনলোড, আনলোড হওয়া মডিউল, আপনার হার্ডওয়্যারের সাথে আর সামঞ্জস্যপূর্ণ নয় এমন ড্রাইভার, অথবা initramfs-এর পরিবর্তন সিস্টেমকে বুট হওয়ার মাঝপথে ফ্রিজ করে দিতে পারে বা স্টার্টআপের সময় কার্নেল প্যানিক ঘটাতে পারে।

সিস্টেমের নিজস্ব কনফিগারেশন সংক্রান্ত অংশটি আমাদের অবশ্যই ভুলে গেলে চলবে না : যেমন—অতিরিক্ত কঠোর সিকিওর বুট রুলস (উদাহরণস্বরূপ, /var/log/audit পূর্ণ হয়ে গেলে auditd-কে HALT মোডে কনফিগার করা), জায়গার অভাবে গুরুত্বপূর্ণ সার্ভিসগুলোর ব্যর্থ হওয়া, অথবা কনফিগারেশন ফাইলে এমন পরিবর্তন আনা যা অপরিহার্য ডেমনগুলোকে (যেমন নেটওয়ার্ক, systemd, Azure-এর মতো ক্লাউডে cloud-init ইত্যাদি) চালু হতে বাধা দেয়।

সবশেষে, রয়েছে হার্ডওয়্যার স্তর: লাল SMART ফ্ল্যাগযুক্ত ডিস্ক, ECC ত্রুটিযুক্ত RAM, প্যাকেট হারানো নেটওয়ার্ক কার্ড, বা অতিরিক্ত গরম হয়ে যাওয়া SSD । প্রায়শই, এর সূত্রটি কার্নেল মেসেজ (dmesg) অথবা SMART এবং EDAC কাউন্টারের মধ্যে পাওয়া যায়, তাই আমরা দেখব কীভাবে সেগুলি সাবধানে পড়তে হয়।

স্টার্ট না হওয়ার উৎস কীভাবে শনাক্ত করবেন

হঠাৎ করে চালু হওয়া এড়ানোর মূল উপায় হলো ভার্বোস বুট মোড চালু করে লগগুলো পর্যালোচনা করা । ডিফল্টরূপে, অনেক ডিস্ট্রিবিউশন একটি সুন্দর স্প্ল্যাশ স্ক্রিন দেখায় যা বার্তাগুলোকে আড়াল করে রাখে; এটি দেখতে ভালো লাগলেও, কোনো সমস্যা হলে তা কোনো কাজে আসে না।

যেসব সিস্টেমে GRUB ব্যবহৃত হয়, সেখানে আপনি /etc/default/grub ফাইলটি সম্পাদনা করে সাইলেন্ট মোড নিষ্ক্রিয় করতে পারেন । এই লাইনটি খুঁজুন:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

এবং এটিকে প্রতিস্থাপন করুন:

GRUB_CMDLINE_LINUX_DEFAULT=""

এরপর কনফিগারেশনটি পুনরায় তৈরি করতে `update-grub` (অথবা আপনার ডিস্ট্রিবিউশনের সমতুল্য কমান্ড) চালান। পরবর্তী বুটে, আপনি সমস্ত কার্নেল এবং সিস্টেমডি বার্তা প্রদর্শিত হতে দেখবেন, যা আপনাকে সিস্টেম ক্র্যাশের কারণ হওয়া সঠিক ত্রুটিটি চিহ্নিত করতে সাহায্য করবে ।

যদি সিস্টেমটি আংশিকভাবে বুট করতে পারে অথবা আপনি কোনো লাইভ পরিবেশ থেকে এটি অ্যাক্সেস করতে পারেন, তাহলে /var/log- এ বেশ কিছু গুরুত্বপূর্ণ লগ পাওয়া যাবে :

• /var/log/boot.logস্টার্টআপ পর্যায়ে যা কিছু ঘটে, তার সবকিছু রেকর্ড করে; ত্রুটিটি এই পর্যায়ে হলে, প্রথমে এখানেই খতিয়ে দেখতে হবে।
• প্রথমেই / var / log /? বার্তা o প্রথমেই / var / log /? Syslog- র (ডিস্ট্রোর উপর নির্ভর করে): সাধারণ সিস্টেম ইভেন্ট, যা সার্ভিস, ডেমন ইত্যাদির ত্রুটি দেখার জন্য খুব উপযোগী।
• জন্য dmesgকার্নেল বার্তা প্রদর্শন করে, যার মধ্যে হার্ডওয়্যার ব্যর্থতা, মডিউল সমস্যা, বাস ত্রুটি, পিসিআই ত্রুটি ইত্যাদি অন্তর্ভুক্ত।
• journalctlsystemd ব্যবহৃত সিস্টেমগুলিতে, এটি সম্পূর্ণ রেজিস্ট্রি পরিভ্রমণ করার প্রধান টুল; এর সাথে journalctl -xb আপনি চূড়ান্ত সূচনাটি তার সমস্ত মহিমায় দেখতে পান।

যদি সিস্টেমটি ডেস্কটপে না পৌঁছে TTY বা রিকভারি মোডে পৌঁছায়, তাহলে আপনি সরাসরি সেখান থেকে `journalctl -xb` কমান্ডটি চালাতে পারেন । যদি তাতেও কাজ না হয়, তবে আপনাকে একটি লাইভ ইউএসবি (Live USB) থেকে বুট করে , সিস্টেম ডিস্কটি মাউন্ট করতে হবে এবং লাইভ পরিবেশ থেকে সেই ফাইলগুলো পড়তে হবে।

সমস্যাটি হার্ডওয়্যার-সম্পর্কিত নাকি সফটওয়্যার-সম্পর্কিত, তা যাচাই করুন।

কনফিগারেশন সম্পাদনা করতে গিয়ে মাথা ঘামানোর আগে, সমস্যাটি সরাসরি হার্ডওয়্যারের (যেমন: ডিস্ক, মেমরি, সিপিইউ, মাদারবোর্ড বা পাওয়ার সাপ্লাই ) কিনা তা যাচাই করে নেওয়া ভালো । অনেক ইনস্টলেশন যা "হঠাৎ করে" করাপ্টেড হয়ে যায়, তা আসলে একটি নষ্ট হতে চলা এসএসডি বা ত্রুটিপূর্ণ র‍্যামের লক্ষণ প্রকাশ করে।

প্রথম পদক্ষেপ হলো, যদি কম্পিউটার ড্রাইভটিকে শনাক্তই করতে না পারে, তবে BIOS/UEFI- তে প্রবেশ করে ড্রাইভটি তালিকাভুক্ত আছে কিনা তা নিশ্চিত করা। যদি ড্রাইভটি একেবারেই না দেখা যায়, বা মাঝে মাঝে দেখা যায়, তবে সংযোগ, SATA কেবল এবং পাওয়ার সাপ্লাই পরীক্ষা করুন, অথবা ধরে নিন যে ড্রাইভটি পুনরায় ব্যবহার করার প্রয়োজন হতে পারে।

আপনি GRUB বা Live boot পর্যায়ে পৌঁছালে, আপনার RAM পরীক্ষা করার জন্য GRUB মেনু থেকে MemTest86+ চালু করতে পারেন । এটিকে অন্তত আটটি পাস পর্যন্ত চলতে দিন; যদি আপনি লাল রেখা দেখতে পান, তাহলে মেমোরিটি ত্রুটিপূর্ণ এবং মডিউলগুলো প্রতিস্থাপন করতে হবে। ত্রুটিপূর্ণ RAM হলো ডেটা করাপশনের একটি উর্বর ক্ষেত্র।

লিনাক্সে ডিস্কের অবস্থা পরীক্ষা করতে smartmontools ব্যবহার করুন । এটি ইনস্টল করার পর, SMART সক্রিয় করুন এবং সবচেয়ে গুরুত্বপূর্ণ অ্যাট্রিবিউটগুলো পর্যালোচনা করুন:

• স্থানান্তরিত_সেক্টর_সিটিপুনরায় বরাদ্দকৃত সেক্টরের সংখ্যা; যদি এর মান ০-এর বেশি হয়, তাহলে সেই ডিস্কে ইতিমধ্যেই ত্রুটিপূর্ণ সেক্টর তৈরি হতে শুরু করেছে।
• বর্তমান_অমীমাংসিত_ক্ষেত্র_সিটিপুনর্বন্টনের অপেক্ষায় থাকা সেক্টরসমূহ; ০-এর চেয়ে বড় যেকোনো মান আসন্ন ব্যর্থতার উচ্চ ঝুঁকি নির্দেশ করে।
• বিদ্যুৎ_চালু_ঘন্টামোট ব্যবহারের সময়; এই সংখ্যা যত বেশি হবে, ডিস্কটি বিকল হওয়ার সম্ভাবনাও তত বেশি।

`smartctl -H /dev/sdX` ব্যবহার করে আপনি দ্রুত দেখতে পারবেন ডিস্কটি হেলথ টেস্টে পাস করেছে নাকি ফেল করেছে। যদি ফলাফল PASSED না হয়, তাহলে আপনাকে যত তাড়াতাড়ি সম্ভব আপনার ডেটা ব্যাক আপ করতে হবে এবং এটি প্রতিস্থাপন করার কথা ভাবতে শুরু করতে হবে।

উচ্চ তাপমাত্রার আশঙ্কা থাকলে, ইনস্টল করুন এলএম-সেন্সর এবং চালান sensors (o watch -n 2 sensors (রিয়েল টাইমে দেখার জন্য)। এসএসডি এবং সাটা ড্রাইভের ক্ষেত্রে, hddtemp এটি আপনাকে বর্তমান তাপমাত্রা দেখায়, ফলে আপনি এমন ইউনিটগুলি শনাক্ত করতে পারেন যেগুলির তাপমাত্রা নিষ্ক্রিয় অবস্থাতেও হঠাৎ বেড়ে যায়, যা নিম্নলিখিত ক্ষেত্রে উপযোগী... সার্ভার অপ্টিমাইজেশন.

লিনাক্সে বিশেষায়িত হার্ডওয়্যার ডায়াগনস্টিকস

সিপিইউ, র‍্যাম এবং ডিস্ক ছাড়াও, লিনাক্সে ইসিসি মেমোরি, নেটওয়ার্ক কার্ড, জিপিইউ এবং অন্যান্য কম্পোনেন্ট মূল্যায়নের জন্য নির্দিষ্ট টুল রয়েছে । এই বিষয়গুলো পরীক্ষা করতে কয়েক মিনিট সময় ব্যয় করলে তা আপনার ডিবাগিংয়ের বহু ঘণ্টা বাঁচিয়ে দিতে পারে।

আপনার সার্ভার বা ওয়ার্কস্টেশনে যদি ECC মেমরি থাকে , তাহলে কার্নেল সাধারণত EDAC ব্যবহার করে সংশোধিত এবং অসংশোধিত ত্রুটিগুলো লগ করে রাখে। একটি সহজ উদাহরণ হলো:

dmesg | grep EDAC

এর মাধ্যমে আপনি দেখতে পারবেন যে সেখানে CE (সংশোধিত ত্রুটি) বা UE (অসংশোধিত ত্রুটি) আছে কিনা । CE নির্দেশ করে যে RAM-এ ত্রুটি ছিল, কিন্তু হার্ডওয়্যার তা সংশোধন করতে সক্ষম হয়েছে; এই মডিউলগুলো পর্যবেক্ষণ করার পরামর্শ দেওয়া হয়, কারণ এগুলো অসংশোধনযোগ্য ত্রুটিতে পরিণত হওয়াটা সাধারণত শুধু সময়ের ব্যাপার। গুরুতর ডেটা বিকৃতি রোধ করতে UE-এর ফলে প্রায়শই কার্নেল প্যানিক ঘটে।

মেমোরির গঠন এবং ধারণক্ষমতা পরীক্ষা করার জন্য, `dmidecode -t memory` কমান্ডটি আপনাকে মডিউলের ধরন (DDR3, DDR4, DDR5), ধারণক্ষমতা, ব্যবহৃত ব্যাঙ্ক এবং আরও অনেক কিছু দেখায়। আর `dmidecode -t 16` কমান্ডের মাধ্যমে আপনি মাদারবোর্ড দ্বারা সমর্থিত সর্বোচ্চ র‍্যামের ধারণক্ষমতা দেখতে পারেন, যা আপগ্রেড করার কথা ভাবলে বেশ দরকারি।

তাপমাত্রা এবং দৃশ্যমান পর্যবেক্ষণের ক্ষেত্রে, আপনি psensor বা xsensors-এর মতো গ্রাফিক্যাল টুলের সাহায্যে সেন্সর এবং HDD-এর তাপমাত্রার ডেটা সমর্থন করতে পারেন , যা সময়ের সাথে সাথে তাপমাত্রার গ্রাফ তৈরি করে অস্বাভাবিক বৃদ্ধি বা ক্রমাগত সর্বোচ্চ তাপমাত্রায় থাকা সরঞ্জাম শনাক্ত করে।

ডিস্ক এবং ইউএসবি ড্রাইভ নির্ণয়ের জন্য , ডিভাইস তালিকাভুক্ত করতে lsblk এবং fdisk -l ব্যবহারের পাশাপাশি, নিম্নলিখিত পদ্ধতিগুলো একত্রিত করা খুবই উপকারী:

• df -h y df -iস্থান এবং আইনোড ব্যবহারের শতাংশ; আপনার কাছে গিগাবাইট খালি জায়গা থাকতে পারে কিন্তু ১০০% আইনোড ব্যবহৃত হলেও সিস্টেমটি "জায়গা নেই" বলে অভিযোগ করবে।
• fsck /dev/sdXN -yফাইল সিস্টেমে (অন্যান্যদের মধ্যে EXT2/3/4) যৌক্তিক ত্রুটি খুঁজে বের করে এবং সংশোধন করে।
• badblocks /dev/my_diskত্রুটিপূর্ণ সেক্টরগুলির জন্য স্ক্যান করে এবং সেগুলিকে চিহ্নিত করে, যাতে সিস্টেম সেগুলি ব্যবহার না করে (এটি করার আগে একটি ব্যাকআপ তৈরি করার জন্য দৃঢ়ভাবে সুপারিশ করা হয়)।

নেটওয়ার্ক কার্ডের ক্ষেত্রে , সাধারণ লক্ষণগুলোর মধ্যে রয়েছে সংযোগ বিচ্ছিন্ন হওয়া, লেটেন্সি বা ব্যাখ্যাতীত প্যাকেট লস। আপনি পরিসংখ্যান পর্যালোচনা করতে ethtool এবং প্যাকেট লসের হার (RX-DRP ও TX-DRP) পরীক্ষা করতে netstat ব্যবহার করতে পারেন । যদি প্যাকেট লসের হার প্রায় ০.২% ছাড়িয়ে যায় , তাহলে নেটওয়ার্কের পারফরম্যান্স স্পষ্টভাবে প্রভাবিত হয় এবং NIC-টি ত্রুটিপূর্ণ হতে পারে অথবা ড্রাইভার দ্বারা এটি সঠিকভাবে সমর্থিত নাও হতে পারে।

ডিস্ক পূর্ণ এবং স্থান সংক্রান্ত ত্রুটি: সেই চিরাচরিত “ডিভাইসে আর কোনো জায়গা নেই”

অনেক মেশিনে (বিশেষ করে সার্ভার এবং ভার্চুয়াল মেশিনে ) অন্যতম একটি সাধারণ সমস্যা হলো সিস্টেম ডিস্ক পুরোপুরি ভরে যাওয়া। এমনটা হলে সার্ভিস, লগ, বুট প্রসেস, এমনকি স্বয়ং কার্নেলও I/O এরর দেখাতে শুরু করে।

Azure-এর মতো পরিবেশে, কনসোলে বা স্টার্টআপ ডায়াগনস্টিক্সে এই ধরনের বার্তা দেখা যাওয়া সাধারণ ব্যাপার:

• যন্ত্রে আর কোন স্থান অবশিষ্ট নেই cloud-init-এর মধ্যে থাকা একটি ত্রুটি, যা VM-এর বুট প্রক্রিয়া সম্পন্ন হতে বাধা দিতে পারে।
• বারবার বার্তা পাঠানো হচ্ছে ডিভাইসটিতে আর কোনো জায়গা বাকি নেই। যেগুলো ক্লাউড এজেন্টসহ গুরুত্বপূর্ণ পরিষেবাগুলোকে প্রভাবিত করে।
• সিস্টেম লগে এমন ত্রুটি দেখা যাচ্ছে যা নির্দেশ করে যে অডিট বা নেটওয়ার্ক লগ লেখা সম্ভব নয়।

স্থানটিতে কী আছে তা দ্রুত খুঁজে বের করতে, আপনি নিম্নলিখিত কমান্ডগুলো ব্যবহার করতে পারেন:

• du -ks /* | sort -nআকার অনুসারে রুট ডিরেক্টরিগুলোর তালিকা দেখায়; আসলটি খুঁজে না পাওয়া পর্যন্ত সবচেয়ে ভারী ডিরেক্টরিগুলোর মধ্যে এটি পুনরাবৃত্তি করে।
• ls -altSr /var/log: লগ ফাইলগুলোকে আকার অনুযায়ী ছোট থেকে বড় ক্রমে সাজিয়ে দেখায়; আপনি প্রায়শই বিশাল আকারের পুরোনো লগ দেখতে পাবেন যেগুলো রোটেট বা ডিলিট করা যায়।
• find / -size +500M -exec ls -alFh {} \;বড় আকারের স্বতন্ত্র ফাইল অনুসন্ধান করুন; প্রয়োজন অনুযায়ী সেই ৫০০ মেগাবাইট সমন্বয় করুন।

সাধারণত /var/log বা /tmp ভরে যাওয়া ছাড়াও, কিছু নিরাপত্তা কনফিগারেশন রয়েছে, যেমন— নিরীক্ষা যার কারণে একটি মেশিন বন্ধ হয়ে যেতে পারে বা চালু হতে ব্যর্থ হতে পারে যখন /var/log/audit-এ জায়গা ফুরিয়ে যাচ্ছে। যদি থাকে /etc/audit/auditd.conf তোমার আছে:

admin_space_left_action = HALT
disk_full_action = HALT
disk_error_action = HALT

যদি সিস্টেমটি অডিট লগে লিখতে না পারে, তবে এটি একটি নিয়ন্ত্রিত পদ্ধতিতে বন্ধ হয়ে যেতে পারে অথবা বুট হতে অস্বীকার করতে পারে। একটি অস্থায়ী সমাধান হলো, সিস্টেমটিকে বুট হতে এবং জায়গা খালি করতে দেওয়ার জন্য ওই মানগুলিকে SUSPEND, IGNORE বা অন্য কোনো বৈধ বিকল্পে (এই প্রসঙ্গে কখনোই SINGLE নয়) পরিবর্তন করা। সমস্যাটি সমাধান করার পর, যদি নিয়ম মেনে চলার প্রয়োজন হয়, তবে আপনার মূল নীতিতে ফিরে যাওয়া উচিত।

যখন সিস্টেমটি বুটই হয় না এবং কোনো কিছু ডিলিট করার উপায় থাকে না, তখন আপনি রেসকিউ মোড ব্যবহার করতে পারেন : যেমন—অটোমেটিক ক্লাউড রিপেয়ার কমান্ড (উদাহরণস্বরূপ, Azure-এ az vm repair), রিকভারি ভার্চুয়াল মেশিন, অথবা সিঙ্গেল-ইউজার মোড। এর মাধ্যমে ডিস্ক মাউন্ট করে অপ্রয়োজনীয় ফাইলগুলো ডিলিট করতে পারেন, যতক্ষণ না /var/log এবং বাকি গুরুত্বপূর্ণ ডিরেক্টরিগুলো ধারণকারী ফাইল সিস্টেমে অন্তত ১০% খালি জায়গা তৈরি হয়।

ক্ষতিগ্রস্ত EXT4 এবং XFS: কীভাবে ক্ষতিগ্রস্ত ফাইল সিস্টেম মেরামত করবেন

স্টার্টআপের সময় যদি আপনি “EXT4-fs error (device sda1)” , “bad extra_isize” , “no journal found” অথবা “Metadata CRC error detected… Unmount and run xfs_repair”- এর মতো XFS মেসেজ দেখতে পান , তাহলে এটি কোনো বিচ্ছিন্ন সমস্যা নয়: ফাইল সিস্টেমটি করাপ্ট হয়ে গেছে এবং যতক্ষণ না আপনি এটি মেরামত করছেন, মেশিনটি স্বাভাবিকভাবে বুট হবে না।

প্রথম ধাপ হলো কোন ডিভাইসটি প্রভাবিত হয়েছে তা শনাক্ত করা । বুট লগে, কার্নেল মেসেজগুলোতে বন্ধনীর মধ্যে থাকা লেখাগুলো দেখুন: sda1, sdc1, dm-0, dm-2, /dev/mapper/vgname/lvname, ইত্যাদি। এটি আপনাকে বলে দেবে যে আপনি একটি ডাইরেক্ট পার্টিশন (sdXN) নিয়ে কাজ করছেন নাকি একটি LVM লজিক্যাল ভলিউম (dm-N, /dev/vgname/lvname) নিয়ে।

একবার আপনি একটি শেল (ইমার্জেন্সি মোড, সিঙ্গেল ইউজার, বা রেসকিউ মেশিন) অ্যাক্সেস পেলে, সম্পূর্ণ কাঠামো—ডিস্ক, পার্টিশন, LVM, এবং ফাইলসিস্টেমের ধরন—দেখার জন্য `lsblk -f` চালান। এখানে এটি নিশ্চিত করা খুব জরুরি যে ওই পার্টিশনটি আসলেই ext4, xfs, vfat, LVM2_member ইত্যাদি কি না, এবং যদি আপনার সন্দেহ হয় যে এটি ভুলভাবে কনফিগার করা হয়েছে, তবে শুধুমাত্র `/etc/fstab`-এর তথ্যের উপর নির্ভর করবেন না।

EXT4 ফাইল সিস্টেম মেরামত করতে fsck ব্যবহার করা হয় । সাধারণ নিয়ম অনুযায়ী:

• ফাইল সিস্টেমটি নিশ্চিত করুন আনমাউন্ট করা (যদি এটি একটি ডেটা ডিস্ক হয়) অথবা আপনি এমন একটি রেসকিউ এনভায়রনমেন্ট থেকে কাজ করছেন যেখানে এটি ব্যবহৃত হচ্ছে না।
• বর্শা fsck /dev/sdXN o fsck /dev/vgname/lvnameএটি আপনাকে জিজ্ঞাসা করবে যে আপনি অসঙ্গতি সংশোধন করতে, রিসাইজ আইনোড পুনরায় তৈরি করতে, ব্লক কাউন্টার সামঞ্জস্য করতে, ইত্যাদি চান কিনা।
• যদি অনেক প্রশ্ন আসে, তাহলে CTRL+C চেপে থামান এবং আবার চালান। fsck -y যাতে এটি স্বয়ংক্রিয়ভাবে 'হ্যাঁ' উত্তর দেয়; এতে আপনার কিছুই বাদ পড়বে না।
• আপনি যদি ফাইলগুলি সরান হারিয়ে যাওয়া + পাওয়া গেছেতোমাকে পরে সেগুলো পরীক্ষা করে যথাস্থানে ফিরিয়ে রাখতে হবে।
• আউটপুটে ফাইল সিস্টেমটি নির্দেশিত না হওয়া পর্যন্ত fsck আবার চালান। পরিষ্কার.

XFS- এর ক্ষেত্রে টুলটি হলো xfs_repair । এক্ষেত্রে সাধারণ কার্যপ্রবাহটি হলো:

• প্রথমে, একটি প্রাথমিক যাচাই: xfs_repair -n /dev/vgname/homelv কোনো কিছু পরিবর্তন না করে কী ক্ষতি হয়েছে তা দেখা।
• বিশ্লেষণটি যুক্তিসঙ্গত হলে, -n ছাড়া পুনরাবৃত্তি করুন যাতে এটি সংশোধন করার চেষ্টা করতে পারে: xfs_repair /dev/vgname/homelv.
• যদি কমান্ডটি অভিযোগ করে যে ফাইলসিস্টেমে "একটি জার্নালে মূল্যবান মেটাডেটা পরিবর্তন রয়েছে যা পুনরায় তৈরি করা প্রয়োজন," তবে এটি মাউন্ট করার চেষ্টা করুন: XFS সিস্টেমে, অনেক মুলতুবি থাকা পরিবর্তন ঠিক মাউন্ট করার সময়েই প্রয়োগ করা হয়। আপনি যদি একটি রেসকিউ ভিএম-এ থাকেন, তবে আপনি এটি একটি নির্দিষ্ট সময়ে করতে পারেন, যেমন /recovery.
• যদি অন্য কোনো উপায় না থাকে এবং জার্নালের ত্রুটিগুলো ঠিক করা না যায়, তাহলে শেষ উপায় হলো ব্যবহার করা xfs_repair -L জার্নালটি বাতিল করে অ্যাসেম্বলিটিকে এমনভাবে চালাতে হবে যেন সমস্ত পরিবর্তন প্রয়োগ করা হয়েছে। এর ফলে সাম্প্রতিক ডেটা হারিয়ে যেতে পারে, তাই এটি শুধুমাত্র শেষ উপায় হিসেবেই করুন।

সব ক্ষেত্রেই, এটা বোঝা অত্যন্ত জরুরি যে fsck এবং xfs_repair কোনো জাদু নয় : এগুলো ফাইল সিস্টেমের কাঠামো ঠিক করে, কিন্তু সবসময় সমস্ত ডেটা পুনরুদ্ধার করতে পারে না। একারণেই পূর্ববর্তী ব্যাকআপ থাকা অত্যন্ত গুরুত্বপূর্ণ এবং আপনি যদি ক্লাউড বা ভিএম-এ থাকেন, তবে ডিস্ক স্ন্যাপশট বা রেসকিউ মেশিনের সাথে সংযুক্ত একটি কপি থেকে কাজ করা জরুরি ।

GRUB, UEFI, Secure Boot এবং অন্যান্য ক্লাসিক বুট

যখন আপনি কম্পিউটার চালু করার পর GRUB মেনুটিও দেখতে পান না, অথবা BIOS/UEFI "Failed to open \EFI\ubuntu\grubx64.efi - Not found"- এর মতো ত্রুটি দেখায় এবং ওই এন্ট্রি থেকে বুট করার চেষ্টা করতে করতে একটি লুপে আটকে যায়, তখন সমস্যাটি প্রায় নিশ্চিতভাবেই বুট ম্যানেজার অথবা ফার্মওয়্যার কনফিগারেশনে রয়েছে ।

ডুয়াল-বুট কনফিগারেশনে উইন্ডোজ ইনস্টল করার পরে (যা প্রায়শই MBR দখল করে নেয় বা UEFI এন্ট্রি ওভাররাইট করে), ভুলবশত একটি EFI পার্টিশন মুছে ফেলার পরে, অথবা BIOS-এ বুট অর্ডার পরিবর্তন করার পরে এই ত্রুটিগুলি ঘটতে পারে। আধুনিক ল্যাপটপগুলিতে, যদি "ubuntu" নামক UEFI এন্ট্রিটি এমন একটি ফাইলকে নির্দেশ করে যা আর বিদ্যমান নেই এবং সেটিকে লোড করার চেষ্টা করে, তবে মেশিনটি একটি লুপের মধ্যে রিবুট হতে থাকাটা অস্বাভাবিক নয়।

একটি নষ্ট GRUB বুটলোডার মেরামত করার সবচেয়ে সহজ উপায় হলো একটি লাইভ ডিস্ট্রিবিউশন (যেমন, উবুন্টু) থেকে বুট করা এবং বুট-রিপেয়ার টুলটি ব্যবহার করা । এর সাধারণ পদ্ধতিটি হলো:

• একটি থেকে শুরু করুন ইউএসবি লাইভ এবং একটি টার্মিনাল খুলুন।
• রিপোজিটরি যোগ করুন এবং আপডেট করুন: sudo apt-add-repository ppa:yannubuntu/boot-repair && sudo apt update.
• টুল ইনস্টল করুন: sudo apt install -y boot-repair.
• এটা দিয়ে চালান boot-repair এবং বিকল্পটি নির্বাচন করুন "প্রস্তাবিত মেরামত".

বুট-রিপেয়ার পার্টিশন বিশ্লেষণ করে, ইনস্টল করা সিস্টেমগুলো সনাক্ত করে, GRUB পুনঃকনফিগার করে, কনফিগারেশন ফাইল পুনর্গঠন করে এবং প্রয়োজনে UEFI এন্ট্রিগুলো সমন্বয় করে, যাতে কম্পিউটারটি উপযুক্ত বুট ম্যানেজার থেকে বুট করে।

যেসব সিস্টেমে UEFI, Secure Boot, এবং Fast Boot সক্রিয় করা আছে, সেখানে বেশ কিছু অসঙ্গতি রয়েছে যা সম্পর্কে সচেতন থাকা প্রয়োজন। সব ডিস্ট্রিবিউশন Secure Boot সঠিকভাবে সমর্থন করে না, এবং পুরোনো হার্ডওয়্যারের জন্য ডিজাইন করা কিছু ডিস্ট্রিবিউশন UEFI-এর সাথে ঠিকমতো কাজও করে না। যদি আপনার ডিস্ট্রিবিউশনটি আনসাইনড (unsigned) হয় অথবা বুট শিমটি (boot shim) অসঙ্গতিপূর্ণ হয়, তাহলে UEFI কার্নেল লোড করতে অস্বীকার করতে পারে।

এইসব ক্ষেত্রে, সমাধানটি সাধারণত UEFI সেটিংসে গিয়ে, ক্লাসিক BIOS-স্টাইলের বুটিংয়ের জন্য Legacy/CSM মোড চালু করা এবং Secure Boot নিষ্ক্রিয় করার মাধ্যমে করা হয় । তবে, যদি আপনি সেই কম্পিউটারে Windows 11-ও ব্যবহার করেন অথবা Windows থেকে Linux-এ মাইগ্রেট করতে চান , তাহলে Secure Boot নিষ্ক্রিয় করলে Windows-এর বুটের প্রয়োজনীয়তাগুলো ভেঙে যেতে পারে। তাই, কোন সিস্টেমটি অগ্রাধিকার পাবে তা আপনার বিবেচনা করা উচিত অথবা Secure Boot-এর সাথে সামঞ্জস্যপূর্ণ কোনো Linux ডিস্ট্রিবিউশন খোঁজা উচিত, যাতে প্রতিবার BIOS-এ প্রবেশ করার ঝামেলা এড়ানো যায়।

ডুয়াল-বুট পরিস্থিতিতেও উইন্ডোজ ফাস্ট বুট সমস্যা সৃষ্টি করে। ফাস্ট বুট চালু থাকা অবস্থায় শাটডাউন করলে, উইন্ডোজ পুরোপুরি বন্ধ হয় না: এটি কার্নেলের একটি অংশকে ডিস্কে হাইবারনেট অবস্থায় রেখে দেয়, যা NTFS ফাইল সিস্টেমে সম্পূর্ণ অ্যাক্সেসকে বাধা দেয়। যখন লিনাক্স এই পার্টিশনগুলো মাউন্ট করার চেষ্টা করে, তখন ত্রুটি দেখা দিতে পারে বা সিস্টেমটি এমনকি ফ্রিজও হয়ে যেতে পারে। উইন্ডোজ পাওয়ার অপশন এবং, যদি আপনার UEFI অনুমতি দেয়, তবে সরাসরি BIOS-এ ফাস্ট বুট নিষ্ক্রিয় করার পরামর্শ দেওয়া হয়।

রিকভারি মোড এবং বিল্ট-ইন রিপেয়ার টুলের ব্যবহার

যদি GRUB দেখা যায় কিন্তু আপনার লিনাক্স সিস্টেম বুট করতে ব্যর্থ হয়, অথবা যদি আপনার সন্দেহ হয় যে কোনো প্যাকেজ অসম্পূর্ণ রয়ে গেছে বা কোনো আপডেটের পরে সিস্টেমটি ক্ষতিগ্রস্ত হয়েছে, তাহলে আপনি GRUB-এর অ্যাডভান্সড অপশন এবং বেশিরভাগ ডিস্ট্রিবিউশনে অন্তর্ভুক্ত রিকভারি মোডগুলোর সুবিধা নিতে পারেন।

GRUB মেনুতে সাধারণত " Advanced options " বা এই ধরনের কোনো একটি এন্ট্রি থাকে। এর ভেতরে, আপনি সাধারণত সমস্ত উপলব্ধ কার্নেল সংস্করণ এবং প্রতিটির জন্য একটি রিকভারি মোড দেখতে পাবেন । সর্বশেষ সংস্করণের জন্য রিকভারি মোডটি নির্বাচন করুন (এবং যদি সেটি ব্যর্থ হয়, তবে আগেরটি চেষ্টা করুন)।

রিকভারি মোড আপনাকে খুব দরকারি কিছু ইউটিলিটির একটি মেনু দেখায়, যেমন:

• fsckফাইল সিস্টেম পরীক্ষা ও মেরামত করুন (উইন্ডোজের chkdsk-এর অনুরূপ)।
• পরিষ্কারটেম্পোরারি ফাইল এবং অন্যান্য অবশিষ্ট ফাইল মুছে দিয়ে জায়গা খালি করুন।
• dpkgত্রুটিপূর্ণ প্যাকেজ, অপূরিত নির্ভরতা, বা আটকে থাকা ইনস্টলেশন ঠিক করুন।
• কীড়াবুট ম্যানেজার কনফিগারেশন পুনরায় তৈরি করুন।

এই অপশনগুলো ক্রমানুসারে চালালে সাধারণত আপডেটের সময় বিদ্যুৎ বিভ্রাট, ত্রুটিপূর্ণ প্যাকেজ, বা ডিস্ক ভরে যাওয়ার কারণে সৃষ্ট অনেক সমস্যার সমাধান হয়ে যায় । এরপর, বুট প্রক্রিয়া স্বাভাবিক অবস্থায় ফিরে এসেছে কিনা তা পরীক্ষা করার জন্য সিস্টেমটি সাধারণত রিস্টার্ট করার প্রস্তাব দেবে।

Azure-এর মতো ক্লাউডে , ইমার্জেন্সি এবং সিঙ্গেল-ইউজার মোড ছাড়াও, Azure Linux Automatic Repair (ALAR) এবং az vm repair কমান্ডের মতো নির্দিষ্ট কিছু টুল রয়েছে , যা প্রক্রিয়ার একটি অংশকে স্বয়ংক্রিয় করে তোলে: এগুলো একটি রেসকিউ ভিএম-এ সিস্টেম ডিস্ক মাউন্ট করে, সাধারণ কনফিগারেশন ঠিক করার জন্য “auditd”-এর মতো অ্যাকশন চালায়, এবং কোনো সমস্যা হলে আপনাকে সহজেই আগের অবস্থায় ফিরে যাওয়ার সুযোগ দেয়।

ডেটা না হারিয়ে লিনাক্স পুনরায় ইনস্টল করার কৌশল

এমন পরিস্থিতিও আসে যেখানে, আপনি যতই তদন্ত করুন না কেন, সিস্টেমটি এতটাই ত্রুটিপূর্ণ থাকে অথবা আপনার হার্ডওয়্যারটি এতটাই অস্বাভাবিক হয় (যেমন সেই HP N150 বা বিশেষ ধরনের কন্ট্রোলারযুক্ত আধুনিক ল্যাপটপ), যে ডিস্ট্রোটি পুনরায় ইনস্টল করাই সবচেয়ে বুদ্ধিমানের কাজ । তবে, এর মানে এই নয় যে আপনাকে আপনার সমস্ত ডেটা হারাতে হবে।

উবুন্টু এবং এর থেকে উদ্ভূত সংস্করণগুলোর মতো অনেক ডিস্ট্রিবিউশন ইনস্টলেশনের সময় "ডকুমেন্ট ও সেটিংস অক্ষুণ্ণ রেখে অপারেটিং সিস্টেম পুনরায় ইনস্টল করুন " নামে একটি বিকল্প দিয়ে থাকে। এটি মূল সিস্টেমটি পুনরায় ইনস্টল করে, কিন্তু আপনার /home ডিরেক্টরি এবং কখনও কখনও কিছু ইনস্টল করা অ্যাপ্লিকেশনও অক্ষুণ্ণ রাখার চেষ্টা করে। এটি একটি সুবিধাজনক বিকল্প হলেও, সম্পূর্ণ নিরাপদ নয়, তাই আপনি যা কিছু হারাতে চান না, তা ম্যানুয়ালি ব্যাক আপ করে রাখা বাঞ্ছনীয় ।

ভবিষ্যতে পুনরায় ইনস্টলেশন রোধ করার সবচেয়ে শক্তিশালী উপায় হলো ডিস্কটিকে কয়েকটি পৃথক পার্টিশনে বিভক্ত করে রাখা ।

• একটির জন্য / (মূল): ভিত্তি ব্যবস্থা।
• আরও একটির জন্য / বুট (এবং UEFI-তে /boot/efi) যদি আপনি বুটিংয়ের উপর আরও বেশি নিয়ন্ত্রণ চান।
• একটি বিশেষ বিভাগের জন্য / হোম অথবা ডেটার জন্য।

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

ভার্চুয়াল মেশিনে, তা VirtualBox, VMware বা ক্লাউড থেকেই হোক না কেন, ডেটা ডিস্ককে সিস্টেম ডিস্ক থেকে আলাদা রাখা একটি ভালো অভ্যাস । উদাহরণস্বরূপ, Azure-এ এই পরামর্শ দেওয়া হয় যে LVM ডেটা ভলিউমগুলোকে সিস্টেম ডিস্কের সাথে একই ভলিউম গ্রুপে রাখা উচিত নয়, যাতে OS ব্যর্থতার কারণে ডেটাও ক্ষতিগ্রস্ত না হয়।

সমস্যা পুনরায় দেখা দেওয়া প্রতিরোধের সর্বোত্তম উপায়

একবার আপনি বুট সমস্যার সমাধান করে আপনার সিস্টেম (বা অন্তত আপনার ডেটা) পুনরুদ্ধার করে ফেললে, বুদ্ধিমানের কাজ হলো পরেরবার যাতে এই ধরনের বিপদ কম গুরুতর হয় বা এটি যাতে পুরোপুরি না ঘটে, তার জন্য কিছু পদক্ষেপ নেওয়া।

প্রথমত, আপনার সিস্টেম এবং সফটওয়্যার হালনাগাদ রাখুন , তবে তা বিচক্ষণতার সাথে করুন। আর্চের মতো রোলিং রিলিজ ডিস্ট্রিবিউশনগুলোতে ঘন ঘন আপডেট অপরিহার্য; তুলনামূলকভাবে রক্ষণশীল ডিস্ট্রিবিউশনগুলোতে (ডেবিয়ান স্টেবল, উবুন্টু এলটিএস) আপনি আপডেটের মধ্যে কিছুটা ব্যবধান রাখতে পারেন, কিন্তু বছরের পর বছর ধরে সেগুলোকে অপরিবর্তিত রাখা বুদ্ধিমানের কাজ নয়। বড় ধরনের কার্নেল বা ভার্সন পরিবর্তনের আগে, সর্বদা একটি ভালো মানের ব্যাকআপ তৈরি করে নিন।

আরেকটি খুব স্বাস্থ্যকর অভ্যাস হলো যেকোনো বড় কনফিগারেশন পরিবর্তন নথিভুক্ত করুন।আপনি কোন ফাইলটিতে হাত দিয়েছেন, কোন লাইনটি পরিবর্তন করেছেন এবং আগে ফাইলটি কেমন ছিল। একটি সহজ কৌশল হলো, মূল ফাইলটির একটি অনুলিপি সবসময় সাফিক্স (suffix) দিয়ে সংরক্ষণ করা। .bak (উদাহরণস্বরূপ, sshd_config.bakযাতে কোনো ভুল হয়ে গেলেও আপনি সহজেই তা ঠিক করে নিতে পারেন।

ডেটার ক্ষেত্রে, নিয়মিত ব্যাকআপ অপরিহার্য । আপনি ইনক্রিমেন্টাল ব্যাকআপের জন্য rsync, সম্পূর্ণ ডিরেক্টরি প্যাকেজ করার জন্য tar, অথবা ক্লাউড এবং NAS সলিউশন ব্যবহার করতে পারেন। এছাড়াও, যদি আপনার ডেটা সিস্টেম পার্টিশন থেকে ভিন্ন কোনো পার্টিশনে থাকে, তাহলে ডিস্ক বুট না করলেও আপনি তেমন কোনো ঝামেলা ছাড়াই পুনরায় ইনস্টল করতে পারবেন।

অবশেষে, নিয়মিত সিস্টেমের স্বাস্থ্য পর্যবেক্ষণ করা সর্বদা একটি ভালো অভ্যাস: প্রতি মাসে SMART চেক করুন, গুরুত্বপূর্ণ পার্টিশনগুলিতে (/, /var, /home) ইনোড এবং খালি জায়গা নিরীক্ষণ করুন , পুনরাবৃত্তিমূলক বার্তার জন্য লগগুলি দেখুন, এবং ভৌত সরঞ্জামগুলিতে তাপমাত্রা ও ধুলার মাত্রা কম রাখুন। একটি সাধারণ রক্ষণাবেক্ষণ রুটিন এমন মেশিন ঠিক করার জন্য অনেক ভোরের সময় বাঁচিয়ে দেয়, যেগুলো "হঠাৎ" বুট হওয়া বন্ধ করে দিয়েছে।

বিভিন্ন কৌশল, কমান্ড এবং সেরা অনুশীলনের এই সম্ভারের সাহায্যে, লিনাক্সে বুট সমস্যা এবং হার্ডওয়্যার ত্রুটি নির্ণয় ও মেরামত করা আর কোনো অন্ধ বিশ্বাসের বিষয় থাকে না, বরং এটি একটি বেশ যুক্তিসঙ্গত প্রক্রিয়ায় পরিণত হয়: প্রথমে, আপনি শনাক্ত করেন যে সমস্যাটি ডিস্ক, ফাইল সিস্টেম, GRUB, কার্নেল, কনফিগারেশন, নাকি হার্ডওয়্যারের কারণে হচ্ছে; তারপর আপনি উপযুক্ত টুলটি প্রয়োগ করেন (যেমন fsck, xfs_repair, Boot-Repair, smartctl, MemTest, রিকভারি মোড ইত্যাদি); এবং সবচেয়ে খারাপ পরিস্থিতিতে, আপনার কাছে আলাদা পার্টিশন ও ব্যাকআপসহ একটি সুসংগঠিত বিকল্প পরিকল্পনা (Plan B) থাকে, যা আপনাকে কোনো বড় ধরনের ঝামেলা ছাড়াই পুনরায় ইনস্টল করার সুযোগ দেয়।