Kernel update-க்கு பிறகு VPS boot ஆகவில்லை என்றால் என்ன

kernel update-க்கு பிறகு VPS boot ஆகவில்லை என்றால் முதலில் செய்ய வேண்டியவை

kernel update-க்கு பிறகு VPS boot ஆகவில்லை என்றால், அதைச் சில நிமிடங்களில் சரிசெய்துவிடலாம். ஏனெனில், முந்தைய kernel கோப்புகள் நீக்கப்படவில்லை. Ubuntu புதிய kernel-ஐ பழையதோடு சேர்த்து நிறுவுகிறது; GRUB எந்த kernel-ஐ முதலில் இயக்க வேண்டும் என்பதை மட்டுமே மாற்றுகிறது. எனவே, முதலில் நீங்கள் செய்ய வேண்டியது பழுதுபார்ப்பு அல்ல. boot menu-வில் முந்தைய kernel-ஐத் தேர்ந்தெடுத்து, login prompt-ஐப் பெற்று, இயங்கும் system-ல் இருந்து பிரச்சினையைக் கண்டறிய வேண்டும்.

server-ல் இதைச் சரிசெய்வது laptop-ல் செய்வதிலிருந்து மாறுபட்டது. ஏனெனில், இதில் keyboard இணைக்கப்படவில்லை, monitor-ல் panic error-ஐயும் பார்க்க முடியாது. machine-ல் sshd தொடங்கும் நிலையை அடையாததால், SSH மூலமாகவும் இணைக்க முடியாது. கீழே உள்ள அனைத்தும் உங்கள் provider வழங்கும் console மூலமாகவே செய்யப்பட வேண்டும்.

எதையும் மாற்றும் முன் உங்கள் console-ல் உள்ள தகவலைப் படிக்கவும். அந்தத் திரையில் உள்ள உரையே உங்கள் server எந்த வகையான தோல்வியை எதிர்கொள்கிறது என்பதைத் தீர்மானிக்கும். "boot ஆகவில்லை" என்று சொல்லப்படும் இரண்டு server-களுக்கு முற்றிலும் மாறுபட்ட தீர்வுகள் தேவைப்படலாம்.

SSH செயலிழந்தால் console-ஐ எவ்வாறு அணுகுவது?

உங்கள் service provider-ன் control panel-க்குச் சென்று console-ஐத் தேடவும். VNC console, web console, noVNC, மற்றும் serial console ஆகியவை பொதுவான பெயர்கள். இரண்டிலும் வசதி இருந்தால் serial console-ஐத் தேர்ந்தெடுக்கவும்; ஏனெனில் அதில் உரையை நகலெடுக்கவும், scroll செய்யவும் முடியும். VNC என்பது திரையின் ஒரு படம் மட்டுமே. இயந்திரம் சரியாக இயங்கும்போது இந்த வசதியை இப்போதே கண்டறிந்து, அது வேலை செய்கிறதா என்பதை உறுதிப்படுத்தவும். சேவை முடங்கியிருக்கும்போது இதைத் தேடுவது பதற்றத்தை உண்டாக்கும். இந்தச் சோதனையை புதிய VPS-ன் முதல் பத்து நிமிடங்களில் செய்ய வேண்டும்; firewall விதிகள் மற்றும் SSH keys-ஐ அமைக்கும்போதே இதையும் செய்துவிடவும்.

பெரும்பாலான panels rescue mode அல்லது recovery image வசதியை வழங்குகின்றன. இது provider-ன் network-லிருந்து ஒரு சிறிய system-ஐ boot செய்து, உங்கள் disk-ஐ ஒரு கூடுதல் சாதனமாக இணைக்கும்; இதனால் உங்கள் disk-ல் உள்ள எந்தவொரு மென்பொருளும் இயங்காது. GRUB பழுதடைந்தால் rescue mode-ஐப் பயன்படுத்தலாம்; மேலும், ஒரு server-ஐத் தொடர்ந்து பயன்படுத்தப் போவதில்லை என்றால், அதிலிருந்து தரவுகளை எடுக்கவும் இது உதவும்.

நீங்கள் login செய்ய முடியாத இயந்திரத்தில் sudo reboot கட்டளையை இயக்க முடியாது என்பதால், boot menu-வை அடைய panel மூலம் hard reset செய்ய வேண்டியிருக்கும். hard reset என்பது மின் இணைப்பைத் துண்டிப்பதற்குச் சமம். இதனால் filesystem சரியாக மூடப்படாது, எனவே அடுத்த முறை boot செய்யும்போது filesystem check நடக்கும் என்பதை எதிர்பார்க்கலாம்.

GRUB மெனுவில் பழைய kernel-ஐ எவ்வாறு தேர்ந்தெடுப்பது?

Reset பொத்தானை அழுத்திய தருணத்திலிருந்து console-ஐ கவனிக்கவும். முதல் சில வினாடிகளில் Esc-ஐத் தொடர்ந்து அழுத்தவும், அல்லது legacy BIOS முறையில் இயங்கும் கணினியாக இருந்தால் Shift-ஐ அழுத்திப் பிடிக்கவும். இந்த கால அவகாசம் மிகக் குறைவு, மேலும் console viewer இணைவதற்குச் சில வினாடிகள் ஆகலாம், எனவே முன்கூட்டியே அழுத்தத் தொடங்கித் தொடர்ந்து அழுத்தவும்.

மெனு தோன்றியதும், "Advanced options for Ubuntu" என்பதைத் தேர்ந்தெடுக்கவும். அந்த submenu-வில் நிறுவப்பட்ட அனைத்து kernel-களும் புதியவற்றிலிருந்து பழையவை என்ற வரிசையில் பட்டியலிடப்பட்டிருக்கும், ஒவ்வொன்றிற்கும் ஒரு recovery mode உள்ளீடும் இருக்கும். புதிய kernel-க்கு அடுத்ததாக உள்ள இரண்டாவது சாதாரண உள்ளீட்டைத் தேர்ந்தெடுத்து Enter அழுத்தவும். Recovery mode என்பது வேறுபட்டது: இது ஒரு குறைந்தபட்ச single user system-ஐத் தொடங்கும், இது பழுதுபார்ப்பு பணிகளுக்காகவே தவிர, உங்கள் சேவைகளை மீண்டும் ஆன்லைனில் கொண்டு வருவதற்காக அல்ல.

பழைய kernel வெற்றிகரமாகத் தொடங்கினால், உங்கள் server மீண்டும் இயங்கும் நிலைக்கு வந்துவிடும். நீங்கள் எந்த kernel-ல் இருக்கிறீர்கள் என்பதை உறுதிப்படுத்தி, அந்த எண்களைக் குறித்துக் கொள்ளவும்.

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

dpkg கட்டளையின் வெளியீடு உங்கள் கணினியில் நிறுவப்பட்ட kernel-களின் பட்டியலாகும். அதில் ஒரே ஒரு வரி மட்டுமே இருந்தால், உங்களிடம் fallback வசதி இல்லை என்று அர்த்தம், இதைத்தான் நீங்கள் முதலில் சரிசெய்ய வேண்டும்.

GRUB menu ஏன் தெரிவதில்லை?

Cloud images-ல் menu-வை மறைக்கும் வகையில் configuration அமைக்கப்பட்டுள்ளது. Ubuntu images-ல் பொதுவாக /etc/default/grub.d/ கோப்பில் timeout மதிப்பு 0 என அமைக்கப்பட்டிருக்கும். இதனால், மிகப்புதிய kernel உடனடியாகத் தொடங்கும், நீங்கள் எதையும் அழுத்த வாய்ப்பிருக்காது.

இதற்கு நேர்மாறான சூழலும் உண்டு; menu திரையில் தோன்றி காத்திருக்கும்போது, அது system hang ஆனது போலத் தோன்றும். GRUB ஒருமுறை boot தோல்வியடைந்ததை பதிவு செய்திருந்தால், அடுத்த முறை யாராவது ஒரு key-ஐ அழுத்தும் வரை menu-வை அப்படியே வைத்திருக்கும். விசைப்பலகை (keyboard) இல்லாத கணினிகளில், இந்த காத்திருப்பு முடிவுக்கு வராது. உங்கள் console-ல் menu தெரிந்து, எந்த மாற்றமும் இல்லை என்றால், இதுவே காரணம். ஒரு 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" ஆனது menu-வை graphical console மற்றும் serial port ஆகிய இரண்டிற்கும் அனுப்பும். இதனால் உங்கள் panel-ல் எந்த viewer இருந்தாலும் அதில் menu தெரியும். console= kernel arguments, boot செய்திகளை அதேபோல் கையாளும். அதிகாலை 2 மணிக்குத் தேவைப்படும்போது menu-வை அணுக, ஒவ்வொரு boot-க்கும் 10 வினாடிகள் காத்திருப்பது ஒரு சிறிய விலையே.

நான் எந்த வகையான தோல்வியைக் கையாள்கிறேன்?

Console-ன் இயக்கம் நின்ற இடத்திற்கு முந்தைய கடைசி இருபது வரிகளைப் படிக்கவும். Kernel update-க்கு பிறகு நடக்கும் பெரும்பாலான சிக்கல்களை நான்கு பொதுவான அமைப்புகள் விளக்குகின்றன.

GRUB-ஆல் அதன் சொந்தக் கோப்புகளைக் கண்டறிய முடியவில்லை. உங்களுக்கு grub rescue> prompt கிடைக்கும், அல்லது இல்லாத ஒரு partition அல்லது கோப்பு குறித்த பிழைச் செய்தி தோன்றும்; எந்தவொரு kernel செய்தியும் வராது. இதில் kernel இன்னும் செயல்பாட்டிற்கு வரவில்லை. இது ஒரு disk அல்லது partition மாற்றத்திற்குப் பிறகு அல்லது bootloader தவறான சாதனத்தில் எழுதப்பட்டதால் நிகழ்கிறது; kernel package-ஆல் மட்டும் இது நிகழ்வதில்லை.

Kernel தொடங்குகிறது, ஆனால் root-ஐ mount செய்ய முடியவில்லை. Kernel செய்திகள் திரையில் ஓடும், பிறகு நீங்கள் (initramfs) என்று காட்டும் busybox shell-க்குச் செல்வீர்கள், அல்லது root filesystem-ஐ mount செய்ய முடியவில்லை என்ற panic செய்தியுடன் boot முடிவடையும். Kernel ஏற்றப்பட்டது. உண்மையான root filesystem-ஐக் கண்டறிந்து mount செய்யும் சிறிய தற்காலிக root-ஆன initramfs, disk-ஐக் கண்டறியவில்லை. Ubuntu-வில், இந்த shell-க்கு முன்னதாக root device-க்காகக் காத்திருந்து தோல்வியடைந்த செய்தி வரும், அதில் அது தேடிய UUID குறிப்பிடப்பட்டிருக்கும். அந்த UUID-ஐ நகலெடுத்து, பின்னர் blkid வெளியீட்டுடன் ஒப்பிட்டுப் பார்க்கவும்.

Logical volume ஒருபோதும் தோன்றவில்லை. இது முந்தைய வகையைச் சார்ந்தது, ஆனால் ஒரு குறிப்பிட்ட காரணத்தைக் கொண்டது. (initramfs) prompt-ல், ls /dev/mapper என்பதை இயக்கவும். அதில் control மட்டுமே இருந்தால், எந்தவொரு LVM (logical volume manager) volume-ம் செயல்படுத்தப்படவில்லை என்று அர்த்தம், எனவே 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 வெளியீடு இல்லாத வெற்றுத் திரை அல்லது reset loop மட்டுமே தெரியும். Linux இயங்குவதற்கு முன்பே தோல்வி ஏற்படுகிறது. நீங்கள் மீண்டும் system-ஐச் சரிசெய்த பிறகு, உங்கள் server எந்த mode-ஐப் பயன்படுத்துகிறது என்பதைச் சரிபார்க்கவும், ஏனெனில் பல VPS instances legacy BIOS mode-ல் boot ஆகின்றன, அவை EFI path-ஐப் பயன்படுத்துவதில்லை:

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

UEFI இயந்திரங்களில் upgrade-ன் போது /boot/efi mount செய்யப்படாமல் இருப்பது ஒரு பொதுவான காரணமாகும், ஏனெனில் EFI system partition-ஐப் பராமரிக்கும் packages சாதாரணமான காலி directory-ல் தகவல்களை எழுதிவிடும். Disk-ல் உள்ளவற்றுடன் அந்த entry பொருந்தாத வரை, firmware பழைய boot entry-யையே தொடர்ந்து தொடங்கும்.

இன்னொரு வகை, boot தோல்வியே அல்ல. நீங்கள் emergency mode-ல் உள்ளதாகக் கூறும் root shell-ஐ அடைந்தால், kernel boot ஆகிவிட்டது, ஆனால் userspace நின்றுவிட்டது என்று அர்த்தம். இது பொதுவாக /etc/fstab-ல் உள்ள தவறான வரி அல்லது அதன் சோதனையில் தோல்வியடைந்த filesystem காரணமாக இருக்கலாம். அந்த shell-ல் journalctl -xb என்பதை இயக்கி, தோல்வியடைந்த unit-ன் பெயரைப் படிக்கவும்.

Kernel package சிதைந்துள்ளதா அல்லது initramfs-ஆ?

Console-ல் பார்க்கும்போது இவை இரண்டும் ஒரே மாதிரியாகத் தோன்றும், ஆனால் இவற்றைச் சரிசெய்யும் முறைகள் வேறுபட்டவை. பழைய kernel-ஐ boot செய்து, கோப்புகளை ஒப்பிட்டுப் பார்க்கவும்.

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

ஒவ்வொரு installed version-க்கும் ஒரு 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

கடைசியாக எந்தெந்த packages எப்போது install செய்யப்பட்டன என்பதை history.log துல்லியமாகப் பட்டியலிடும், இது எதில் மாற்றம் ஏற்பட்டது என்ற குழப்பத்தைத் தீர்க்கும்.

/boot நிரம்பியிருந்தால் முதலில் இடத்தைச் சுத்தம் செய்யவும் (free space), பின்னர் தேவையான version-க்கு image-ஐ மீண்டும் உருவாக்கி menu-வை refresh செய்யவும். கீழே உள்ள placeholder ஒரு உண்மையான release அல்ல என்பதால், உங்கள் ls output-ல் உள்ள version string-ஐப் பயன்படுத்தவும்:

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

அந்தக் கடைசி ls என்பது சரிபார்ப்புக்கானது. கோப்பின் அளவு சரியாக இருந்தால், image இப்போது அங்கு உள்ளது என்று அர்த்தம். மாறாக, kernel image-ஏ சிதைந்திருந்தாலோ அல்லது dpkg -l அந்த package-ஐ ii என்பதைத் தவிர வேறு நிலையில் காட்டினாலோ, package-ஐ மீண்டும் install செய்யவும்:

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

Kernel boot ஆகாதபோது rescue mode மூலம் சரிசெய்தல்

Boot menu-வில் உள்ள அனைத்து entry-களும் தோல்வியுற்றால், provider-ன் rescue image-ஐ boot செய்து, disk-ஐ வெளிப்புறமாக இருந்து சரிசெய்யவும். உங்கள் disk unmounted சாதனமாகத் தெரியும் என்பதால், அதில் எந்த process-ம் இயங்காது, மேலும் கோப்புகளை மாற்றும்போது எந்தத் தடையும் இருக்காது.

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-க்குத் திரும்பிவிடும். நீங்கள் நம்பும் kernel-ஐ default-ஆக வைத்துக்கொண்டு, புதிய kernel-ஐ ஒருமுறை மட்டும் boot செய்யத் தொடங்கலாம். அது தோல்வியடைந்தால், panel மூலம் hard reset செய்வதன் மூலம், console timing-ஐக் கவனிக்க வேண்டிய அவசியமின்றி, பழைய சரியான kernel-க்கே மீண்டும் வந்துவிடலாம்.

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 என அச்சிட வேண்டும். இந்த output-தான் இந்த முறை சரியாகச் செயல்படுவதற்கான சான்று. ஏனெனில், இதைச் சேமிக்க /boot/grub/grubenv கோப்பு எழுதக்கூடிய நிலையில் (writable) இருக்க வேண்டும்; சில layout-களில் இது அமைதியாகத் தோல்வியடையலாம். Entry 0 என்பது menu-வின் உச்சியில் உள்ள, அதாவது மிகப்புதிய kernel ஆகும். Kernel-கள் நிறுவப்படும்போதோ அல்லது நீக்கப்படும்போதோ எண்கள் மாறிக்கொண்டே இருக்கும் என்பதால், எண்களை விட titles-ஐப் பயன்படுத்துவது பாதுகாப்பானது.

Headless server-ல் autoremove ஏன் ஆபத்தானது

APT தானாகவே நீக்கக்கூடாத kernel packages-ன் பட்டியலை வைத்திருக்கும். உங்களது பட்டியலை இங்கே பார்க்கலாம்:

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

Kernel packages மாறும்போது அந்த file மீண்டும் உருவாக்கப்படும்; இது தற்போது இயங்கும் kernel-ஐயும், மிக சமீபத்திய kernel-களையும் பாதுகாக்கும். இதில் உள்ள சிக்கல் நேர மேலாண்மை சார்ந்தது. புதிய kernel-க்கு reboot செய்த உடனேயே sudo apt autoremove --purge கட்டளையை இயக்கினால், பாதுகாக்கப்பட்ட பட்டியல் ஏற்கனவே மாறிவிடும். எனவே, நீங்கள் நம்பியிருந்த பழைய kernel இனி பாதுகாக்கப்பட்டதாக இருக்காது. விசைப்பலகை இணைக்கப்பட்ட கணினியில் இது ஒரு சிறிய சிரமம். ஆனால், headless server-ல் இது boot menu-வில் ஒரு தேர்வைச் செய்வதற்கும், rescue image மூலம் disk-ஐ mount செய்து சரிசெய்வதற்கும் இடையிலான பெரிய வித்தியாசத்தை ஏற்படுத்தும்.

குறைந்தபட்சம் இரண்டு kernel-களை எப்போதும் வைத்திருக்கவும்; /boot-ல் இடம் இருந்தால் மூன்று kernel-களை வைத்திருக்கலாம். uname -r மூலம் சரிபார்த்த பிறகு, பழைய kernel-களை அவற்றின் பெயர் கொண்டு நீக்கவும். இதன் மூலம் நீங்கள் தற்போது இயக்கும் kernel-ஐ தவறுதலாக நீக்குவதைத் தவிர்க்கலாம்:

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

அதன்பிறகு அந்த கடைசி கட்டளையை மீண்டும் இயக்கவும். எண்ணிக்கை மூன்றிலிருந்து இரண்டாகக் குறைவது ஒரு முறையான சுத்தம் செய்தல் ஆகும். எண்ணிக்கை ஒன்றாகக் குறைந்தால், அது அடுத்த reboot-ல் சிக்கலை ஏற்படுத்தும்.

மேம்படுத்தலுக்கு (upgrade) முன்பு ஒரு snapshot எடுங்கள்

apt upgrade-க்கு முன்பு எடுக்கப்படும் ஒரு snapshot, எதையும் boot செய்ய வேண்டிய அவசியமில்லாத ஒரே மீட்பு வழியாகும். அதை restore செய்வதன் மூலம், பழைய kernel இயல்பாக (default) இருந்த நிலைக்கு disk-ஐக் கொண்டு செல்ல முடியும். console-ஐத் திறந்து வைத்துக்கொண்டு, நீங்கள் மேம்படுத்தலை மீண்டும் முயற்சி செய்யலாம். இயங்கிக்கொண்டிருக்கும் machine-ன் snapshots 'crash consistent' முறையில் இருக்கும்; அதாவது மின்சாரம் திடீரெனத் துண்டிக்கப்பட்டால் disk எப்படி இருக்குமோ, அதே நிலையில் அது சேமிக்கப்படும். எனவே, உங்கள் provider offline snapshot-ஐ ஆதரித்தால், முதலில் server-ஐ shutdown செய்துவிட்டு snapshot எடுங்கள். snapshot என்பது backup அல்ல; ஏனெனில் இது பொதுவாக எந்த volume-ஐ நகல் எடுக்கிறதோ, அதே உள்கட்டமைப்பில்தான் (infrastructure) சேமிக்கப்படும். VPS snapshots மற்றும் உண்மையான backups-க்கு இடையிலான வேறுபாட்டை புரிந்துகொள்வது, kernel-ஐத் தாண்டிய பெரிய தோல்விகள் ஏற்படும்போது எது உங்களைக் காப்பாற்றும் என்பதைத் தீர்மானிக்கும்.

kernel, initramfs கருவிகள், bootloader மற்றும் GRUB config ஆகிய அனைத்தும் ஒரே நேரத்தில் மாறும் release upgrade-ன் போது இது மிக முக்கியமானது. Ubuntu 24.04-லிருந்து 26.04-க்கு மேம்படுத்தும் பணியைத் தொடங்குவதற்குச் சரியாக முன்பாக snapshot எடுங்கள்; முந்தைய நாள் இரவே எடுக்க வேண்டாம். அப்போதுதான், நீங்கள் மாற்றப்போகும் machine-ன் அதே நிலைக்கு restore point சரியாகப் பொருந்தும்.

unattended-upgrades எவ்வாறு kernel packages-ஐ கையாளுகிறது

Ubuntu-வின் unattended-upgrades பாதுகாப்பு மேம்படுத்தல்களை (security updates) தானாகவே நிறுவுகிறது. மற்ற தொகுப்புகளைப் போலவே, kernel தொகுப்புகளும் security pocket வழியாகவே வருகின்றன. இதனால் இரண்டு விளைவுகள் ஏற்படுகின்றன.

முதலாவதாக, புதிய kernel நிறுவப்படும், ஆனால் அது இயங்காது. ஒரு kernel, கணினி மறுதொடக்கம் (reboot) செய்யப்படும்போது மட்டுமே செயல்பாட்டுக்கு வரும். /var/run/reboot-required என்ற கோப்பு தோன்றும், மேலும் /var/run/reboot-required.pkgs-ல் எதனால் மறுதொடக்கம் தேவைப்பட்டது என்பது குறிப்பிடப்பட்டிருக்கும். ஆனால், நீங்கள் /etc/apt/apt.conf.d/50unattended-upgrades-ல் Unattended-Upgrade::Automatic-Reboot-ஐ செயல்படுத்தியிருந்தால் ஒழிய, எதுவும் தானாக மறுதொடக்கம் ஆகாது.

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

இரண்டாவதாக, இந்த இடைவெளி சிக்கலுக்கான காரணத்தை மறைத்துவிடும். ஒரு server-ல் மார்ச் மாதம் kernel நிறுவப்பட்டு, ஜூன் மாதம் முற்றிலும் தொடர்பில்லாத ஒரு காரணத்திற்காக மறுதொடக்கம் செய்யப்படும்போது, அது இயங்காமல் போகலாம். பூட் (boot) ஆவதைத் தடுத்த அந்த மாற்றம் மூன்று மாதங்களுக்கு முன்பே நிகழ்ந்ததால், அன்று நீங்கள் செய்த எந்த மாற்றமும் அதற்குக் காரணமாக இருக்காது. நீங்கள் தற்போது சந்திக்கும் தோல்விக்குக் காரணமான kernel நிறுவப்பட்ட நிகழ்வை /var/log/apt/history.log-ல் கண்டறியலாம்.

நீங்கள் தேர்ந்தெடுக்கும் நாளில், console window-ஐத் திறந்து வைத்துக்கொண்டு, திட்டமிட்டு மறுதொடக்கம் செய்யுங்கள். இந்த ஒரே ஒரு பழக்கம், மர்மமான செயலிழப்பை இரண்டு நிமிட வேலையாக மாற்றிவிடும். ஆச்சரியங்கள் இல்லாத தானியங்கி முறை வேண்டுமென்றால், automatic installs-ஐ ஆன் செய்துவிட்டு, automatic reboots-ஐ ஆஃப் செய்து வையுங்கள். சரியான அமைப்புகளுக்கு Ubuntu-வில் unattended-upgrades-ஐ எவ்வாறு கட்டமைப்பது என்பதைப் பார்க்கவும். sudo apt-mark hold linux-image-generic மூலம் kernel தொகுப்புகளை நிறுத்தி வைப்பது (holding) அவற்றை முழுமையாகத் தடுத்துவிடும், அதே சமயம் kernel பாதுகாப்புத் திருத்தங்களையும் அது நிறுத்திவிடும். எனவே, இதை ஒரு பாதுகாப்பு நடவடிக்கையாகக் கருதாமல், நீங்கள் மேற்கொள்ளும் ஒரு சமரசமாகவே பார்க்க வேண்டும்.

FAQ

விசைப்பலகை (keyboard) இல்லாத VPS-ல் பழைய kernel-ஐ எவ்வாறு boot செய்வது?

வழங்குநரின் console-ஐ (VNC அல்லது serial) திறந்து, control panel மூலம் hard reset செய்யவும், ஏனெனில் உங்களால் முறையாக login செய்து reboot செய்ய முடியாது. கணினி restart ஆகும்போது, GRUB menu-வை நிறுத்த Esc-ஐத் தொடர்ந்து அழுத்தவும் அல்லது legacy BIOS boot-ல் Shift-ஐ அழுத்திப் பிடிக்கவும். "Advanced options for Ubuntu" என்பதைத் தேர்ந்தெடுத்து, புதிய kernel-க்குக் கீழே உள்ள பதிப்பைத் தேர்ந்தெடுக்கவும். Login prompt வந்தவுடன், நீங்கள் எந்த kernel-ல் இருக்கிறீர்கள் என்பதை உறுதிப்படுத்த uname -r-ஐயும், வேறு என்னென்ன நிறுவப்பட்டுள்ளன என்பதைப் பார்க்க 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 ஆகியவற்றை அமைக்கவும், menu serial console-லும் தெரிய GRUB_TERMINAL="console serial"-ஐச் சேர்க்கவும், பின்னர் sudo update-grub-ஐ இயக்கவும். grep -r TIMEOUT /etc/default/grub /etc/default/grub.d/ மூலம் சரிபார்க்கவும், ஏனெனில் அந்த directory-ல் உள்ள கோப்புகள் முதன்மை கோப்பிற்குப் பிறகு வாசிக்கப்பட்டு உங்கள் மாற்றங்களை மேலெழுதக்கூடும்.

/boot-ல் இடவசதியை உருவாக்க பழைய kernel-களை நீக்க வேண்டுமா?

மிகவும் பழையவற்றை நீக்கிவிட்டு, குறைந்தது இரண்டை வைத்திருக்கவும். /boot முழுமையாக நிரம்புவது ஒரு தோல்வி நிலையாகும், ஏனெனில் அப்போது initramfs உருவாக்கம் தோல்வியடையும், மேலும் உங்களிடம் இயங்கக்கூடிய image இல்லாத kernel மட்டுமே எஞ்சியிருக்கும். uname -r-ஐச் சரிபார்த்த பிறகு, சரியான package பெயரைக் கொண்டு நீக்கவும் (purge), அப்போதுதான் இயங்கிக்கொண்டிருக்கும் kernel நீக்கப்படாது. Headless கணினியில் மொத்தமாக sudo apt autoremove --purge செய்வதைத் தவிர்க்கவும், ஏனெனில் protected-kernel பட்டியல் ஒவ்வொரு kernel மாற்றத்தின் போதும் மீண்டும் உருவாக்கப்படும்; தவறான நேரத்தில் இயக்கினால், உங்களிடம் ஒரே ஒரு kernel மட்டுமே எஞ்சி, menu-வில் fallback entry இல்லாமல் போகலாம்.

unattended-upgrades எனது boot-ஐப் பாதிக்குமா?

இது boot ஆகத் தவறும் ஒரு kernel-ஐ நிறுவக்கூடும், ஆனால் /etc/apt/apt.conf.d/50unattended-upgrades-ல் Unattended-Upgrade::Automatic-Reboot என்பது true என அமைக்கப்பட்டிருந்தால் ஒழிய, அது கணினியை restart செய்யாது. பொதுவாக இது தாமதமான தோல்வியாகவே வெளிப்படும்: தானியங்கி run-ன் போது kernel பதிவிறக்கப்படும், /var/run/reboot-required தோன்றும், ஆனால் பல வாரங்களுக்குப் பிறகு நீங்கள் அடுத்தமுறை reboot செய்யும்போதுதான் சிக்கல் வெளிப்படும். Console-ஐத் திறந்து வைத்துக்கொண்டு திட்டமிட்டு reboot செய்யவும், நீங்கள் boot செய்யும் kernel எந்த run-ல் நிறுவப்பட்டது என்பதைக் கண்டறிய /var/log/apt/history.log-ஐப் படிக்கவும்.