Kernel update के बाद VPS बूट न होने पर क्या करें

kernel update के बाद VPS बूट न होने पर सबसे पहले क्या करें

kernel update के बाद यदि VPS बूट नहीं हो रहा है, तो इसे आमतौर पर कुछ ही मिनटों में ठीक किया जा सकता है, क्योंकि update ने उस kernel को डिलीट नहीं किया है जो कल तक काम कर रहा था। Ubuntu नए kernel को पुराने के साथ ही install करता है और केवल यह बदलता है कि GRUB डिफ़ॉल्ट रूप से कौन सी entry start करेगा। इसलिए पहला कदम repair नहीं है। बूट मेनू में पिछले kernel को चुनें, login prompt वापस प्राप्त करें, और फिर चल रहे सिस्टम से diagnose करें।

सर्वर पर इसे ठीक करना लैपटॉप को ठीक करने से अलग है, क्योंकि कोई कीबोर्ड जुड़ा नहीं होता और कोई मॉनिटर panic नहीं दिखाता है। SSH भी जवाब नहीं देगा, क्योंकि मशीन उस बिंदु तक कभी नहीं पहुँची जहाँ sshd start होता है। नीचे दी गई हर चीज़ आपके प्रदाता के console के माध्यम से होती है।

कुछ भी बदलने से पहले अपने console को पढ़ें। उस स्क्रीन पर मौजूद टेक्स्ट यह तय करता है कि आप किस failure class में हैं, और दो सर्वर जो दोनों "बूट नहीं होंगे" उन्हें विपरीत सुधारों की आवश्यकता हो सकती है।

जब SSH काम न कर रहा हो, तो console तक कैसे पहुँचें?

अपने provider के control panel को खोलें और console का विकल्प ढूँढें। इसके सामान्य नाम VNC console, web console, noVNC और serial console हैं। यदि दोनों उपलब्ध हों, तो serial console को प्राथमिकता दें, क्योंकि यह आपको वास्तविक टेक्स्ट देता है जिसे आप scroll और copy कर सकते हैं, जबकि VNC view केवल स्क्रीन की एक तस्वीर होती है। इस विकल्प को अभी ढूँढ लें, जब मशीन ठीक से काम कर रही हो, और सुनिश्चित करें कि यह खुल रहा है। outage के दौरान इसे ढूँढने में आपका वह धैर्य खत्म हो सकता है जिसकी आपको आवश्यकता है। यह जाँच नए VPS पर पहले दस मिनट के कार्यों में शामिल होनी चाहिए, firewall rules और SSH keys के साथ।

अधिकांश panels rescue mode या recovery image की सुविधा भी देते हैं। यह provider के network से एक छोटा system boot करता है और आपकी disk को एक अतिरिक्त device के रूप में attach कर देता है, ताकि आपकी disk पर मौजूद कोई भी चीज़ run न हो। Rescue mode तब काम आता है जब GRUB ही खराब हो गया हो, और इसी तरीके से आप उस server से data copy कर सकते हैं जिसे आप अब नहीं रखना चाहते।

Boot menu तक पहुँचने के लिए आपको आमतौर पर panel से hard reset की आवश्यकता होगी, क्योंकि जिस मशीन में आप login नहीं कर सकते, उसमें आप sudo reboot नहीं चला सकते। Hard reset का मतलब बिजली काटना है। Filesystems का shutdown unclean होता है, इसलिए अगली बार boot होने पर filesystem check की अपेक्षा रखें।

GRUB menu में पुराना kernel कैसे चुनें?

Reset बटन दबाने के तुरंत बाद console पर नज़र रखें। शुरुआती कुछ सेकंड के दौरान बार-बार Esc दबाएं, या यदि मशीन legacy BIOS mode में boot होती है तो Shift को दबाकर रखें। यह समय बहुत कम होता है और console viewer को connect होने में अक्सर एक सेकंड लग जाता है, इसलिए जल्दी दबाना शुरू करें और दबाते रहें।

जब menu दिखाई दे, तो "Advanced options for Ubuntu" चुनें। वह submenu हर installed kernel को दिखाता है, जिसमें सबसे नया सबसे ऊपर होता है, और हर एक के लिए एक recovery mode entry भी होती है। दूसरी सामान्य entry चुनें, जो सबसे नए kernel के ठीक नीचे वाला kernel है, और Enter दबाएं। Recovery mode एक अलग चीज़ है: यह एक minimal single user system में boot होता है, और यह मरम्मत के काम के लिए है, न कि आपकी services को वापस online लाने के लिए।

यदि पुराना kernel boot हो जाता है, तो आपका सर्वर फिर से चल पड़ेगा। पुष्टि करें कि आप किस kernel पर हैं और उन numbers को लिख लें।

uname -r
dpkg -l 'linux-image-*' | grep '^ii'

dpkg का output आपके installed kernels की सूची है। यदि इसमें केवल एक ही line है, तो आपके पास कोई fallback नहीं है, और इसे ठीक करना आपकी पहली प्राथमिकता होनी चाहिए।

GRUB menu कभी दिखाई नहीं देता। अब क्या करें?

Cloud images में एक ऐसी config होती है जो menu को छिपा देती है। Ubuntu images आमतौर पर /etc/default/grub.d/ के अंतर्गत एक फ़ाइल में timeout को 0 पर सेट करती हैं, इसलिए सबसे नया kernel तुरंत शुरू हो जाता है और दबाने के लिए कुछ भी नहीं बचता।

इसका उल्टा मामला भी होता है, जहाँ menu स्क्रीन पर होता है और इंतज़ार कर रहा होता है, और यह ऐसा लगता है जैसे सिस्टम hang हो गया हो। GRUB एक failed boot को रिकॉर्ड करता है, और अगली बार शुरू होने पर यह menu को तब तक खुला रख सकता है जब तक कोई key न दबाई जाए। बिना keyboard वाले box पर, वह इंतज़ार कभी खत्म नहीं होता। यदि आपके console पर menu दिखाई दे रहा है और कुछ भी आगे नहीं बढ़ रहा है, तो यही हुआ है। एक entry चुनें और आगे बढ़ें।

मशीन के ठीक रहने पर ही दोनों को ठीक करें। /etc/default/grub को edit करें:

GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=10
GRUB_RECORDFAIL_TIMEOUT=10
GRUB_TERMINAL="console serial"
GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200"
GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0,115200"

फिर इसे apply करें और जाँचें कि आपका edit सुरक्षित है या नहीं, क्योंकि /etc/default/grub.d/ की फ़ाइलें /etc/default/grub के बाद पढ़ी जाती हैं और आपके बदलावों को override कर सकती हैं।

sudo update-grub
grep -rE 'TIMEOUT|TERMINAL' /etc/default/grub /etc/default/grub.d/

GRUB_TERMINAL="console serial" menu को graphical console और serial port पर भेजता है, ताकि यह उस viewer में दिखाई दे जो आपका panel आपको देता है। console= kernel arguments बाद में आने वाले boot messages के लिए भी यही काम करते हैं। प्रति boot दस सेकंड की देरी उस menu के लिए एक छोटी कीमत है जिसे आप रात के 2 बजे भी access कर सकते हैं।

मैं किस प्रकार की विफलता (failure class) देख रहा हूँ?

कंसोल के रुकने से पहले की अंतिम बीस पंक्तियों को पढ़ें। कर्नल अपडेट के बाद होने वाली अधिकांश समस्याओं को चार श्रेणियों में बांटा जा सकता है।

GRUB अपनी फाइलें नहीं ढूंढ पा रहा है। आपको एक grub rescue> प्रॉम्प्ट मिलता है, या किसी ऐसी पार्टीशन या फाइल के बारे में त्रुटि मिलती है जो मौजूद नहीं है, और कोई भी कर्नल संदेश दिखाई नहीं देता है। कर्नल अभी तक सक्रिय नहीं हुआ है। यह समस्या डिस्क या पार्टीशन में बदलाव के बाद, या बूटलोडर के गलत डिवाइस पर लिखे जाने के कारण होती है, न कि केवल कर्नल पैकेज के कारण।

कर्नल शुरू होता है लेकिन रूट (root) को माउंट नहीं कर पाता है। कर्नल संदेश स्क्रॉल होते हैं, फिर आप एक busybox शेल में पहुँच जाते हैं जिसका प्रॉम्प्ट (initramfs) है, या बूट प्रक्रिया रूट फाइलसिस्टम को माउंट करने में असमर्थ होने के कारण पैनिक (panic) में समाप्त हो जाती है। कर्नल लोड हो गया है। initramfs, जो कि एक छोटा अस्थायी रूट है और आपके वास्तविक रूट फाइलसिस्टम को ढूंढकर माउंट करता है, उसे डिस्क नहीं मिली। Ubuntu पर इस शेल से पहले आमतौर पर रूट डिवाइस के लिए प्रतीक्षा करने और उसे न ढूंढ पाने का संदेश आता है, जिसमें वह UUID भी होता है जिसे वह ढूंढ रहा था। उस UUID को कॉपी करें और बाद में blkid आउटपुट के साथ उसकी तुलना करें।

लॉजिकल वॉल्यूम (logical volume) कभी दिखाई नहीं देता है। यह पिछली श्रेणी जैसी ही है लेकिन इसका एक विशिष्ट कारण है। (initramfs) प्रॉम्प्ट पर, ls /dev/mapper चलाएं। यदि एकमात्र प्रविष्टि control है, तो इसका मतलब है कि कोई भी LVM (logical volume manager) वॉल्यूम सक्रिय नहीं हुआ है, इसलिए रूट डिवाइस अभी मौजूद नहीं है। वॉल्यूम ग्रुप्स को मैन्युअल रूप से सक्रिय करें:

lvm vgchange -ay
ls /dev/mapper
exit

exit नियंत्रण को वापस initramfs स्क्रिप्ट को सौंप देता है, जो माउंट करने का पुनः प्रयास करती है। यदि सिस्टम इसके बाद बूट हो जाता है, तो इसका मतलब है कि नए initramfs में LVM के हिस्से गायब हैं। इस स्थिति में सुधार के लिए कर्नल को बदलने के बजाय उस इमेज को फिर से बनाना (rebuild) आवश्यक है।

Linux से कुछ भी नहीं दिख रहा है। कंसोल पर फर्मवेयर टेक्स्ट, एक UEFI (unified extensible firmware interface) शेल, बिना कर्नल आउटपुट वाली खाली स्क्रीन, या रीसेट लूप दिखाई देता है। विफलता Linux के चलने से पहले ही हो रही है। सिस्टम के वापस आने पर जांचें कि आपका सर्वर वास्तव में किस मोड का उपयोग करता है, क्योंकि कई VPS इंस्टेंस legacy BIOS मोड में बूट होते हैं और EFI पाथ का उपयोग नहीं करते हैं:

[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
mountpoint /boot/efi
sudo efibootmgr -v

अपग्रेड के दौरान एक अनमाउंटेड /boot/efi UEFI मशीनों पर एक सामान्य कारण है, क्योंकि EFI सिस्टम पार्टीशन को बनाए रखने वाले पैकेज तब एक सामान्य खाली डायरेक्टरी में लिख देते हैं। फर्मवेयर पुरानी बूट प्रविष्टि को तब तक शुरू करता रहता है जब तक कि वह प्रविष्टि डिस्क पर मौजूद डेटा से मेल खाना बंद नहीं कर देती।

एक और पैटर्न बूट विफलता नहीं है। यदि आप एक रूट शेल तक पहुँचते हैं जो कहता है कि सिस्टम इमरजेंसी मोड में है, तो इसका मतलब है कि कर्नल बूट हो गया है लेकिन यूजरस्पेस रुक गया है। इसका आमतौर पर मतलब है कि /etc/fstab में कोई गलत लाइन है या फाइलसिस्टम अपनी जांच में विफल रहा है। उस शेल में journalctl -xb चलाएं और उस यूनिट का नाम पढ़ें जो विफल रही है।

क्या kernel package खराब है, या initramfs?

console से ये दोनों एक जैसे दिखते हैं और इनके लिए अलग-अलग सुधार की आवश्यकता होती है। पुराने kernel को boot करें, फिर files की तुलना करें।

ls -l /boot/vmlinuz-* /boot/initrd.img-*
df -h /boot

आपको हर installed version के लिए एक vmlinuz- और एक मेल खाता initrd.img- चाहिए, जिनमें से प्रत्येक का आकार उचित हो। एक missing initrd, या अपने पड़ोसियों की तुलना में बहुत छोटा initrd, का मतलब है कि initramfs generation विफल रहा है। इसका सामान्य कारण /boot का भर जाना है, और इसका प्रमाण package logs में मिलता है:

sudo grep -iE 'no space|update-initramfs' /var/log/apt/term.log
sudo tail -n 40 /var/log/apt/history.log

history.log यह भी सूचीबद्ध करता है कि पिछली बार किन packages को कब install किया गया था, जो इस बारे में किसी भी बहस को सुलझा देता है कि क्या बदला गया है।

यदि /boot भर गया है तो पहले खाली स्थान बनाएँ, फिर उस version के लिए image को rebuild करें जिसकी आपको आवश्यकता है और menu को refresh करें। अपने स्वयं के ls output से version string लें, क्योंकि नीचे दिया गया placeholder वास्तविक release नहीं है:

KVER=6.8.0-XX-generic
sudo update-initramfs -c -k "$KVER"
sudo update-grub
ls -l /boot/initrd.img-$KVER

वह अंतिम ls जाँच है। सामान्य आकार की file का मतलब है कि image अब वहाँ मौजूद है। यदि इसके बजाय kernel image ही क्षतिग्रस्त है, या dpkg -l package को ii के अलावा किसी अन्य स्थिति में दिखाता है, तो package को reinstall करें:

sudo apt install --reinstall linux-image-$KVER
sudo dpkg --configure -a

जब कोई kernel बूट न हो तो rescue mode से मरम्मत करना

यदि बूट मेनू की सभी प्रविष्टियाँ विफल हो जाती हैं, तो provider की rescue image से बूट करें और डिस्क को बाहर से ठीक करें। आपकी डिस्क एक unmounted device के रूप में दिखाई देगी, इसलिए उस पर कुछ भी चल नहीं रहा होगा और कोई प्रक्रिया आपके काम में बाधा नहीं डालेगी।

sudo lsblk -f
sudo vgchange -ay
sudo mount /dev/ubuntu-vg/ubuntu-lv /mnt
sudo mount /dev/vda2 /mnt/boot
sudo mount /dev/vda1 /mnt/boot/efi

for d in dev proc sys run; do sudo mount --rbind /$d /mnt/$d; done
sudo chroot /mnt /bin/bash

df -h /boot
update-initramfs -u -k all
update-grub
grub-install /dev/vda
exit

नए kernel को टेस्ट करें बिना अगले बूट को जोखिम में डाले

GRUB किसी एक entry को केवल एक बार start कर सकता है और उसके बाद आपके द्वारा चुने गए default पर वापस आ सकता है। default को उस kernel पर सेट करें जिस पर आपको भरोसा है, फिर नए kernel को केवल एक बूट के लिए launch करें। यदि यह विफल हो जाता है, तो पैनल से hard reset करने पर आप सुरक्षित kernel पर वापस आ जाएंगे, जिसमें console timing को सही करने की कोई आवश्यकता नहीं होगी।

GRUB_DEFAULT=saved को /etc/default/grub में सेट करें, sudo update-grub चलाएं, और फिर entry titles की सूची देखें ताकि आप किसी एक का सटीक नाम ले सकें:

grep -E "(menuentry|submenu) " /boot/grub/grub.cfg | cut -d"'" -f2
sudo grub-set-default "Advanced options for Ubuntu>Ubuntu, with Linux 6.8.0-XX-generic"
sudo grub-editenv list
sudo grub-reboot 0
sudo reboot

grub-editenv list को आपके द्वारा चुने गए title को saved_entry के रूप में print करना चाहिए। यह output इस बात का प्रमाण है कि यह mechanism काम कर रहा है, क्योंकि इसे save करने के लिए एक writable /boot/grub/grubenv की आवश्यकता होती है, और कुछ layouts पर यह चुपचाप काम नहीं करता है। Entry 0 menu का सबसे ऊपरी हिस्सा है, जो कि सबसे नया kernel होता है। यहाँ numbers के बजाय titles का उपयोग करना अधिक सुरक्षित है, क्योंकि kernel install या remove होने पर numbers बदल जाते हैं।

Headless सर्वर पर autoremove जोखिम भरा क्यों है

APT उन kernel packages की सूची रखता है जिन्हें उसे स्वयं नहीं हटाना चाहिए। अपनी सूची देखें:

cat /etc/apt/apt.conf.d/01autoremove-kernels
dpkg -l 'linux-image-*' | grep -c '^ii'

यह फ़ाइल तब फिर से जनरेट होती है जब kernel packages बदलते हैं, और यह चल रहे kernel तथा सबसे हालिया kernels को सुरक्षित रखती है। जोखिम समय (timing) का है। यदि आप नए kernel में reboot करने के तुरंत बाद sudo apt autoremove --purge चलाते हैं, तो सुरक्षित सूची पहले ही आगे बढ़ चुकी होती है, इसलिए जिस पुराने kernel पर आप भरोसा कर रहे थे वह अब सुरक्षित नहीं रहता। कीबोर्ड वाले मशीन पर यह केवल एक असुविधा है। headless सर्वर पर, यह एक menu entry चुनने और rescue image से अपनी disk को mount करने के बीच का अंतर है।

न्यूनतम दो kernels रखें, और यदि /boot में जगह हो तो तीन रखें। uname -r की जाँच करने के बाद पुराने kernels को नाम से हटाएँ, ताकि आप कभी भी उस kernel को delete न कर सकें जिसे आप चला रहे हैं:

uname -r
sudo apt purge linux-image-6.8.0-XX-generic
dpkg -l 'linux-image-*' | grep '^ii'

उसके बाद वह अंतिम command फिर से चलाएँ। यदि संख्या तीन से दो हो जाती है, तो यह एक cleanup है। यदि संख्या एक हो जाती है, तो यह अगले reboot पर होने वाली एक outage है।

अपग्रेड से पहले स्नैपशॉट लें

apt upgrade से पहले लिया गया स्नैपशॉट रिकवरी का एकमात्र ऐसा रास्ता है जिसके लिए किसी भी चीज़ को बूट करने की आवश्यकता नहीं होती। इसे रिस्टोर करने से डिस्क वापस उस स्थिति में आ जाती है जहाँ पुराना kernel डिफ़ॉल्ट था, और आप कंसोल को पहले से ही ओपन रखकर अपग्रेड को दोबारा प्रयास कर सकते हैं। चलती हुई मशीन के स्नैपशॉट 'क्रैश कंसिस्टेंट' होते हैं, जिसका अर्थ है कि वे डिस्क को ऐसे कैप्चर करते हैं जैसे बिजली अचानक कट गई हो, इसलिए यदि आपका प्रोवाइडर ऑफलाइन स्नैपशॉट सपोर्ट करता है, तो पहले सर्वर को शटडाउन करें। स्नैपशॉट कोई बैकअप नहीं है, क्योंकि यह आमतौर पर उसी इंफ्रास्ट्रक्चर पर रहता है जिस वॉल्यूम की यह कॉपी बनाता है। VPS स्नैपशॉट और वास्तविक बैकअप के बीच का अंतर समझना यह तय करता है कि जब विफलता kernel से बड़ी हो, तो कौन सा विकल्प आपको बचाएगा।

यह रिलीज अपग्रेड के दौरान सबसे अधिक मायने रखता है, जहाँ kernel, initramfs टूल्स, बूटलोडर और GRUB कॉन्फ़िगरेशन सभी एक ही बार में बदल जाते हैं। Ubuntu 24.04 से 26.04 अपग्रेड शुरू करने से ठीक पहले स्नैपशॉट लें, न कि एक रात पहले, ताकि रिस्टोर पॉइंट उस मशीन से मेल खाए जिसे आप बदलने जा रहे हैं। यदि वह अपग्रेड अभी तक आपके सर्वर पर ऑफर नहीं किया गया है, तो इसका कारण खराब सेटअप नहीं बल्कि शेड्यूलिंग है, क्योंकि LTS से LTS का जंप केवल पहली पॉइंट रिलीज, 26.04.1 पर ही खुलता है।

unattended-upgrades kernel packages को कैसे प्रोसेस करता है

Ubuntu का unattended-upgrades बिना पूछे security updates install कर देता है, और kernel packages भी बाकी चीजों की तरह security pocket के माध्यम से ही आते हैं। इसके दो परिणाम होते हैं।

पहला, नया kernel install तो हो जाता है लेकिन चल नहीं रहा होता है। Kernel केवल boot के समय ही प्रभावी होता है। /var/run/reboot-required फाइल दिखाई देती है, और /var/run/reboot-required.pkgs यह बताता है कि reboot की मांग किसने की थी, लेकिन जब तक आप /etc/apt/apt.conf.d/50unattended-upgrades में Unattended-Upgrade::Automatic-Reboot को enable नहीं करते, तब तक कुछ भी restart नहीं होता है।

cat /var/run/reboot-required.pkgs
grep -E 'Automatic-Reboot|Blacklist' /etc/apt/apt.conf.d/50unattended-upgrades

दूसरा, यह अंतराल कारण को छिपा देता है। एक सर्वर मार्च में kernel install कर सकता है और जून में किसी पूरी तरह से असंबंधित कारण से reboot हो सकता है, और फिर boot होने में विफल हो सकता है। जिस बदलाव ने boot को तोड़ा है वह तीन महीने पुराना है, इसलिए उस दिन आपके द्वारा की गई कोई भी गतिविधि इसका कारण नहीं बताती है। /var/log/apt/history.log वह जगह है जहाँ आप उस run को पा सकते हैं जिसने वह kernel install किया था जिस पर आप अब विफल हो रहे हैं।

अपनी पसंद के दिन, जानबूझकर reboot करें, और उस समय console window को खुला रखें। यह एक आदत एक रहस्यमयी outage को दो मिनट के menu selection में बदल देती है। यदि आप बिना किसी आश्चर्य के automation चाहते हैं, तो automatic installs को चालू रखें और automatic reboots को बंद रखें, और सटीक settings के लिए Ubuntu पर unattended-upgrades को कैसे configure करें देखें। sudo apt-mark hold linux-image-generic के साथ kernel packages को hold करने से वे पूरी तरह से रुक जाते हैं, और साथ ही kernel security fixes भी रुक जाते हैं, इसलिए इसे एक सुरक्षा उपाय के बजाय एक ऐसे समझौते के रूप में देखें जिसे आपने करने का निर्णय लिया है।

FAQ

बिना कीबोर्ड वाले VPS पर पुराना kernel कैसे बूट करें?

Provider के console (VNC या serial) को खोलें और control panel से hard reset ट्रिगर करें, क्योंकि आप सामान्य रूप से reboot करने के लिए login नहीं कर सकते। जैसे ही मशीन restart हो, GRUB menu को रोकने के लिए बार-बार Esc दबाएं, या legacy BIOS बूट पर Shift को दबाए रखें। "Advanced options for Ubuntu" चुनें और सबसे नए kernel के नीचे वाली entry को select करें। एक बार login prompt मिलने पर, यह पुष्टि करने के लिए कि आप किस kernel पर हैं, uname -r चलाएं और अन्य क्या installed है यह देखने के लिए dpkg -l 'linux-image-*' चलाएं। सिस्टम के दोबारा चलने के बाद ही निदान (diagnose) करें।

मेरा VPS GRUB menu क्यों नहीं दिखाता है?

Cloud images आमतौर पर /etc/default/grub.d/ के अंतर्गत एक फ़ाइल में GRUB timeout को 0 पर सेट करती हैं, इसलिए सबसे नया kernel बिना किसी विकल्प के शुरू हो जाता है। /etc/default/grub में GRUB_TIMEOUT=10 और GRUB_TIMEOUT_STYLE=menu को सेट करें, GRUB_TERMINAL="console serial" जोड़ें ताकि menu serial console तक भी पहुँचे, और फिर sudo update-grub चलाएं। grep -r TIMEOUT /etc/default/grub /etc/default/grub.d/ के साथ सत्यापित करें, क्योंकि उस directory की फ़ाइलें मुख्य फ़ाइल के बाद पढ़ी जाती हैं और आपके संपादन (edit) को override कर सकती हैं।

क्या /boot में जगह खाली करने के लिए पुराने kernels को हटा देना चाहिए?

सबसे पुराने kernels को हटा दें और कम से कम दो रखें। एक भरा हुआ /boot अपने आप में एक विफलता का कारण है, क्योंकि तब initramfs generation विफल हो जाता है और आपके पास ऐसा kernel बचता है जिसका कोई working image नहीं होता। uname -r की जाँच करने के बाद सटीक package नाम से purge करें, ताकि चल रहा kernel कभी भी हटाने के लिए न चुना जाए। Headless मशीन पर एक साथ sudo apt autoremove --purge चलाने से बचें, क्योंकि protected-kernel सूची हर kernel परिवर्तन पर फिर से उत्पन्न होती है और गलत समय पर चलाया गया command आपको केवल एक kernel के साथ छोड़ सकता है, जिसमें menu में कोई fallback entry नहीं होगी।

क्या unattended-upgrades मेरे बूट को खराब कर सकता है?

यह ऐसा kernel install कर सकता है जो बाद में बूट होने में विफल हो जाए, लेकिन यह मशीन को तब तक restart नहीं करता जब तक कि /etc/apt/apt.conf.d/50unattended-upgrades में Unattended-Upgrade::Automatic-Reboot को true पर सेट न किया गया हो। सामान्य पैटर्न एक विलंबित विफलता है: kernel automatic run के दौरान आता है, /var/run/reboot-required दिखाई देता है, और समस्या केवल हफ्तों बाद आपके अगले reboot पर सामने आती है। Console को पहले से खोलकर जानबूझकर reboot करें, और यह पता लगाने के लिए कि किस run ने वह kernel install किया है जिसे आप बूट कर रहे हैं, /var/log/apt/history.log पढ़ें।