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

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

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

सर्वर पर इसे ठीक करना लैपटॉप को ठीक करने से अलग है, क्योंकि इसमें कोई कीबोर्ड नहीं जुड़ा होता और कोई मॉनिटर panic मैसेज नहीं दिखाता। SSH भी जवाब नहीं देगा, क्योंकि मशीन उस बिंदु तक कभी नहीं पहुँची जहाँ sshd शुरू होता है। नीचे दी गई सभी प्रक्रियाएँ आपके प्रदाता के 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 मेनू कभी दिखाई नहीं देता। अब क्या करें?

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

इसका उल्टा मामला भी होता है, जहाँ मेनू स्क्रीन पर होता है और इंतज़ार कर रहा होता है, और यह एक hang जैसा दिखता है। GRUB एक failed boot को रिकॉर्ड करता है, और अगली बार शुरू होने पर यह मेनू को तब तक खुला रख सकता है जब तक कोई key न दबाई जाए। बिना कीबोर्ड वाले बॉक्स पर, वह इंतज़ार कभी खत्म नहीं होता। यदि आपके console पर मेनू दिख रहा है और कुछ भी आगे नहीं बढ़ रहा है, तो यही हुआ है। एक 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"

फिर इसे लागू करें और जाँचें कि आपका बदलाव सुरक्षित है या नहीं, क्योंकि /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" मेनू को graphical console और serial port पर भेजता है, ताकि यह उस viewer में दिखाई दे जो आपका पैनल आपको देता है। console= kernel arguments boot messages के लिए भी यही काम करते हैं जो इसके बाद आते हैं। प्रति boot दस सेकंड की देरी उस मेनू के लिए एक छोटी कीमत है जिसे आप रात के 2 बजे भी एक्सेस कर सकते हैं।

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

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

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

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

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

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 सिस्टम पार्टीशन को बनाए रखने वाले पैकेज तब एक साधारण खाली डायरेक्टरी में लिख देते हैं। फर्मवेयर तब तक पुरानी बूट प्रविष्टि को शुरू करता रहता है जब तक कि वह प्रविष्टि डिस्क पर मौजूद डेटा से मेल खाना बंद नहीं कर देती।

एक और पैटर्न बूट विफलता नहीं है। यदि आप एक रूट शेल तक पहुँचते हैं जो कहता है कि सिस्टम emergency mode में है, तो कर्नल बूट हो गया है और यूजरस्पेस रुक गया है। इसका आमतौर पर मतलब है कि /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- चाहिए, जिनका आकार विश्वसनीय हो। यदि 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 मेनू का सबसे ऊपरी हिस्सा है, जो कि सबसे नया 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 को न हटा सकें जिस पर आप वर्तमान में चल रहे हैं:

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 अपग्रेड शुरू करने से ठीक पहले लें, एक रात पहले नहीं, ताकि रिस्टोर पॉइंट उसी मशीन से मेल खाए जिसे आप बदलने जा रहे हैं।

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

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

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

अपनी पसंद के दिन, console window को पहले से खोलकर, जानबूझकर reboot करें। यह एक आदत एक रहस्यमयी 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 करें, क्योंकि आप cleanly 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/ के अंतर्गत एक file में 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/ के साथ verify करें, क्योंकि उस directory की files मुख्य file के बाद पढ़ी जाती हैं और आपके द्वारा किए गए बदलाव को override कर सकती हैं।

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

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

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

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