Kernel update नंतर boot न होणारा VPS कसा सुरू करावा

VPS kernel update नंतर boot होत नसेल तर प्रथम काय करावे

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

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

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

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

तुमच्या provider चे control panel उघडा आणि console शोधा. सामान्य नावे VNC console, web console, noVNC आणि serial console अशी आहेत. दोन्ही उपलब्ध असतील, तर serial console ला प्राधान्य द्या. त्यातून खरा text scroll आणि copy करता येतो, तर VNC view मध्ये फक्त screen चे चित्र दिसते. मशीन सुरळीत असतानाच हे control शोधून ठेवा आणि ते उघडते का ते तपासा. outage सुरू झाल्यावर ते शोधण्यात वेळ जातो आणि आवश्यक शांतपणे troubleshooting करण्यासाठी कमी वेळ उरतो. ही तपासणी नवीन 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 करावा लागतो, कारण ज्या machine मध्ये 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 सुरू होते. ती repair work साठी आहे; तुमच्या services पुन्हा online आणण्यासाठी नाही.

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

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

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

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

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

याच्या उलट स्थितीही असू शकते. मेन्यू स्क्रीनवर दिसतो आणि प्रतीक्षा करत राहतो, त्यामुळे system hang झाल्यासारखे वाटते. GRUB ला boot अयशस्वी झाल्याचे आढळल्यास, पुढील start वेळी तो एखाद्याने key दाबेपर्यंत मेन्यू उघडे ठेवू शकतो. keyboard नसलेल्या मशीनवर ही प्रतीक्षा कधीच संपत नाही. तुमच्या console वर मेन्यू दिसत असेल आणि काहीही पुढे सरकत नसेल, तर हेच कारण आहे. एखादी entry निवडा आणि पुढे जा.

मशीन व्यवस्थित सुरू असतानाच दोन्ही समस्या दुरुस्त करा. /etc/default/grub संपादित करा:

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 या दोन्हीकडे पाठवला जातो. त्यामुळे तुमच्या panel मध्ये उपलब्ध असलेल्या viewer मध्ये तो दिसतो. त्यानंतर येणाऱ्या boot messages साठी console= kernel arguments हेच करतात. प्रत्येक boot वेळी दहा सेकंदांचा विलंब स्वीकारणे योग्य आहे; कारण त्यामुळे रात्री 2 वाजताही प्रत्यक्ष वापरता येणारा मेन्यू उपलब्ध राहतो.

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

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

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

Kernel सुरू होतो, पण root mount करू शकत नाही. Kernel संदेश दिसत राहतात. त्यानंतर (initramfs) असा prompt असलेल्या busybox shell मध्ये प्रवेश होतो, किंवा root filesystem mount करता न आल्याची panic त्रुटी दिसते. Kernel load झालेला असतो. प्रत्यक्ष root filesystem शोधून mount करणारा लहान तात्पुरता root असलेला initramfs disk शोधू शकलेला नसतो. Ubuntu वर या shell च्या आधी सामान्यतः root device साठी प्रतीक्षा सोडत असल्याचा संदेश दिसतो. त्या संदेशात अपेक्षित 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 पुन्हा तयार करा.

Linux कडून कोणताही संदेश दिसत नाही. Console वर firmware मजकूर, UEFI (unified extensible firmware interface) shell, kernel output नसलेली रिकामी screen किंवा reset loop दिसतो. Linux सुरू होण्यापूर्वीच अपयश घडत आहे. Server पुन्हा सुरू झाल्यावर तो प्रत्यक्षात कोणता 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 मध्ये files लिहिल्या. Disk वरील स्थितीशी boot entry जुळेनाशी होईपर्यंत firmware जुनी boot entry सुरू करत राहते.

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

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

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

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

प्रत्येक स्थापित आवृत्तीसाठी एक vmlinuz- आणि त्याच्याशी जुळणारा एक initrd.img- असावा. दोन्ही फाइल्सचा आकार विश्वासार्ह असावा. initrd नसणे किंवा शेजारील फाइल्सच्या तुलनेत त्याचा आकार खूपच कमी असणे म्हणजे initramfs निर्मिती अयशस्वी झाली आहे. याचे नेहमीचे कारण /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 पूर्ण असल्यास प्रथम मोकळी जागा निर्माण करा. त्यानंतर आवश्यक आवृत्तीसाठी image पुन्हा तयार करा आणि menu refresh करा. आवृत्तीची string स्वतःच्या ls output मधून घ्या, कारण खालील 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 पुन्हा install करा:

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

बूट होणारा कोणताही kernel नसताना rescue mode मधून दुरुस्ती

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

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

GRUB एक entry फक्त एकदा सुरू करू शकतो आणि त्यानंतर तुम्ही निवडलेल्या default entry कडे परत जाऊ शकतो. 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 म्हणून दाखवला पाहिजे. हे output यंत्रणा कार्यरत असल्याचा पुरावा आहे, कारण save करण्यासाठी writable /boot/grub/grubenv आवश्यक असते आणि काही layouts मध्ये ते उपलब्ध नसते; मात्र कोणताही error दिसत नाही. 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 चे संरक्षण करते. धोका timing मध्ये आहे. नवीन 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 ज्या स्थितीत राहील, त्याच स्थितीत snapshot घेतला जातो. त्यामुळे provider offline snapshot ला समर्थन देत असल्यास, आधी server बंद करा. Snapshot हा backup देखील नाही, कारण तो सहसा ज्या volume ची प्रत घेतो त्याच infrastructure वर साठवला जातो. VPS snapshots आणि वास्तविक backups मधील फरक समजून घेणे महत्त्वाचे आहे. Kernel पेक्षा मोठे failure झाल्यास यापैकी कोणती पद्धत तुम्हाला वाचवेल हे त्यावर ठरते.

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

कर्नल पॅकेजेस unattended-upgrades कसे हाताळते

Ubuntu चे unattended-upgrades कोणतीही सूचना न देता सुरक्षा अद्यतने स्थापित करते. कर्नल पॅकेजेसही इतर सर्व पॅकेजेसप्रमाणे security pocket मधून येतात. याचे दोन परिणाम होतात.

पहिला परिणाम असा की नवीन कर्नल स्थापित होतो, पण तो चालू होत नाही. कर्नलचा प्रभाव फक्त 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

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

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

FAQ

कीबोर्ड नसलेल्या VPS वर जुना kernel कसा boot करू?

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

माझ्या 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 नंतर वाचल्या जातात आणि तुमचे बदल अधिलिखित करू शकतात.

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

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

unattended-upgrades मुळे boot बिघडू शकतो का?

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