Skip to content
VDS · समस्या निवारण

कर्नेल क्रैश: kernel panic और उसके बाद

जब मशीन बूट ही न हो और स्क्रीन पर कर्नेल का मैसेज अटका हो तो क्या करें: एरर टेक्स्ट कैप्चर करें, कर्नेल रोल बैक करें, और recovery डिस्क से fstab ठीक करें।

23 अगस्त 2026 को अपडेट किया गया

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

चरण 1. संदेश पढ़ें

/hosting/vds/m/<id> खोलें, “Console” टैब, “Screen” व्यू (VNC)। टेक्स्ट कंसोल भी कर्नल का आउटपुट दिखाता है, लेकिन पैनिक अक्सर ग्राफ़िकल बफ़र पर बनता है, और “Screen” पर यह ज़्यादा भरोसे के साथ दिखता है। मायने पहली लाइन का नहीं, सबसे नीचे वाली काम की लाइन का है, आम तौर पर इनमें से एक:

  • VFS: Unable to mount root fs on unknown-block(0,0) — कर्नल को रूट पार्टीशन नहीं मिला;
  • Kernel panic - not syncing: Attempted to kill init — प्रोसेस नंबर एक मर गया, ज़्यादातर फेल हुए अपडेट के बाद खराब हुए /sbin/init की वजह से;
  • Kernel panic - not syncing: No working init found — वही समस्या;
  • स्टैक ट्रेस के साथ ड्राइवर एरर — आम तौर पर थर्ड-पार्टी कर्नल मॉड्यूल इंस्टॉल करने के बाद।

फ़ौरन फ़ोटो लें या टेक्स्ट कॉपी करें: रीबूट के बाद स्क्रीन साफ़ हो जाएगी।

चरण 2. पिछला कर्नल आज़माएँ

अगर पैनिक अपडेट के ठीक बाद आया है, तो GRUB में पुराना कर्नल मौजूद है। पैनल से मशीन रीबूट करें और “Screen” पर मेन्यू पकड़ें: पहले कुछ सेकंड में Shift या Esc दबाएँ, फिर “Advanced options” और पिछला वर्शन चुनें।

पुराने कर्नल से बूट हो जाने के बाद काम करने वाली स्थिति पक्की करें और नए पैकेज से निपटें:

uname -r
dpkg -l | grep linux-image
apt install --reinstall linux-image-amd64

चरण 3. रिकवरी डिस्क

अगर बूटलोडर मेन्यू नहीं दिखता या पुराना कर्नल भी क्रैश हो जाता है, तो “Access” टैब पर “SystemRescue recovery disk” बूट मोड चालू करें और मशीन रीबूट करें। बिना पासवर्ड के root से लॉगिन करें; मशीन की डिस्क /dev/sda के रूप में दिखेगी।

lsblk
mount /dev/sda1 /mnt
ls /mnt

अगर खराबी का शक हो तो फ़ाइल सिस्टम जाँचें:

umount /mnt
fsck -f /dev/sda1

मैन्युअल बदलावों के बाद पैनिक का आम कारण /etc/fstab में गलती है: किसी ऐसे पार्टीशन वाली लाइन जो मौजूद ही नहीं, या गलत UUID बूट को रोक देती है। इसे जाँचें:

blkid /dev/sda1
cat /mnt/etc/fstab

सिस्टम के अंदर काम करने के लिए (कर्नल दोबारा इंस्टॉल करना, बूटलोडर एडिट करना), chroot के ज़रिए उसमें जाएँ:

mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt /bin/bash

काम पूरा होने पर “Access” टैब पर वापस सामान्य बूट मोड पर स्विच करना न भूलें। वरना हर रीबूट पर मशीन SystemRescue में बूट होगी, और आपको लगेगा कि सिस्टम कभी उठा ही नहीं।

चरण 4. जब दोबारा इंस्टॉल करना आसान हो

हमारे पास मशीन के ऑटोमैटिक बैकअप या स्टेट स्नैपशॉट नहीं हैं, इसलिए फ़ैसला आपका है। अगर डिस्क पर कीमती डेटा है, तो पहले उसे SystemRescue से scp के ज़रिए अपनी मशीन पर कॉपी करें, और उसके बाद ही “Access” टैब से OS रीइंस्टॉल शुरू करें — यह डिस्क को पूरी तरह मिटा देता है।

क्रम यह है: डेटा कॉपी करें, पक्का करें कि वह आपकी तरफ़ पढ़ा जा रहा है, रीइंस्टॉल करें। रीइंस्टॉल के बाद वापस जाने का रास्ता नहीं होता।

इसे दोबारा होने से कैसे बचें

अपने डेटा की कॉपी मशीन के बाहर रखें, कर्नल को बाकी पैकेजों से अलग अपडेट करें, और अपडेट के ठीक बाद रीबूट करें — इस तरह किसी समस्या के बारे में आप सुविधाजनक समय पर जानेंगे, महीने बाद किसी अनजाने रीबूट के दौरान नहीं। आम सर्विस फेल होने की ट्रबलशूटिंग के लिए देखें Service won't start: systemd troubleshooting।