Ubuntu VPS-ல் குறிப்பிட்ட Kernel-ஐ Boot செய்வது எப்படி?
Ubuntu cloud image-ல் GRUB_DEFAULT வேலை செய்யாதபோது, உங்கள் சர்வரின் சரியான menu entries-ஐ கண்டறிந்து, rescue console தேவையின்றி அடுத்த boot-ஐ பாதுகாப்பாக மாற்றுவது எப்படி?
உங்கள் VPS எந்த kernel-ஐ boot செய்கிறது என்பதை எது தீர்மானிக்கிறது
உங்கள் VPS அடுத்ததாக எந்த kernel-ஐ boot செய்ய வேண்டும் என்பதை /boot/grub/grub.cfg என்ற ஒரு உருவாக்கப்பட்ட கோப்பு தீர்மானிக்கிறது. அந்தக் கோப்பை நீங்கள் நேரடியாகத் திருத்தக்கூடாது. அதற்குப் பதிலாக, அதன் உள்ளீடுகளைத் திருத்தி, கோப்பை மீண்டும் உருவாக்க வேண்டும். Ubuntu cloud image-ல், அந்த உள்ளீடுகளில் ஒன்று image வழங்குநரிடமிருந்து வருகிறது. இது menu தேர்வுகளைச் செல்லாததாக்கிவிடும். இதனால்தான், ஒரு laptop-ல் வேலை செய்யும் GRUB_DEFAULT=1 மற்றும் அதைத் தொடர்ந்து update-grub ஆகிய இரண்டு படிகளும், வாடகைக்கு எடுக்கப்பட்ட server-ல் எந்த மாற்றத்தையும் செய்வதில்லை.
இந்த வரிசையில் செயல்படுங்கள். எந்த kernel-ஐத் தேர்ந்தெடுக்க வேண்டும் என்பது உங்கள் கட்டுப்பாட்டில் உள்ளதா என்பதை உறுதிப்படுத்தவும். வழங்குநர் சேர்த்தவை உட்பட, அனைத்து உள்ளீட்டுக் கோப்புகளையும் வாசிக்கவும். உருவாக்கப்பட்ட வெளியீட்டை வாசித்து, அதில் உள்ள entries-களின் எண்ணிக்கையைச் சரிபார்க்கவும். அதன் பிறகு மட்டுமே pinning முறையைத் தேர்ந்தெடுக்கவும். SSH மூலம் மட்டுமே அணுகக்கூடிய ஒரு machine-ல் இதைத் தவறாகச் செய்தால், rescue console-ஐப் பயன்படுத்த வேண்டிய சூழல் ஏற்படும். எனவே, பாதுகாப்பான தீர்வுகள் இந்தப் பக்கத்தின் இறுதியில் கொடுக்கப்பட்டுள்ளன; பெரும்பாலும் அவைதான் சரியான தீர்வுகளாக இருக்கும்.
முதலில் kernel உங்களுடையதுதானா என்பதை உறுதிப்படுத்தி அதை pin செய்யவும்
uname -r
systemd-detect-virt
ls -1 /boot/vmlinuz-*systemd-detect-virt என்பது kvm, qemu அல்லது xen என அச்சிடப்பட்டால், நீங்கள் உங்களுடைய சொந்த kernel-ஐ இயக்குகிறீர்கள் என்று அர்த்தம்; எனவே கீழே உள்ள அனைத்தும் உங்களுக்குப் பொருந்தும். lxc அல்லது openvz என அச்சிடப்பட்டால், உங்கள் server host-ன் kernel-ஐப் பகிர்ந்து கொள்கிறது என்று அர்த்தம்; எனவே உங்களுக்கென பிரத்யேக bootloader இல்லை, pin செய்வதற்கு எதுவும் இல்லை. அந்தச் சூழலில், uname -r காட்டும் பதிப்பு /boot/vmlinuz-*-ல் இருக்காது. ஏனெனில், இயங்கும் kernel host-க்குச் சொந்தமானது, உங்கள் disk-ல் உள்ள எந்த அமைப்பும் அதை மாற்ற முடியாது.
ls -1 /boot/vmlinuz-* என்பது நீங்கள் தேர்ந்தெடுக்கக்கூடிய kernel-களின் உண்மையான பட்டியல் ஆகும். அதில் ஒரே ஒரு வரி மட்டுமே இருந்தால், முந்தைய kernel ஏற்கனவே நீக்கப்பட்டுவிட்டது என்று அர்த்தம்; எந்த bootloader அமைப்பாலும் அதை மீண்டும் கொண்டுவர முடியாது. இது பொதுவாக autoremove செயல்பாட்டின் போது நடக்கும். முக்கியமான server-களில் Ubuntu-வில் பழைய kernel-களை நீக்குவது குறித்துப் புரிந்துகொள்வது அவசியம்.
நீங்கள் திருத்தும் கோப்பு GRUB வாசிக்கும் கோப்பு அல்ல
/etc/default/grub என்பது plain shell variable assignments-ஐக் கொண்டிருக்கும். இது ஒரு உள்ளீடு (input). /boot/grub/grub.cfg என்பது வெளியீடு (output), இது # DO NOT EDIT THIS FILE மற்றும் அதற்கான காரணத்துடன் தொடங்குகிறது. நீங்கள் வெளியீட்டுக் கோப்பில் எழுதும் எதையும், அடுத்த முறை kernel package நிறுவப்படும்போதோ அல்லது நீக்கப்படும்போதோ அது அழிந்துவிடும், ஏனெனில் அந்த package scripts-கள் அதை மீண்டும் உருவாக்குகின்றன.
cat /usr/sbin/update-grubupdate-grub என்பது ஒரு wrapper ஆகும். இது grub-mkconfig -o /boot/grub/grub.cfg-ஐ இயக்குகிறது; இது variables-ஐ வாசித்து, /etc/grub.d/-ல் உள்ள ஒவ்வொரு script-ஐயும் இயக்கி, முடிவை எழுதுகிறது. இரண்டு கட்டளைகள், ஒரே திசை: உள்ளீடுகள் உள்ளே செல்கின்றன, grub.cfg வெளியே வருகிறது.
உங்கள் அமைப்பை எது மீறுகிறது: /etc/default/grub.d
grep -rn '^[^#]' /etc/default/grub /etc/default/grub.d/இரண்டாவது பாதை பலரால் கவனிக்கப்படாத ஒரு பகுதியாகும். grub-mkconfig முதலில் /etc/default/grub-ஐ source செய்கிறது, அதன் பிறகு /etc/default/grub.d/-ல் உள்ள ஒவ்வொரு *.cfg கோப்பையும் glob வரிசையில் source செய்கிறது. இதைச் செய்யும் குறியீட்டைப் படிக்கவும்:
grep -n 'default/grub' /usr/sbin/grub-mkconfigSourcing என்பது ஒரு சாதாரண shell செயல்முறை என்பதால், கடைசியாகச் செய்யப்படும் assignment-தான் இறுதியானது. Ubuntu cloud images அந்த directory-ல் சில கோப்புகளைக் கொண்டுள்ளன. அவை உங்கள் கோப்பு வாசிக்கப்பட்ட பிறகு, timeout மற்றும் kernel command line போன்றவற்றை அமைக்கின்றன. /etc/default/grub-ல் உள்ள உங்கள் GRUB_TIMEOUT=10, vendor கோப்பு ஒன்றால் சிறிது நேரத்தில் 0 என மாற்றியமைக்கப்படுகிறது. மேலே உள்ள grep கட்டளை உங்கள் image-ல் உள்ள துல்லியமான assignment-களைக் காட்டும், எனவே இந்த வாக்கியத்தை மட்டும் நம்பாமல் அவற்றைச் சரிபார்க்கவும்.
இதிலிருந்து பெறப்படும் நடைமுறை விதி இதுதான்: /etc/default/grub-ஐத் திருத்துவதற்குப் பதிலாக, /etc/default/grub.d/99-local.cfg போன்ற வரிசையில் கடைசியாக வரும் ஒரு கோப்பில் உங்கள் அமைப்புகளைச் சேர்க்கவும். அப்போதுதான் image-உடன் வரும் எந்த அமைப்பும் உங்கள் அமைப்பிற்குப் பிறகு இயங்காது.
GRUB_FORCE_PARTUUID ஏன் menu selection-ஐ பயனற்றதாக்குகிறது
grep -rn GRUB_FORCE_PARTUUID /etc/default/grub /etc/default/grub.d/
grep -n GRUB_FORCE_PARTUUID /etc/grub.d/10_linux
sudo grep -n 'root=PARTUUID' /boot/grub/grub.cfgGRUB_FORCE_PARTUUID, boot ஆகும்போது filesystem UUID-ஐத் தேடுவதற்குப் பதிலாக, root filesystem-ஐ partition UUID மூலம் கண்டறிந்து, அதை நேரடியாக kernel command line-ல் root=PARTUUID=... என எழுதுமாறு generator-க்குக் கட்டளையிடுகிறது. இது ஒரு disk image-ஐ அது உருவாக்கப்பட்ட வன்பொருளைத் தவிர மற்றவற்றிலும் நம்பகத்தன்மையுடன் boot செய்ய வைப்பதால், image vendor இதை அமைக்கிறது. இரண்டாவது grep, /etc/grub.d/10_linux-ல் அந்த variable-ஐச் செயல்படுத்தும் குறியீட்டைக் காட்டுகிறது. அந்த script உங்கள் disk-லேயே உள்ளது, உங்கள் image என்ன செய்கிறது என்பதைத் தீர்மானிக்கும் அதிகாரம் அதற்குத்தான் உண்டு.
இதன் விளைவுதான் இங்கே முக்கியமானது: அந்தப் பாதையில், generator நிறுவப்பட்ட kernel-களின் முழுப் பட்டியலுக்குப் பதிலாக, ஒரு நேரடி boot entry-ஐ மட்டுமே உருவாக்குகிறது. இறுதியில் உங்களுக்குக் கிடைத்தவற்றைக் கணக்கிடுங்கள்.
sudo grep -cE '^\s*(menuentry|submenu) ' /boot/grub/grub.cfg
sudo grep -nE '^\s*(menuentry|submenu) ' /boot/grub/grub.cfgஎண்ணிக்கை 1 ஆக இருந்தால், தேர்ந்தெடுப்பதற்கு இரண்டாவது entry எதுவும் இல்லை, எனவே GRUB_DEFAULT=1 இல்லாத ஒரு entry-ஐக் குறிப்பிடுகிறது. GRUB-ஆல் அதைத் தீர்க்க முடியாது, எனவே அது முதல் entry-ஐ boot செய்கிறது; அது நீங்கள் தவிர்க்க முயன்ற புதிய kernel ஆகும். grub-set-default-ம் உதவாது, ஏனெனில் default என்பது பிழையான பகுதி அல்ல. நீங்கள் தேர்ந்தெடுக்க முயலும் menu ஒருபோதும் உருவாக்கப்படவில்லை.
முழு menu-வையும் மீண்டும் பெற, vendor கோப்பை நகர்த்திவிட்டு, மாற்றங்களைச் செய்வதற்கு முன் முடிவைப் பார்க்கவும். -o இல்லாமல் grub-mkconfig-ஐ இயக்கினால், அது standard output-ல் மட்டுமே எழுதும், disk-ல் எதையும் மாற்றாது.
sudo grub-mkconfig 2>/dev/null | grep -cE '^\s*(menuentry|submenu) '
sudo mkdir -p /root/grub-backup
sudo mv /etc/default/grub.d/<the file your grep named> /root/grub-backup/
sudo grub-mkconfig 2>/dev/null | grep -cE '^\s*(menuentry|submenu) 'எண்ணிக்கை 1-லிருந்து பலவாக உயர்ந்தால், forcing நீக்கப்பட்ட பிறகு entries தோன்றும் என்று அர்த்தம். இன்னும் எதுவும் எழுதப்படவில்லை. இரண்டாவது எண்ணிக்கை சரியாகத் தெரியவில்லை என்றால், கோப்பை மீண்டும் பழைய இடத்திற்கே கொண்டு வாருங்கள், ஏனெனில் forced PARTUUID மூலமே உங்கள் provider-ன் image அதன் root filesystem-ஐக் கண்டறிகிறது; அதை நீக்கினால் machine தேடல் பாதைக்கு (search path) மாறிவிடும். update-grub-ஐ உண்மையாக இயக்குவதற்கு முன் ஒரு snapshot எடுக்கவும்.
ஒரு மோசமான kernel-லிருந்து தப்பிப்பதே உங்கள் ஒரே நோக்கம் என்றால், இத்துடன் நிறுத்திவிட்டு கீழே உள்ள பாதுகாப்பான விருப்பங்களைப் பயன்படுத்தவும். ஒருமுறை மேம்படுத்தியதால் ஏற்பட்ட சிக்கலைத் தவிர்க்க, remote server-ல் boot menu-வை மீண்டும் உருவாக்குவது, அந்தச் சிக்கலை விட அதிக ஆபத்தானது.
ஏன் entry எண்களைக் கொண்டு pin செய்வது தவறானது
GRUB_DEFAULT ஒரு எண், தலைப்பு அல்லது identifier-ஐ ஏற்கும். எண்கள் 0-லிருந்து தொடங்கும் மேல்நிலை entry-களைக் குறிக்கும். ஒரு nested entry-க்கு > பிரிப்பானாகப் பயன்படுத்தப்படுகிறது, எனவே GRUB_DEFAULT="1>2" என்பது 1-வது குறியீட்டில் உள்ள submenu-க்குள் இருக்கும் 2-வது குறியீட்டில் உள்ள entry-ஐக் குறிக்கும்.
குறியீடுகள் (Indices) மாறக்கூடியவை. 10_linux kernels-ஐப் புதியவற்றிலிருந்து பழையவை என்ற வரிசையில் பட்டியலிடும். எனவே, ஒரு புதிய kernel-ஐ நிறுவும்போது பழைய entry-கள் அனைத்தும் ஒரு இடம் கீழே தள்ளப்படும்; ஒரு kernel-ஐ நீக்கும்போது அவை மேலே நகர்த்தப்படும். நீங்கள் கவனமாக அமைத்த 1>2 அந்த மாற்றத்திற்குப் பிறகும் செயல்படும். ஆனால், அது இப்போது வேறொரு kernel-ஐக் குறிக்கும். எந்தப் பிழையும் வராது, எச்சரிக்கையும் வராது; reboot செய்த பிறகுதான் நீங்கள் இதைக் கண்டறிய முடியும்.
Identifiers மாறாது, ஏனெனில் ஒவ்வொன்றும் kernel version-ஐக் கொண்டிருக்கும். உங்களுடையதை இவ்வாறு வாசிக்கவும்:
sudo awk -F"'" '/menuentry_id_option/ {print $2, "==>", $4}' /boot/grub/grub.cfgவெளியீட்டின் முதல் சில வரிகளைப் புறக்கணிக்கவும், அவை header-ல் வரையறுக்கப்படும் variable-கள் ஆகும். அதற்குப் பிறகு, இடது பக்கம் பயனர் பார்க்கும் தலைப்பு இருக்கும், வலது பக்கம் நீங்கள் கருவிகளுக்கு வழங்க வேண்டிய identifier இருக்கும். ஒரு submenu-க்குள் இருக்கும் entry-க்கு, submenu identifier மற்றும் entry identifier ஆகியவற்றை > கொண்டு இணைக்கவும். அந்த வரிசை, எண் வடிவம் போலவே இருக்க வேண்டும்.
grub-reboot மூலம் முந்தைய kernel-ஐ ஒருமுறை மட்டும் boot செய்தல்
தொலைதூரத்தில் உள்ள server-ல் ஒருமுறை மட்டும் boot செய்வது சரியான அணுகுமுறையாகும், ஏனெனில் இது தானாகவே பழைய நிலைக்குத் திரும்பிவிடும். grub-reboot கட்டளையானது next_entry மதிப்பை /boot/grub/grubenv கோப்பில் எழுதும். GRUB அந்த மாறியைப் படித்து, அதை அழித்துவிட்டு, எதையும் boot செய்வதற்கு முன்பே அந்த மாற்றத்தைச் சேமித்துவிடும். எனவே, kernel செயலிழந்தால் (panic), அடுத்த boot-ல் அது மீண்டும் முயற்சிக்கப்படாது. உங்களுக்கு ஒரு வாய்ப்பு மட்டுமே கிடைக்கும், அதன் பிறகு machine தானாகவே அதன் இயல்பான default நிலைக்குத் திரும்பிவிடும்.
முதலில், உங்கள் உருவாக்கப்பட்டுள்ள config அந்த மாறியைப் படிக்கிறதா என்பதை உறுதிப்படுத்தவும்:
sudo grep -n -B2 -A5 'next_entry' /boot/grub/grub.cfgஅதில் ஒரு load_env வரியும், next_entry-லிருந்து default-ஐ அமைக்கும் ஒரு தொகுதியும் இருக்க வேண்டும். grep எந்த முடிவையும் காட்டவில்லை என்றால், உங்கள் image boot-ன் போது grubenv-ஐப் படிக்காது என்று அர்த்தம். எனவே, grub-reboot கட்டளையை shell-ல் கொடுத்தாலும், bootloader அதை நிராகரித்துவிடும். இது முந்தைய பகுதியில் காட்டப்பட்ட அதே கட்டாய நேரடி boot பாதையாகும், இது இரண்டாவது இடத்திலும் வெளிப்படுகிறது.
sudo grub-reboot '<the identifier you copied>'
sudo grub-editenv listgrub-editenv list இப்போது நீங்கள் கொடுத்த அதே மதிப்பை உள்ளடக்கிய ஒரு next_entry= வரியைக் காட்ட வேண்டும். உங்கள் provider-ன் console-ஐ browser tab-ல் திறந்து, reboot செய்து முடிவைச் சரிபார்க்கவும்.
sudo rebootuname -runame -r பழைய பதிப்பைக் காட்டினால், pin சரியாக வேலை செய்கிறது என்று அர்த்தம். புதிய பதிப்பைக் காட்டினால், identifier சரியாகத் தீர்க்கப்படவில்லை அல்லது grubenv படிக்கப்படவில்லை என்று அர்த்தம். எப்படியிருந்தாலும் machine இயங்கத் தொடங்கிவிடும், இதுவே இந்த one-shot முறையைப் பயன்படுத்துவதன் நோக்கமாகும்.
GRUB_DEFAULT=saved மூலம் தேர்வை நிலைப்படுத்துதல்
GRUB_DEFAULT=saved ஆனது grubenv-ல் உள்ள saved_entry-லிருந்து இயல்புநிலை மதிப்பை எடுக்கச் செய்கிறது, மேலும் அந்த மதிப்பை நீங்கள் grub-set-default மூலம் அமைக்கிறீர்கள். இது kernel நிறுவல்களின் போதும் மாறாமல் இருக்கும், ஏனெனில் update-grub ஆனது grub.cfg-ஐ மட்டுமே மீண்டும் எழுதும், grubenv-ஐ ஒருபோதும் மாற்றாது.
echo 'GRUB_DEFAULT=saved' | sudo tee /etc/default/grub.d/99-local.cfg
sudo update-grub
sudo grub-set-default '<the identifier you copied>'
sudo grub-editenv list
sudo grep -n 'set default' /boot/grub/grub.cfgகடைசி கட்டளை set default="${saved_entry}"-ஐ அச்சிட வேண்டும். அது set default="0"-ஐ அச்சிட்டால், உங்கள் கோப்பிற்குப் பிறகு ஏதோ ஒன்று GRUB_DEFAULT-ஐ மீண்டும் ஒரு குறிப்பிட்ட மதிப்பிற்கு மாற்றியுள்ளது என்று அர்த்தம். எனவே /etc/default/grub.d/-ஐ மீண்டும் பட்டியலிட்டு, 99-local.cfg வரிசையில் கடைசியாக வருகிறதா என்பதைச் சரிபார்க்கவும்.
GRUB_SAVEDEFAULT=true என்பது வேறு ஒரு அமைப்பாகும், இதை இதனுடன் குழப்பிக் கொள்வது எளிது. இது நீங்கள் கடைசியாக boot செய்ததை புதிய இயல்புநிலையாகச் சேமிக்கும், எனவே இயல்புநிலை என்பது கடைசியாக வெற்றிகரமாக boot ஆனதையே குறிக்கும். ஒரு server-ல், இது கவனிக்கப்படாத reboot-ன் போது உங்கள் pin-ஐ தானாகவே மாற்றிவிடக்கூடும். உங்களுக்கு அது தேவைப்படாவிட்டால் இதைத் தவிர்க்கவும்.
identifier மூலம் pin செய்வது ஒரு வகையில் தோல்வியடையலாம். அது குறிப்பிடும் kernel-ஐ நீக்கினால், அந்த identifier-ஆல் கண்டறிய முடியாமல் போகும், இது உங்களை மீண்டும் முதல் entry-க்குத் தள்ளிவிடும். எனவே அந்த package-ஐ hold செய்யவும் அல்லது அந்த kernel-ஐ autoremove பட்டியலில் இருந்து நீக்கவும்.
வழங்குநர் கன்சோலில் மெனுவைக் கொண்டு வருதல்
ஊடாடும் முறையில் (interactively) தேர்வு செய்ய, மெனு திரையில் தெரிய வேண்டும். ஆனால், கிளவுட் இமேஜ்கள் (cloud images) இதை மறைத்துவிடும். இவற்றை வரிசைப்படுத்தலில் கடைசியாக இருக்கும் கோப்பில் சேர்த்துவிட்டு, பின் sudo update-grub-ஐ இயக்கவும்.
GRUB_TIMEOUT=10
GRUB_TIMEOUT_STYLE=menu
GRUB_RECORDFAIL_TIMEOUT=10GRUB_TIMEOUT_STYLE=hidden மற்றும் GRUB_TIMEOUT=0 ஆகியவற்றைச் சேர்த்தாலும் எதுவும் தெரிவதில்லை. கன்சோலைப் பார்ப்பவர்களுக்கு, கர்னல் செய்திகள் உடனடியாகத் தொடங்குவது போலத் தோன்றும், எனவே பூட்லோடர் (bootloader) தவிர்க்கப்பட்டதாக அவர்கள் முடிவெடுப்பார்கள். GRUB_RECORDFAIL_TIMEOUT என்பது பூட் முழுமையடையாதபோது பயன்படுத்தப்படும் தனித்த காலாவதி நேரமாகும் (timeout). கிளவுட் இமேஜ்கள் இதையும் 0 என அமைப்பதால், பூட் ஆகத் தவறிய சர்வர் கூட நிற்காமல் தொடர்ந்து இயங்குகிறது.
உங்கள் வழங்குநர் கிராபிக் கன்சோலுக்குப் பதிலாக சீரியல் கன்சோலை (serial console) வழங்கியும் உங்களுக்கு எதுவும் தெரியவில்லை என்றால், GRUB உங்களால் பார்க்க முடியாத ஒரு டெர்மினலுக்கு எழுதுகிறது என்று அர்த்தம். இரண்டு வரிகளையும் ஒன்றாகச் சேர்க்கவும்; ஏனெனில் முதலாவது வெளியீட்டைத் தேர்ந்தெடுக்கிறது, இரண்டாவது போர்ட்டை (port) உள்ளமைக்கிறது:
GRUB_TERMINAL="console serial"
GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1"இனி ஒவ்வொரு பூட் தொடக்கத்திலும் பத்து வினாடிகள் கூடுதலாகச் சேர்க்கப்படும். உங்கள் வேலை முடிந்ததும் காலாவதி நேரத்தை மீண்டும் 0 என அமைக்கவும்.
Bootloader-ஐத் திருத்துவதை விட பாதுகாப்பான விருப்பங்கள்
SSH வழியாக மட்டுமே அணுகக்கூடிய ஒரு கணினியில் bootloader உள்ளீட்டை மாற்றுவது, இந்தப் பக்கத்தில் உள்ள மிக அதிக ஆபத்துள்ள செயலாகும். இதைவிட எளிமையான தீர்வுகள் உள்ளன, அவை பெரும்பாலும் உண்மையான சிக்கலைத் தீர்த்துவிடும்.
Kernel packages-ஐ நிறுத்தி வைக்கவும் (Hold). "புதிய kernel-ஐ எனக்கு வழங்க வேண்டாம்" என்பதே உங்கள் நோக்கம் என்றால், அதை bootloader-க்குச் சொல்வதற்குப் பதிலாக package manager-க்குச் சொல்லுங்கள்.
apt list --installed 2>/dev/null | grep -E '^linux-(image|headers|generic|virtual|kvm|aws|azure|gcp|oracle)'
sudo apt-mark hold linux-image-virtual linux-headers-virtual
apt-mark showholdமுதல் கட்டளை எதைக் காட்டுகிறதோ அந்தப் பெயர்களையே பயன்படுத்துங்கள், ஏனெனில் cloud images பொதுவாக generic-க்கு பதிலாக virtual அல்லது kvm வகையையே நிறுவுகின்றன. ஒரு image புதுப்பிப்பின் போது புதிய kernel வந்திருந்தால், release மாறியதாக நீங்கள் கருதினால், அது தவறு. ஏனெனில் a point release is the updates you already have rolled into new install media என்பது ஏற்கனவே உங்களுக்கு வழங்கப்பட்ட அப்டேட்களின் தொகுப்புதான், அது ஏற்கனவே patch செய்யப்பட்ட server-க்கு புதிதாக எதையும் தருவதில்லை. நிறுத்தி வைக்கப்பட்ட (held) package-ஐ apt upgrade தவிர்க்கும், அது The following packages have been kept back: மூலம் அதை அறிவிக்கும், மேலும் unattended upgrades on Ubuntu-வும் அதைத் தவிர்க்கும். இதில் ஒரு சிக்கல் உள்ளது: நிறுத்தி வைக்கப்பட்ட kernel பாதுகாப்புத் திருத்தங்களைப் பெறாது. எனவே, இதை ஒரு குறிப்பிட்ட காலத்திற்கு மட்டும் செய்யும் தற்காலிக நடவடிக்கையாகக் கருதி, sudo apt-mark unhold மூலம் மீண்டும் விடுவிக்கவும். ஒரு kernel மோசமானது என்பதற்காக அல்லாமல், reboot செய்வதால் downtime ஏற்படும் என்பதால் நீங்கள் kernel அப்டேட்களைத் தவிர்க்கிறீர்கள் என்றால், அதற்கு live kernel patching on a VPS சிறந்த தீர்வாகும்.
Upgrade செய்வதற்கு முன் Snapshot எடுக்கவும். ஒரு snapshot சில நிமிடங்களில் கணினியை பழைய நிலைக்குக் கொண்டுவரும். இதில் console-ல் தட்டச்சு செய்ய வேண்டிய அவசியமில்லை, bootloader மாற்றங்கள் பாதியில் நின்றுவிடும் அபாயமும் இல்லை. Snapshot எடுங்கள், upgrade செய்யுங்கள், reboot செய்யுங்கள், சரிபார்க்கவும். புதிய kernel சரியாகச் செயல்படவில்லை என்றால், rollback செய்யுங்கள்; boot path அப்படியே பழையபடி இருக்கும்.
ஏற்கனவே முடங்கிய கணினிக்கு console அல்லது rescue image-ஐப் பயன்படுத்தவும். ஒரு server boot ஆகவில்லை என்றால், அதைச் சரிசெய்ய bootloader configuration-ஐத் திருத்துவது சரியான வழி அல்ல. அந்த மீட்பு முறை தனித்துவமானது: what to do when a VPS will not boot after a kernel update.
எவை செயலிழக்கும் மற்றும் நீங்கள் காணும் செய்திகள்
/boot/grub/grub.cfg-ல் நீங்கள் செய்த மாற்றம் மறைந்துவிட்டது. ஒரு kernel package நிறுவப்பட்டாலோ அல்லது நீக்கப்பட்டாலோ, அதன் maintainer script update-grub-ஐ இயக்கும், அப்போது அந்த கோப்பு உள்ளீடுகளிலிருந்து மீண்டும் உருவாக்கப்படும். # DO NOT EDIT THIS FILE தலைப்பு, இரண்டு உள்ளீட்டு இடங்களைக் குறிப்பிடுகிறது. அவற்றை மாற்றியமைக்கவும்.
grub-editenv: error: environment block too small. /boot/grub/grubenv காணவில்லை அல்லது பாதியில் துண்டிக்கப்பட்டுள்ளது. sudo grub-editenv /boot/grub/grubenv create மூலம் அதை மீண்டும் உருவாக்கி, உங்கள் மதிப்பை மீண்டும் அமைத்து, sudo grub-editenv list மூலம் உறுதிப்படுத்தவும்.
Pinned kernel, VFS: Unable to mount root fs on unknown-block(0,0) பிழையுடன் செயலிழக்கிறது (panic). நீங்கள் pin செய்த entry, வட்டில் இல்லாத ஒரு kernel அல்லது initrd-ஐக் குறிக்கிறது. பொதுவாக, package நீக்கப்பட்ட பிறகும் அதன் identifier grubenv-ல் அப்படியே இருப்பதால் இது நிகழ்கிறது. மீட்பு நடவடிக்கையாக, சரியாக இயங்கும் ஒரு entry மூலம் console-ல் boot செய்து, பழைய மதிப்பை நீக்க வேண்டும்.
Reboot செய்த பிறகும் uname -r மாறவில்லை. வரிசையாக மூன்றைச் சரிபார்க்கவும்: grub-editenv list இன்னும் உங்கள் மதிப்பைக் காட்டுகிறதா அல்லது அது பயன்படுத்தப்பட்டுவிட்டதா; நீங்கள் அமைத்த identifier தற்போதைய grub.cfg-ல் உள்ளதா; grub.cfg-ல் நீங்கள் அமைத்த variable-ஐ வாசிக்கும் set default வரி உள்ளதா. இந்த மூன்றில் ஒன்றுதான் இதற்கான காரணமாக இருக்கும்.
System crash-க்கு பிறகு menu தானாகவே தோன்றியது. GRUB, தோல்வியடைந்த boot முயற்சியை grubenv-ல் recordfail=1 எனப் பதிவு செய்கிறது. இது அடுத்த boot-ல் menu-வை கட்டாயப்படுத்தித் தோற்றுவிக்கும், இதன் மூலம் பயனர் தலையிட முடியும். இயந்திரம் சரியாக இயங்கிய பிறகு sudo grub-editenv /boot/grub/grubenv unset recordfail மூலம் அதை நீக்கவும்.
நினைவில் கொள்ள வேண்டிய ஒரே வாக்கியம்: நீங்கள் திருத்தும் கோப்பு GRUB வாசிக்கும் கோப்பு அல்ல. Cloud image-களில், இவை இரண்டிற்கும் இடையே உள்ள இடைவெளிதான் குழப்பத்திற்கு மூல காரணம். முதலில் உருவாக்கப்பட்ட config-ஐப் படிக்கவும். இந்தப் பக்கத்தில் உள்ள ஒவ்வொரு முடிவும், அந்தக் கோப்பில் உண்மையில் என்ன உள்ளது என்பதைப் பொறுத்தே அமைகிறது.
FAQ
GRUB_DEFAULT=1 என்று அமைத்தும் எனது VPS ஏன் பழைய kernel-லேயே boot ஆகிறது?
Ubuntu cloud image-களில் உருவாக்கப்படும் /boot/grub/grub.cfg பெரும்பாலும் ஒரே ஒரு boot entry-ஐ மட்டுமே கொண்டிருக்கும். எனவே, index 1 என்பது எதையும் குறிக்காது, GRUB தானாகவே முதல் entry-க்குத் திரும்பிவிடும். இதை sudo grep -cE '^\s*(menuentry|submenu) ' /boot/grub/grub.cfg மூலம் உறுதிப்படுத்தவும். அங்கு எண்ணிக்கை 1 என்று இருந்தால் அதுவே காரணம். /etc/default/grub.d/-க்குக் கீழ் உள்ள கோப்பில் image vendor அமைத்துள்ள GRUB_FORCE_PARTUUID தான் இதற்குக் காரணம்; இது முழுமையான kernel பட்டியலை உருவாக்குவதற்குப் பதிலாக, நேரடியாக boot ஆகும் பாதையைத் தேர்ந்தெடுக்கிறது. grep -rn GRUB_FORCE_PARTUUID /etc/default/grub /etc/default/grub.d/ மூலம் அந்தப் பட்டியலைக் கண்டறியலாம்.
முந்தைய kernel-ஐ ஒருமுறை மட்டும் boot செய்வது எப்படி?
உங்கள் grub.cfg-லிருந்து நகலெடுக்கப்பட்ட identifier-ஐப் பயன்படுத்தி sudo grub-reboot '<identifier>' கட்டளையை இயக்கவும். பிறகு, provider console-ஐத் திறந்து வைத்துக்கொண்டு reboot செய்யவும். GRUB boot ஆவதற்கு முன்பே next_entry-ஐ அழித்துவிடும், எனவே இந்தத் தேர்வு ஒருமுறை மட்டுமே பொருந்தும்; kernel ஏதேனும் பிழையினால் (panic) நின்றால், அது மீண்டும் முயற்சிக்கப்படாது. sudo grub-editenv list மூலம் அந்த மதிப்பு சரியாகப் பதிவாகியுள்ளதா என உறுதிப்படுத்தவும். இதைச் செய்வதற்கு முன் sudo grep -n next_entry /boot/grub/grub.cfg-ஐ இயக்கவும்; ஏனெனில், சில image-களின் configuration-ல் grubenv இல்லையென்றால், எந்தப் பிழையும் காட்டாமல் இந்தக் கட்டளை புறக்கணிக்கப்படும்.
Entry எண்ணைப் பயன்படுத்த வேண்டுமா அல்லது identifier-ஐப் பயன்படுத்த வேண்டுமா?
Identifier-ஐப் பயன்படுத்துவதே சிறந்தது. Entry எண்கள் என்பது 10_linux மூலம் புதியவை முதலில் வருமாறு வரிசைப்படுத்தப்பட்ட பட்டியலின் இடங்கள் ஆகும். எனவே, ஒரு kernel-ஐ நிறுவும்போதோ அல்லது நீக்கும்போதோ இந்த வரிசை மாறிவிடும். பழைய 1>2 தவறான entry-ஐச் சுட்டிக்காட்டினாலும், அது எந்த எச்சரிக்கையும் தராது. Identifier-களில் kernel version இருப்பதால், அவை நீங்கள் குறிப்பிட்ட kernel-ஐத் துல்லியமாகத் தேர்ந்தெடுக்கும் அல்லது பிழையைக் காட்டும். sudo grep -n menuentry_id_option /boot/grub/grub.cfg மூலம் பட்டியலைப் பார்த்து, ஒவ்வொரு entry வரியிலும் உள்ள மேற்கோள் குறிக்குள் இருக்கும் string-ஐ நகலெடுக்கவும்.
Bootloader-ஐ மாற்றுவதை விட kernel package-ஐ hold செய்வது பாதுகாப்பானதா?
பொதுவான தேவைகளுக்கு, ஆம். sudo apt-mark hold linux-image-virtual linux-headers-virtual புதிய kernel-கள் வருவதைத் தடுக்கும், இதனால் boot பாதை மாறாது. உங்களிடம் console வசதி இல்லாத சூழலில், இது பிழைகளைத் தவிர்க்க உதவும். முதலில் apt list --installed மூலம் உங்கள் கணினியில் உள்ள flavour பெயர்களைச் சரிபார்க்கவும், பின் apt-mark showhold மூலம் hold செய்யப்பட்டுள்ளதை உறுதிப்படுத்தவும். இதில் உள்ள சிக்கல் என்னவென்றால், hold செய்யப்பட்ட kernel-க்கு security updates கிடைக்காது. எனவே, hold செய்வதற்கு முன்பே எப்போது sudo apt-mark unhold-ஐ இயக்கப் போகிறீர்கள் என்பதைத் திட்டமிட்டுக்கொள்ளுங்கள்.