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

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

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

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

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

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

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

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

boot menu-வை அடைய நீங்கள் பெரும்பாலும் control panel மூலம் hard reset செய்ய வேண்டியிருக்கும், ஏனெனில் உங்களால் login செய்ய முடியாத இயந்திரத்தில் sudo reboot கட்டளையை இயக்க முடியாது. hard reset என்பது மின்சாரத்தைத் துண்டிப்பதற்குச் சமம். இதனால் filesystem முறையற்ற shutdown-க்கு உள்ளாகும், எனவே அடுத்த முறை 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 மீண்டும் இயங்கும் நிலைக்கு வரும். நீங்கள் எந்தப் பதிப்பில் உள்ளீர்கள் என்பதை உறுதிப்படுத்தி, அந்த எண்களைக் குறித்துக் கொள்ளவும்.

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 இல்லாத ஒரு server-ல், அந்த காத்திருப்பு முடிவுக்கு வராது. உங்கள் 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"

பின்பு அதைச் செயல்படுத்தி, உங்கள் மாற்றம் நிலைத்திருக்கிறதா என்று சரிபார்க்கவும். ஏனெனில் /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 செய்திகள் ஓடும், பிறகு நீங்கள் ஒரு busybox shell-க்குச் செல்வீர்கள், அதன் prompt (initramfs) என்று இருக்கும், அல்லது root filesystem-ஐ mount செய்ய முடியவில்லை என்ற panic செய்தியுடன் boot முடிவடையும். kernel load ஆகிவிட்டது. initramfs என்பது உங்கள் உண்மையான root filesystem-ஐக் கண்டறிந்து mount செய்யும் சிறிய தற்காலிக root ஆகும், அது disk-ஐக் கண்டறியவில்லை. Ubuntu-வில், இந்த shell-க்கு முன்னதாக root device-க்காகக் காத்திருப்பதை நிறுத்துவது பற்றிய செய்தி வரும், அது தேடிய UUID-ஐக் குறிப்பிடும். அந்த UUID-ஐ நகலெடுத்து, பின்னர் blkid வெளியீட்டுடன் ஒப்பிடவும்.

logical volume ஒருபோதும் தோன்றவில்லை. இது முந்தைய வகையின் ஒரு குறிப்பிட்ட காரணியாகும். (initramfs) prompt-ல், ls /dev/mapper என்பதை இயக்கவும். control மட்டுமே இருந்தால், எந்த LVM (logical volume manager) volume-ம் செயல்படுத்தப்படவில்லை என்று அர்த்தம், எனவே root device இன்னும் இல்லை. volume group-களைக் கையால் தொடங்கவும்:

lvm vgchange -ay
ls /dev/mapper
exit

exit கட்டுப்பாட்டை மீண்டும் initramfs script-க்கு வழங்குகிறது, அது mount-ஐ மீண்டும் முயற்சிக்கும். கணினி boot ஆனால், புதிய initramfs-ல் LVM பகுதிகள் இல்லை என்று அர்த்தம், எனவே kernel-ஐத் தொடுவதற்குப் பதிலாக அந்த image-ஐ மீண்டும் உருவாக்குவதே தீர்வாகும்.

Linux-லிருந்து எதுவும் வரவில்லை. console-ல் firmware உரை, ஒரு UEFI (unified extensible firmware interface) shell, kernel வெளியீடு இல்லாத வெற்றுத் திரை அல்லது 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

மேம்படுத்தலின் போது /boot/efi mount செய்யப்படாமல் இருப்பது UEFI கணினிகளில் பொதுவான காரணமாகும், ஏனெனில் EFI system partition-ஐப் பராமரிக்கும் packages சாதாரண காலியான கோப்பகத்தில் (directory) எழுதிவிடும். அந்த entry disk-ல் உள்ளவற்றுடன் பொருந்தாத வரை, 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 நிறுவப்பட்டன மற்றும் எப்போது நிறுவப்பட்டன என்பதை history.log துல்லியமாகப் பட்டியலிடும், இது எதில் மாற்றம் ஏற்பட்டது என்ற குழப்பத்தைத் தீர்க்கும்.

/boot நிரம்பியிருந்தால் முதலில் இடத்தை விடுவிக்கவும், பின்னர் உங்களுக்குத் தேவையான version-க்கான image-ஐ மீண்டும் உருவாக்கி menu-வைப் புதுப்பிக்கவும். கீழே உள்ள 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-ஐ மீண்டும் நிறுவவும்:

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 தலைப்புகளைப் பட்டியலிட்டு, ஒன்றைத் துல்லியமாகக் குறிப்பிடவும்:

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

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-வில் ஒரு entry-ஐத் தேர்ந்தெடுப்பதற்கும், 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 செய்யத் தேவையில்லாத ஒரே மீட்பு வழியாகும் (recovery path). இதை restore செய்யும்போது, பழைய kernel இயல்பானதாக (default) இருந்த நிலைக்கு வட்டு (disk) திரும்பும்; எனவே, console-ஐத் திறந்து வைத்துக்கொண்டு நீங்கள் மீண்டும் மேம்படுத்தலை முயற்சி செய்யலாம். இயங்கிக்கொண்டிருக்கும் கணினியின் snapshot-கள் 'crash consistent' முறையில் அமையும்; அதாவது, மின்சாரம் திடீரென துண்டிக்கப்பட்டது போன்ற நிலையில் வட்டு சேமிக்கப்படும். எனவே, உங்கள் provider offline snapshot-ஐ ஆதரித்தால், முதலில் server-ஐ shutdown செய்யுங்கள். snapshot என்பது backup அல்ல; ஏனெனில், அது பொதுவாக நகலெடுக்கப்படும் volume இருக்கும் அதே உள்கட்டமைப்பிலேயே சேமிக்கப்படுகிறது. VPS snapshot மற்றும் உண்மையான backup-களுக்கு இடையிலான வேறுபாட்டை புரிந்துகொள்வது, kernel-ஐ விடப் பெரிய பாதிப்பு ஏற்படும்போது எது உங்களைக் காப்பாற்றும் என்பதைத் தீர்மானிக்க உதவும்.

kernel, initramfs கருவிகள், bootloader மற்றும் GRUB config ஆகிய அனைத்தும் ஒரே நேரத்தில் மாறும் release upgrade-ன் போது இது மிக முக்கியமானது. Ubuntu 24.04-லிருந்து 26.04-க்கு மேம்படுத்தும் பணியைத் தொடங்குவதற்குச் சரியாக முன்னதாகவே snapshot எடுங்கள்; முந்தைய நாள் இரவே எடுக்க வேண்டாம். அப்போதுதான் நீங்கள் மாற்றப்போகும் கணினியின் நிலையும், restore point-ம் சரியாகப் பொருந்தும். உங்கள் server-ல் இன்னும் அந்த மேம்படுத்தல் வழங்கப்படவில்லை என்றால், அதற்குத் தவறான அமைப்பு (broken setup) காரணமல்ல, மாறாக scheduling தான் காரணம். ஏனெனில், LTS-லிருந்து LTS-க்கு மாறுவதற்கான வாய்ப்பு முதல் point release-ஆன 26.04.1-ல் மட்டுமே திறக்கப்படும்.

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

Ubuntu-வின் unattended-upgrades பாதுகாப்பு மேம்படுத்தல்களைக் கேட்காமலேயே நிறுவுகிறது. 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-ஐ செயல்படுத்தியிருந்தால் ஒழிய, எதுவும் தானாக மறுதொடக்கம் ஆகாது.

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

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

நீங்கள் தேர்ந்தெடுத்த நாளில், console window-ஐத் திறந்து வைத்துக்கொண்டு, திட்டமிட்டு reboot செய்யுங்கள். இந்த ஒரே பழக்கம், மர்மமான செயலிழப்பை இரண்டு நிமிட வேலை மாற்றமாக மாற்றும். ஆச்சரியங்கள் இல்லாத automation உங்களுக்குத் தேவைப்பட்டால், automatic installs-ஐ ஆன் செய்துவிட்டு, automatic reboots-ஐ ஆஃப் செய்து வையுங்கள். சரியான அமைப்புகளுக்கு Ubuntu-வில் unattended-upgrades-ஐ எவ்வாறு configure செய்வது என்பதைப் பார்க்கவும். sudo apt-mark hold linux-image-generic மூலம் kernel packages-ஐ நிறுத்தி வைப்பது அவற்றை முழுமையாகத் தடுத்துவிடும். அதே நேரத்தில் 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-க்குக் கீழே உள்ள entry-ஐத் தேர்வு செய்யவும். 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-ல் உள்ள கோப்புகள் முதன்மை கோப்பிற்குப் பிறகு வாசிக்கப்பட்டு உங்கள் மாற்றத்தை மேலெழுதக்கூடும் (override).

/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-ஐ வாசிக்கவும்.