कर्नल अपडेटनंतर VPS बूट होत नसेल तर काय करावे

कर्नल अपडेटनंतर VPS बूट होत नसेल तर प्रथम काय करावे

कर्नल अपडेटनंतर बूट न होणारा VPS साधारणपणे काही मिनिटांत पुन्हा सुरू करता येतो, कारण काल व्यवस्थित चाललेला कर्नल या अपडेटमुळे हटवला जात नाही. Ubuntu नवीन कर्नल जुन्या कर्नलच्या शेजारी स्थापित करते आणि GRUB कोणती entry default म्हणून सुरू करेल, एवढाच बदल करते. त्यामुळे पहिली कृती दुरुस्ती करणे नाही. बूट मेनूमध्ये मागील कर्नल निवडा, login prompt पुन्हा मिळवा आणि त्यानंतर चालू system मधून निदान करा.

Server वर ही प्रक्रिया laptop पेक्षा वेगळी असते, कारण त्याला keyboard जोडलेला नसतो आणि panic दिसण्यासाठी monitor उपलब्ध नसतो. मशीन sshd सुरू होण्याच्या टप्प्यापर्यंत पोहोचलेली नसल्यामुळे SSH कडूनही प्रतिसाद मिळणार नाही. खालील सर्व कृती तुमच्या provider च्या console द्वारे करायच्या आहेत.

काहीही बदलण्यापूर्वी तुमच्या console वरील मजकूर वाचा. त्या स्क्रीनवरील मजकूर तुम्ही कोणत्या failure class मध्ये आहात हे ठरवतो. “बूट होत नाही” अशीच समस्या असलेल्या दोन servers साठी परस्परविरुद्ध दुरुस्ती आवश्यक असू शकते.

SSH बंद असल्यास console पर्यंत कसे पोहोचायचे?

तुमच्या provider चे control panel उघडा आणि console शोधा. यासाठी सामान्यतः VNC console, web console, noVNC आणि serial console ही नावे वापरली जातात. दोन्ही उपलब्ध असल्यास serial console ला प्राधान्य द्या. त्यातून प्रत्यक्ष मजकूर scroll आणि copy करता येतो, तर VNC view मध्ये फक्त screen चे चित्र दिसते. मशीन व्यवस्थित चालू असतानाच हे नियंत्रण शोधून ठेवा आणि ते उघडते याची खात्री करा. सेवा बंद असताना ते शोधण्यात वेळ जातो आणि आवश्यक शांतता कमी होते. हा तपास नवीन VPS वरच्या पहिल्या दहा मिनिटांच्या कामांमध्ये firewall rules आणि SSH keys यांच्या शेजारी असावा.

बहुतेक panels मध्ये rescue mode किंवा recovery image देखील उपलब्ध असते. ते provider च्या network मधून एक छोटी system boot करते आणि तुमची disk extra device म्हणून जोडते. त्यामुळे तुमच्या disk वरील कोणतीही system चालू होत नाही. GRUB स्वतःच बिघडले असल्यास rescue mode हा fallback असतो. ज्या server मधून data वाचवायचा नाही असे तुम्ही ठरवले आहे, त्यामधून data बाहेर copy करण्यासाठीही हीच पद्धत वापरता येते.

Boot menu पर्यंत पोहोचण्यासाठी सामान्यतः panel मधून hard reset करावा लागतो, कारण ज्या मशीनमध्ये login करता येत नाही त्यावर sudo reboot चालवता येत नाही. Hard reset म्हणजे वीजपुरवठा तोडण्यासारखेच आहे. Filesystems ची shutdown प्रक्रिया स्वच्छपणे पूर्ण होत नाही. त्यामुळे पुढील boot वेळी filesystem check होण्याची अपेक्षा ठेवा.

GRUB मेनूमध्ये जुना kernel कसा निवडावा?

reset दाबल्यापासून console वर लक्ष ठेवा. पहिल्या काही सेकंदांत Esc वारंवार दाबा किंवा legacy BIOS mode मध्ये boot होणाऱ्या मशीनवर Shift दाबून ठेवा. ही संधी काही काळापुरतीच असते आणि console viewer ला जोडण्यासाठी अनेकदा एक सेकंद लागतो. त्यामुळे लवकर दाबायला सुरुवात करा आणि दाबत राहा.

मेनू दिसल्यावर "Advanced options for Ubuntu" निवडा. त्या submenu मध्ये स्थापित केलेले सर्व kernel सर्वांत नवीन kernel पासून क्रमाने दिसतात. प्रत्येक kernel साठी recovery mode entry देखील असते. दुसरी normal entry निवडा. ती नवीनतम kernel च्या खालील kernel असते. त्यानंतर Enter दाबा. Recovery mode ही वेगळी गोष्ट आहे. त्यामध्ये minimal single user system boot होते. ते repair कामासाठी आहे; तुमच्या services पुन्हा online आणण्यासाठी नाही.

जुना kernel boot झाल्यास server पुन्हा कार्यरत झाला आहे. तुम्ही कोणत्या kernel वर चालत आहात ते निश्चित करा आणि क्रमांक लिहून ठेवा.

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

dpkg च्या output मध्ये स्थापित kernel ची यादी असते. त्यात केवळ एकच ओळ असल्यास तुमच्याकडे कोणताही fallback नाही. सर्वप्रथम ही बाब दुरुस्त करा.

GRUB मेनू दिसत नाही. आता काय करावे?

Cloud images मध्ये मेनू लपवणारी configuration असते. Ubuntu images मध्ये साधारणपणे /etc/default/grub.d/ अंतर्गत असलेल्या file मध्ये timeout 0 वर सेट केलेला असतो. त्यामुळे नवीनतम kernel लगेच सुरू होतो आणि दाबण्यासाठी काहीही दिसत नाही.

याच्या उलट परिस्थितीही असते. मेनू screen वर दिसतो आणि input ची वाट पाहत राहतो, त्यामुळे system hang झाल्यासारखे वाटते. GRUB boot अयशस्वी झाल्याची नोंद करतो. पुढील start वेळी तो एखाद्याने key दाबेपर्यंत मेनू उघडा ठेवू शकतो. keyboard नसलेल्या मशीनवर ही प्रतीक्षा कधीच संपत नाही. 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/ मधील files /etc/default/grub नंतर read केल्या जातात आणि त्या तुमचे बदल override करू शकतात.

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

GRUB_TERMINAL="console serial" मेनू graphical console आणि serial port या दोन्हीकडे पाठवते. त्यामुळे तुमच्या panel कडून उपलब्ध असलेल्या कोणत्याही viewer मध्ये तो दिसतो. त्यानंतर येणाऱ्या boot messages साठी console= kernel arguments हेच कार्य करतात. प्रत्यक्षात 2am वाजताही पोहोचता येणाऱ्या मेनूसाठी प्रत्येक boot वेळी 10 seconds चा विलंब स्वीकारणे योग्य आहे.

मी कोणत्या प्रकारच्या अपयशाकडे पाहत आहे?

कन्सोलमधील आउटपुट थांबण्यापूर्वीच्या शेवटच्या वीस ओळी वाचा. Kernel update नंतर सामान्यतः दिसणाऱ्या बहुतेक परिस्थिती चार नमुन्यांत येतात.

GRUB ला त्याच्या स्वतःच्या फाइल्स सापडत नाहीत. तुम्हाला grub rescue> prompt दिसतो किंवा अस्तित्वात नसलेल्या partition किंवा file विषयी error दिसतो आणि kernel message दिसतच नाही. या टप्प्यावर kernel चा सहभाग झालेला नसतो. हे साधारणपणे disk किंवा partition मध्ये केलेल्या बदलानंतर, अथवा bootloader चुकीच्या device वर लिहिल्यानंतर घडते; केवळ kernel package मुळे ते घडत नाही.

Kernel सुरू होतो, पण root mount करू शकत नाही. Kernel messages दिसत राहतात. त्यानंतर (initramfs) असा prompt असलेल्या busybox shell मध्ये प्रवेश होतो किंवा root filesystem mount करता न आल्याबद्दल panic येतो. Kernel load झालेला असतो. तुमचे वास्तविक root filesystem शोधून mount करणारा लहान तात्पुरता root असलेला initramfs disk शोधू शकलेला नसतो. Ubuntu वर या shell च्या आधी साधारणपणे root device साठी प्रतीक्षा सोडत असल्याचा message दिसतो आणि त्यात अपेक्षित UUID दिलेला असतो. तो UUID कॉपी करा आणि नंतर blkid च्या output शी त्याची तुलना करा.

Logical volume दिसत नाही. हे मागील प्रकारचेच अपयश आहे; मात्र याचे एक विशिष्ट कारण आहे. (initramfs) prompt वर ls /dev/mapper चालवा. एकमेव entry control असेल, तर कोणताही LVM (logical volume manager) volume activate झालेला नाही. त्यामुळे root device अद्याप अस्तित्वात नसतो. Volume groups हाताने सुरू करा:

lvm vgchange -ay
ls /dev/mapper
exit

exit मुळे नियंत्रण initramfs script कडे परत जाते आणि ती mount करण्याचा पुन्हा प्रयत्न करते. त्यानंतर system boot झाले, तर नवीन initramfs मध्ये LVM चे घटक नाहीत. Kernel मध्ये बदल करण्याऐवजी ती image पुन्हा build करणे हा उपाय आहे.

Linux कडून कोणतेही output नाही. कन्सोलवर firmware text, UEFI (unified extensible firmware interface) shell, kernel output नसलेली रिकामी screen किंवा reset loop दिसतो. Linux सुरू होण्यापूर्वीच अपयश होत आहे. System पुन्हा सुरू झाल्यावर तो प्रत्यक्षात कोणता mode वापरतो ते तपासा. अनेक VPS instances legacy BIOS mode मध्ये boot होतात आणि EFI path वापरतच नाहीत:

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

Upgrade दरम्यान /boot/efi mount केलेले नसणे हे UEFI machines वरील सामान्य कारण आहे. अशा वेळी EFI system partition व्यवस्थापित करणाऱ्या packages नी त्याऐवजी साध्या रिकाम्या directory मध्ये लिहिलेले असते. Disk वरील स्थितीशी ती entry जुळेनाशी होईपर्यंत firmware जुनी boot entry सुरू करत राहते.

आणखी एक नमुना प्रत्यक्ष boot failure नसतो. Root shell मिळतो आणि system emergency mode मध्ये असल्याचे message दिसते, तर kernel boot झालेला असतो आणि userspace थांबलेला असतो. याचा अर्थ साधारणपणे /etc/fstab मधील चुकीची line किंवा check मध्ये अपयशी ठरलेले filesystem असा असतो. त्या shell मध्ये journalctl -xb चालवा आणि कोणत्या unit चे अपयश झाले ते नाव वाचा.

कर्नल पॅकेजमध्ये बिघाड आहे की initramfs मध्ये?

कन्सोलवर या दोन्ही समस्या सारख्याच दिसतात, पण त्यांची दुरुस्ती वेगवेगळी असते. जुना कर्नल सुरू करा आणि नंतर फाइल्सची तुलना करा.

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

स्थापित केलेल्या प्रत्येक version साठी एक vmlinuz- आणि त्याच्याशी जुळणारा एक initrd.img- असावा. दोन्ही फाइल्सचा size विश्वसनीय असावा. initrd नसणे किंवा शेजारच्या फाइल्सपेक्षा त्याचा size खूपच कमी असणे म्हणजे 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 शेवटच्या runs मध्ये कोणती packages आणि केव्हा install झाली हेही अचूकपणे दाखवते. त्यामुळे काय बदलले याविषयीचा वाद स्पष्ट होतो.

/boot भरलेले असल्यास प्रथम मोकळी जागा निर्माण करा. त्यानंतर आवश्यक version साठी image पुन्हा build करा आणि 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 ही पडताळणी आहे. सामान्य size असलेली file म्हणजे image आता उपलब्ध आहे. त्याऐवजी kernel image स्वतःच खराब असेल किंवा dpkg -l मध्ये package ची स्थिती ii व्यतिरिक्त काहीही दिसत असेल, तर package पुन्हा install करा:

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

rescue mode मधून दुरुस्ती: कोणतेही kernel boot होत नसताना

मेनूमधील प्रत्येक entry अयशस्वी होत असल्यास, provider ची rescue image boot करा आणि disk ची बाहेरून दुरुस्ती करा. तुमची disk 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

पुढील boot चा धोका न पत्करता नवीन kernel ची चाचणी

GRUB एक entry फक्त एकदाच सुरू करू शकतो आणि त्यानंतर तुम्ही निवडलेल्या default वर परत येतो. default म्हणून तुमच्या विश्वासातील kernel सेट करा आणि नवीन kernel फक्त एका boot साठी सुरू करा. तो अयशस्वी झाल्यास, panel मधून hard reset केल्यावर console वर योग्य वेळी काही करण्याची गरज न पडता तुम्ही पुन्हा चांगल्या kernel वर येता.

/etc/default/grub मध्ये GRUB_DEFAULT=saved सेट करा, sudo update-grub चालवा आणि entry titles ची यादी दाखवा, जेणेकरून तुम्ही एक title अचूकपणे निर्दिष्ट करू शकाल:

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 म्हणून दाखवला पाहिजे. ही पद्धत कार्यरत असल्याचा तो पुरावा आहे, कारण जतन करण्यासाठी लेखन-अनुमती असलेले /boot/grub/grubenv आवश्यक असते आणि काही layout मध्ये ते उपलब्ध नसते, परंतु कोणताही संदेश न देता प्रक्रिया अपयशी ठरते. Entry 0 हा menu मधील सर्वात वरचा entry असतो आणि तो नवीनतम kernel असतो. येथे titles वापरणे numbers पेक्षा अधिक सुरक्षित आहे, कारण प्रत्येक 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 चे आणि सर्वात अलीकडील kernel चे संरक्षण करते. धोका वेळेमध्ये आहे. नवीन kernel मध्ये reboot केल्यानंतर लगेच sudo apt autoremove --purge चालवल्यास protected list आधीच पुढे सरकलेली असते. त्यामुळे तुम्ही ज्यावर अवलंबून होता तो जुना kernel आता protected राहत नाही. keyboard असलेल्या मशीनवर ही फक्त गैरसोय असते. headless server वर मात्र menu entry निवडता येणे आणि rescue image मधून disk mount करावी लागणे यातील हा फरक असतो.

किमान दोन kernels ठेवा. /boot कडे पुरेशी जागा असल्यास तीन kernels ठेवा. 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 निश्चित आहे.

अपग्रेडपूर्वी snapshot घ्या

apt upgrade करण्यापूर्वी घेतलेला snapshot हा अशी एकमेव recovery पद्धत आहे, जी कोणतीही गोष्ट boot करण्यावर अवलंबून नसते. तो restore केल्यावर disk पुन्हा त्या स्थितीत येतो, ज्या वेळी जुना kernel default होता. त्यानंतर console आधीच उघडी ठेवून तुम्ही अपग्रेड पुन्हा प्रयत्न करू शकता. सुरू असलेल्या machine चे snapshots crash consistent असतात. याचा अर्थ power बंद झाल्यासारखी disk ची स्थिती त्यात नोंदवली जाते. त्यामुळे तुमचा provider offline snapshot ला समर्थन देत असल्यास सर्वप्रथम server shutdown करा. Snapshot हा backup देखील नसतो, कारण तो साधारणपणे ज्या volume ची प्रत तयार करतो त्याच infrastructure वर साठवला जातो. VPS snapshots आणि वास्तविक backups मधील फरक समजून घेतल्यास kernel पेक्षा मोठे failure झाल्यावर कोणता पर्याय तुम्हाला वाचवेल हे ठरवता येते.

हे विशेषतः release upgrade वेळी महत्त्वाचे असते. अशा वेळी kernel, initramfs tools, bootloader आणि GRUB config हे सर्व एकाच run मध्ये बदलतात. तुम्ही सुरू करणार असलेल्या Ubuntu 24.04 ते 26.04 upgrade च्या अगदी आधी snapshot घ्या; आदल्या रात्री नाही. त्यामुळे restore point तुम्ही बदलणार असलेल्या machine च्या अचूक स्थितीशी जुळतो. तो upgrade तुमच्या server वर अद्याप उपलब्ध नसेल, तर कारण setup मधील बिघाड नसून scheduling असते. LTS ते LTS upgrade फक्त पहिल्या point release, 26.04.1 वेळी उपलब्ध होते.

unattended-upgrades kernel पॅकेजेस हाताळते

Ubuntu चे unattended-upgrades कोणतीही परवानगी न मागता security updates install करते. Kernel packages देखील इतर packages प्रमाणे security pocket मधून येतात. याचे दोन परिणाम होतात.

पहिला परिणाम असा की नवीन kernel install होतो, पण तो चालू होत नाही. Kernel फक्त boot वेळी लागू होतो. /var/run/reboot-required फाइल दिसते. Reboot ची विनंती कोणी केली हे /var/run/reboot-required.pkgs दाखवते. मात्र Unattended-Upgrade::Automatic-Reboot हे /etc/apt/apt.conf.d/50unattended-upgrades मध्ये enable केलेले नसल्यास काहीही आपोआप restart होत नाही.

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

दुसरा परिणाम असा की या विलंबामुळे मूळ कारण लपते. एखादा server March मध्ये kernel install करू शकतो आणि पूर्णपणे असंबंधित कारणामुळे June मध्ये reboot होऊन सुरू होण्यात अपयशी ठरू शकतो. Boot बिघडवणारा बदल तीन महिन्यांपूर्वीचा असतो. त्यामुळे त्या दिवशी केलेल्या कोणत्याही कृतीत कारण दिसत नाही. तुम्ही ज्या kernel मुळे सध्या सुरू करण्यात अपयशी ठरत आहात तो install करणारी run /var/log/apt/history.log मध्ये सापडते.

तुम्ही निवडलेल्या दिवशी, console window आधीच उघडी ठेवून, जाणीवपूर्वक reboot करा. या एका सवयीमुळे गूढ outage चे रूपांतर दोन मिनिटांच्या menu selection मध्ये होते. अनपेक्षित reboot टाळून automation हवे असल्यास automatic installs सुरू ठेवा आणि automatic reboots बंद ठेवा. अचूक settings साठी Ubuntu वर unattended-upgrades configure कसे करावे पहा. sudo apt-mark hold linux-image-generic वापरून kernel packages hold केल्यास ते पूर्णपणे थांबतात. त्याच वेळी kernel security fixes देखील थांबतात. त्यामुळे याकडे safety measure म्हणून नव्हे, तर जाणीवपूर्वक स्वीकारलेल्या trade-off म्हणून पाहा.

FAQ

keyboard नसलेल्या VPS वर जुना kernel कसा boot करावा?

Provider चे console (VNC किंवा serial) उघडा आणि control panel मधून hard reset सुरू करा, कारण clean reboot करण्यासाठी तुम्ही login करू शकत नाही. मशीन restart होत असताना Esc वारंवार दाबा किंवा legacy BIOS boot असल्यास Shift दाबून ठेवा, म्हणजे GRUB menu उघडा राहील. "Advanced options for Ubuntu" निवडा आणि सर्वांत नवीन kernel च्या खालील entry निवडा. Login prompt मिळाल्यावर तुम्ही कोणत्या kernel वर आहात हे तपासण्यासाठी uname -r चालवा आणि आणखी कोणते kernels installed आहेत हे पाहण्यासाठी dpkg -l 'linux-image-*' चालवा. System पुन्हा सुरू झाल्यानंतरच diagnosis करा.

माझ्या VPS वर GRUB menu अजिबात का दिसत नाही?

Cloud images मध्ये /etc/default/grub.d/ अंतर्गत असलेल्या file मध्ये GRUB timeout सामान्यतः 0 सेट केलेला असतो. त्यामुळे दाबण्यासाठी काहीही न दाखवता सर्वांत नवीन kernel सुरू होतो. /etc/default/grub मध्ये GRUB_TIMEOUT=10 आणि GRUB_TIMEOUT_STYLE=menu सेट करा. Menu serial console वरही उपलब्ध होण्यासाठी GRUB_TERMINAL="console serial" जोडा. त्यानंतर sudo update-grub चालवा. grep -r TIMEOUT /etc/default/grub /etc/default/grub.d/ वापरून पडताळणी करा, कारण त्या directory मधील files मुख्य file नंतर वाचल्या जातात आणि तुमच्या edit वर override करू शकतात.

/boot मध्ये जागा मोकळी करण्यासाठी जुने kernels काढावेत का?

सर्वांत जुने kernels काढा आणि किमान दोन kernels ठेवा. /boot भरल्यास स्वतंत्र failure mode निर्माण होतो, कारण त्यानंतर initramfs generation अपयशी ठरते आणि working image नसलेला kernel उरतो. uname -r तपासल्यानंतर exact package name वापरून purge करा, म्हणजे सध्या चालू असलेला kernel कधीही candidate ठरणार नाही. Headless machine वर blanket sudo apt autoremove --purge टाळा, कारण प्रत्येक kernel change वेळी protected-kernel list पुन्हा तयार केली जाते आणि चुकीच्या वेळी चालवलेली command menu मध्ये एकच kernel आणि कोणतीही fallback entry नसलेली स्थिती निर्माण करू शकते.

unattended-upgrades मुळे boot मध्ये बिघाड होऊ शकतो का?

होऊ शकतो. एखादा kernel नंतर boot होण्यात अपयशी ठरेल अशा प्रकारे तो install केला जाऊ शकतो. मात्र /etc/apt/apt.conf.d/50unattended-upgrades मध्ये Unattended-Upgrade::Automatic-Reboot true सेट केलेले नसल्यास मशीन restart होत नाही. नेहमीची पद्धत अशी असते: automatic run दरम्यान kernel install होतो, /var/run/reboot-required दिसते आणि काही आठवड्यांनी पुढील reboot केल्यावरच समस्या समोर येते. Console आधीच उघडे ठेवून जाणीवपूर्वक reboot करा आणि तुम्ही boot करत असलेला kernel कोणत्या run ने install केला हे शोधण्यासाठी /var/log/apt/history.log वाचा.