VPS-ல் Live Kernel Patching: ரீபூட் தேவையா?

VPS-ல் live kernel patching எவ்வாறு செயல்படுகிறது

Live kernel patching என்பது இயங்கிக்கொண்டிருக்கும் ஒரு கணினியில், reboot செய்யாமலும், இணைப்புகளைத் துண்டிக்காமலும் kernel பாதுகாப்புத் திருத்தங்களைச் செயல்படுத்துவதாகும். ஒரு function-ன் திருத்தப்பட்ட நகல் kernel module-ஆக ஏற்றப்படும்; பழைய function-க்கு வரும் ஒவ்வொரு அழைப்பும் புதிய நகலுக்குத் திருப்பி விடப்படும். இந்தச் செயல்பாட்டின் போது server தொடர்ந்து traffic-ஐக் கையாளும். இந்த ஒரு நுட்பமே live patching எதற்குப் பயன்படும், எதைச் செய்ய முடியாது என்பதை விளக்குகிறது.

இது நேரத்தை மிச்சப்படுத்துகிறது. ஆனால், இது reboot செய்வதற்கான தேவையை முழுமையாக நீக்காது. ஆறு மாதங்களாக live patching செய்யப்பட்ட ஒரு server, வட்டில் (disk) உள்ள பழைய kernel image-லேயே இயங்கிக்கொண்டிருக்கும்; அந்தத் திருத்தங்கள் அனைத்தும் நினைவகத்தில் (memory) மட்டுமே இருக்கும்.

Live patching பெரும்பாலும் managed plan-ன் ஒரு அம்சமாக விற்பனை செய்யப்படுகிறது. Unmanaged server-ல், இரண்டு கட்டளைகளைப் பயன்படுத்தி நீங்களே இதைச் செயல்படுத்தலாம். managed மற்றும் unmanaged VPS ஆகியவற்றுக்கு இடையேயான கட்டண வித்தியாசத்தைச் செலுத்தும் முன் இதைத் தெரிந்துகொள்வது அவசியம்.

Live kernel patching எவ்வாறு செயல்படுகிறது?

Kernel-ல் உள்ளமைக்கப்பட்ட live patching core உள்ளது, இது CONFIG_LIVEPATCH மூலம் compile செய்யப்படுகிறது. உங்கள் இயங்கும் kernel-ல் இது உள்ளதா எனச் சரிபார்க்கவும்:

grep CONFIG_LIVEPATCH /boot/config-$(uname -r)

CONFIG_LIVEPATCH=y என்று ஒரு வரி இருந்தால், நீங்கள் இயக்கும் kernel-ல் அந்த core உள்ளது என்று அர்த்தம். அது இல்லையென்றால், அந்த machine-ல் எந்த live patching சேவையும் செயல்படாது.

இந்த redirection, kernel-ன் function tracer ஆன ftrace-ஐப் பயன்படுத்துகிறது. பெரும்பாலான kernel functions, அவற்றின் தொடக்கத்திலேயே ஒரு call instruction-ஐக் கொண்டிருக்கும்; இது arguments அல்லது stack மாற்றப்படுவதற்கு முன்பே நடக்கும். Ftrace அந்த call site-ஐ ஒரு hook-ஆகப் பயன்படுத்துகிறது. ஒரு patch பயன்படுத்தப்படும்போது, live patching core அந்த target function-ல் ஒரு ftrace handler-ஐப் பதிவு செய்கிறது. அந்த handler, execution-ஐ மாற்று function-க்கு (replacement function) திருப்பி விடுகிறது. Kernel ஆவணங்கள் இதைத் தெளிவாகக் கூறுகின்றன: "Livepatching பொதுவாக function parameters அல்லது stack மாற்றப்படுவதற்கு முன்பே, function-ன் தொடக்கத்திலேயே code-ஐத் திருப்பி விட வேண்டும்."

இந்த வாக்கியத்திலிருந்து இரண்டு விளைவுகள் ஏற்படுகின்றன, இவை பின்னாளில் முக்கியமானவை. Ftrace எதை hook செய்ய முடியுமோ அதை மட்டுமே patch செய்ய முடியும்; எனவே, அந்த entry call இல்லாமல் compile செய்யப்பட்ட function-ஐப் patch செய்ய முடியாது. மேலும், patching-ன் அலகு என்பது ஒரு முழு function ஆகும்; ஒரு function-க்குள் இருக்கும் ஒரு வரியை மட்டும் patch செய்ய முடியாது.

இயங்கும் system-ஐப் பாதுகாப்பாக மாற்றுவதுதான் கடினமான பகுதி. நீங்கள் function-ஐ மாற்றும்போது, பழைய code ஏதேனும் ஒரு CPU-ன் stack-ல் இயங்கிக்கொண்டிருந்தால், பழைய மற்றும் புதிய செயல்பாடுகள் கலந்துவிடும். Upstream Linux இதை per-task consistency model மூலம் கையாளுகிறது. இது kernel ஆவணங்களில் ஒரு hybrid முறையாக விவரிக்கப்பட்டுள்ளது: "இது kGraft-ன் per-task consistency மற்றும் syscall barrier switching ஆகியவற்றை, kpatch-ன் stack trace switching-உடன் இணைக்கிறது." ஒரு task தற்போது patch செய்யப்பட்ட function-க்குள் இல்லை என்று kernel உறுதிப்படுத்திய பிறகு, அந்த task புதிய code-க்கு மாற்றப்படும். அனைத்து task-களும் மாறும் வரை, அந்த patch transition நிலையில் இருக்கும்.

இதன் முடிவை நீங்களே பார்க்கலாம். பயன்படுத்தப்பட்ட patches /sys/kernel/livepatch-ன் கீழ் தோன்றும்; ஒவ்வொரு patch-க்கும் ஒரு directory இருக்கும், அதற்குள் patch செய்யப்பட்ட functions பட்டியலிடப்பட்டிருக்கும்.

ls /sys/kernel/livepatch/

பட்டியல் காலியாக இருந்தால், memory-ல் எந்த live patch-உம் ஏற்றப்படவில்லை என்று அர்த்தம். புதிய server-ல் இதுவே இயல்பான தொடக்க நிலை ஆகும்.

Live kernel patching-ஆல் சரிசெய்ய முடியாதவை

Function-ன் உடற்பகுதிகள் (bodies) மட்டுமே patch செய்யப்படுகின்றன. மற்றவை எவையும் மாற்றப்படுவதில்லை.

• மாற்றப்பட்ட தரவு அமைப்புகள் (Data structures). ஒரு upstream fix, ஒரு struct-ல் புதிய field-ஐச் சேர்த்தாலோ அல்லது ஏற்கனவே உள்ள field-ன் அர்த்தத்தை மாற்றினாலோ, ஏற்கனவே ஒதுக்கப்பட்டு பயன்பாட்டில் உள்ள object-களைப் பாதுகாப்பாக மாற்றுவதற்கு வழியில்லை. kpatch திட்டம் இது குறித்து நேரடியாகக் குறிப்பிடுகிறது: "Statically allocated தரவுகளை மாற்றும் patches நேரடியாக ஆதரிக்கப்படுவதில்லை." Shadow variables மற்றும் callbacks இதற்கு ஒரு தீர்வாக இருந்தாலும், அவை தானியங்கி முறையில் செயல்படாது; ஒவ்வொரு patch-க்கும் கைமுறையாக எழுதப்பட வேண்டும்.
• ஒரே நேரத்தில் பல functions-ல் பரவியிருக்கும் திருத்தங்கள். ஒரு தொகுப்பில் உள்ள பல functions-ல் lock ordering-ஐ மாற்றும் ஒரு திருத்தத்திற்கு, அவை அனைத்தும் ஒரே நேரத்தில் மாற வேண்டும். ஆனால், consistency model முழு கணினியையும் ஒரே நொடியில் முடக்குவதற்குப் பதிலாக, பணிகளை (tasks) மாற்றுகிறது.
• தொடக்கக் குறியீடு (Initialisation code). __init எனக் குறிக்கப்பட்ட functions, உங்கள் server இயங்கத் தொடங்கும்போதே இயக்கப்பட்டு நீக்கப்பட்டிருக்கும். எனவே, அங்கு redirect செய்வதற்கு எதுவும் எஞ்சியிருக்காது.
• புதிய kernel பதிப்புகள் மற்றும் புதிய அம்சங்கள். Live patching என்பது ஒரு குறிப்பிட்ட kernel தொடருக்குள் (series) உங்களை patch level-ல் முன்னெடுத்துச் செல்லும். இது ஒரு தொடரிலிருந்து அடுத்த தொடருக்கு உங்களை மாற்றாது, புதிய அம்சங்களையும் சேர்க்காது. உங்களுக்குப் புதிய தொடரில் உள்ள ஏதேனும் அம்சம் தேவைப்பட்டால், உதாரணமாக Linux 7.1-ல் கொண்டுவரப்பட்ட மாற்றங்கள், நீங்கள் அந்த kernel-ஐ நிறுவி, அதன் மூலம் boot செய்ய வேண்டும்.
• Userspace. Canonical இதற்கான எல்லையைத் தெளிவாகக் கூறுகிறது: "Canonical Livepatch, OpenSSL அல்லது glibc போன்ற userspace libraries-ஐப் patch செய்வதில்லை. ஏனெனில், அது unattended-upgrades அல்லது ஒரு systems management கருவியின் பொறுப்பாகும்." பழைய OpenSSL-உடன் கூடிய live patched kernel என்பது முழுமையாகப் பாதுகாக்கப்பட்ட server ஆகாது. எனவே, unattended upgrades மூலம் userspace packages-ஐக் கையாளுவதை அதே server-ல் உறுதிப்படுத்தவும்.

Ubuntu-வின் சேவையில் தீவிரத்தன்மை (severity) சார்ந்த ஒரு எல்லையும் உள்ளது. Canonical நிறுவனம், "Critical மற்றும் High Common Vulnerability Scoring System (CVSS) மற்றும் Ubuntu Priority மதிப்பீடுகளைக் கொண்ட kernel பாதிப்புகளை மட்டுமே patch செய்கிறது" என்று கூறுகிறது. ஒரு CVE (common vulnerabilities and exposures) அடையாளங்காட்டி ஒரு குறைபாட்டைக் குறிக்கிறது, CVSS என்பது அதனுடன் இணைக்கப்பட்ட மதிப்பெண் ஆகும். Medium-rated kernel CVE-கள் வட்டில் உள்ள package-ல் மட்டுமே சரிசெய்யப்படும்; அவை live patch செய்யப்படாது. எனவே, அவை அடுத்த reboot-க்கு பிறகே உங்கள் இயங்கும் kernel-ஐ வந்தடையும்.

நேரடி kernel patching-க்கான விருப்பங்கள் என்ன?

பொதுவாகப் பயன்பாட்டில் உள்ள மூன்று வழிமுறைகள் உள்ளன, இவை அனைத்தும் ஒரே kernel கட்டமைப்பையே இயக்குகின்றன.

Canonical Livepatch என்பது Ubuntu Pro மூலம் வழங்கப்படுகிறது. தனிப்பட்ட பயன்பாட்டிற்கு Ubuntu Pro இலவசம். Canonical-ன் கூற்றுப்படி, "இது தனிப்பட்ட பயன்பாட்டிற்கு 5 physical machines வரை எப்போதும் இலவசமாகவே இருக்கும்", மேலும் அதிகாரப்பூர்வ Ubuntu Community உறுப்பினர்களுக்கு இது 50 machines வரை உயரும். ஆகஸ்ட் 2026 நிலவரப்படி இதுவே ஆவணப்படுத்தப்பட்ட வரம்பாகும். வணிக ரீதியான பயன்பாட்டிற்கு கட்டண சந்தா தேவை. ஆதரவு அளிக்கப்படும் long term support (LTS) வெளியீடுகளின் general availability (GA) kernels மற்றும் அவற்றின் hardware enablement (HWE) kernels ஆகியவற்றுக்கு, generic, aws, azure, gcp, oracle, ibm மற்றும் lowlatency போன்ற பல்வேறு வகைகளில் இந்த சேவை கிடைக்கிறது. நீங்கள் ஒரு தீர்வைச் சார்ந்திருப்பதற்கு முன், உங்கள் kernel-ஐ Canonical வெளியிட்ட kernel பட்டியலுடன் சரிபார்க்கவும்.

TuxCare வழங்கும் KernelCare என்பது பல Linux விநியோகங்களை உள்ளடக்கிய ஒரு வணிக ரீதியான agent ஆகும்; இதில் முதல் தரப்பு சேவை இல்லாத விநியோகங்களும் அடங்கும். இதன் ஆவணப்படுத்தப்பட்ட நிறுவல் முறை ஒரு vendor script ஆகும், அது curl -s -L https://kernelcare.com/installer | bash, அதைத் தொடர்ந்து key-based உரிமத்திற்காக /usr/bin/kcarectl --register KEY பயன்படுத்தப்படுகிறது. இந்த agent புதிய patches-களை அதன் சொந்த கால அட்டவணையில் சரிபார்க்கிறது, மேலும் /usr/bin/kcarectl --update கட்டளை ஒரு சரிபார்ப்பை கட்டாயப்படுத்துகிறது. நீங்கள் முக்கியமாகக் கருதும் server-ல் ஒரு script-ஐ shell-க்கு அனுப்பும் முன், அந்த installer-ஐப் படித்துப் பார்க்கவும்.

kpatch மற்றும் kGraft ஆகியவை முன்னோடித் தொழில்நுட்பங்கள் ஆகும். kGraft SUSE நிறுவனத்திடமிருந்தும், kpatch Red Hat நிறுவனத்திடமிருந்தும் வந்தவை. இன்றைய upstream Linux-ல் உள்ள நேரடி patching மையப்பகுதி இவ்விரண்டு கருத்துகளின் ஒருங்கிணைப்பாகும். kpatch தற்போது முடிவுக்கு வருகிறது: அதன் README-ல் Linux 6.19 முதல் "kpatch திட்டம் கைவிடப்பட்டு பராமரிப்பு முறையில் உள்ளது" என்று குறிப்பிடப்பட்டுள்ளது, மேலும் upstream kernel-ல் kpatch-build-க்கு பதிலாக klp-build பயன்படுத்தப்படுகிறது. RHEL மற்றும் அதன் மறுவடிவமைப்புகளில் (rebuilds), patches-களை நீங்களே உருவாக்குவதை விட, அந்தந்த விநியோகத்தின் சொந்த சேவையைப் பயன்படுத்துவதே சிறந்தது.

உங்கள் விநியோகம் எதை ஆதரிக்கிறது மற்றும் உங்கள் உரிமம் எதை அனுமதிக்கிறது என்பதைப் பொறுத்து தேர்வு செய்யவும். எந்தவொரு சந்தர்ப்பத்திலும், kernel மட்டத்திலான முடிவு ஒன்றாகவே இருக்கும்.

Ubuntu-வில் Canonical Livepatch-ஐ எவ்வாறு செயல்படுத்துவது

முதலில் உங்கள் Ubuntu Pro கணக்கு பக்கத்திலிருந்து ஒரு token-ஐப் பெறவும். கீழே உள்ள இரண்டு கட்டளைகளுக்கும் வெளிச்செல்லும் network அணுகல் தேவை, ஏனெனில் client, Canonical-ன் server-களுடன் இணைந்து patch-களைப் பெறுகிறது.

sudo pro attach TOKEN
sudo pro status

எந்த token-ம் இல்லாமல் sudo pro attach கட்டளையை இயக்கினால், அது browser அடிப்படையிலான செயல்முறையைத் தொடங்கி, Canonical தளத்தில் உள்ளிட வேண்டிய ஒரு code-ஐக் காண்பிக்கும். இணைக்கும்போது (attach), பரிந்துரைக்கப்பட்ட சேவைகள் தானாகவே செயல்படுத்தப்படும்; தற்போதைய LTS release-ல் Livepatch-ம் இதில் அடங்கும். நீங்கள் சேவைகளைத் தேர்வு செய்ய விரும்பினால் sudo pro attach --no-auto-enable-ஐப் பயன்படுத்தவும்.

Livepatch ஏற்கனவே செயல்பாட்டில் இல்லை என்றால்:

sudo pro enable livepatch
sudo canonical-livepatch status

இந்தச் சேவை canonical-livepatch snap மூலம் இயங்குகிறது, எனவே இந்தச் செயல்பாட்டை முடிக்க snapd சரியாக இயங்க வேண்டும். pro status கட்டளை, சேவைகளின் தகுதி மற்றும் நிலையை ஒரு அட்டவணையாகக் காண்பிக்கும். canonical-livepatch status கட்டளை, kernel வாரியான விவரங்களை அச்சிடும். Canonical-ன் ஆவணங்கள் வெளியீட்டை இந்த வடிவில் காட்டுகின்றன:

last check: 52 seconds ago
kernel: 5.4.0-216.236-generic
server check-in: succeeded
kernel state: ✓ kernel series 5.4 is covered by Livepatch
patch state: ✓ all applicable livepatch kernel modules applied
patch version: 113.1

இரண்டு வரிகள் இதற்கான பதிலைக் கொண்டுள்ளன. kernel state, நீங்கள் இயக்கும் series இந்தச் சேவையின் கீழ் வருகிறதா என்பதைக் குறிக்கிறது; Livepatch ஆதரிக்காத kernel-ஐ நீங்கள் boot செய்யும்போது இந்த வரி பிழையாக மாறும். patch state, அந்த kernel-க்குத் தேவையான patch-கள் உண்மையில் ஏற்றப்பட்டுள்ளதா என்பதைக் குறிக்கிறது. ஒரு kernel தகுதியுடையதாக இருந்து, patch-கள் ஏற்றப்படவில்லை என்றால் அது client சார்ந்த சிக்கல். ஒரு kernel தகுதியற்றதாக இருந்தால் அது kernel சார்ந்த சிக்கல், இதை எந்த client அமைப்பாலும் சரிசெய்ய முடியாது.

reboot நிலுவையில் உள்ளதா என்பதை எவ்வாறு கண்டறிவது?

Live patching அவசரத் தேவையை நீக்குவதால், reboot செய்ய வேண்டிய அவசியம் வெளிப்படையாகத் தெரியாது. நீங்களே அதைச் சரிபார்க்க வேண்டும்.

ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs

ஒரு package-ஐ நிறுவிய பின் அதைச் செயல்படுத்த restart தேவைப்பட்டால், package manager /var/run/reboot-required-ஐ உருவாக்கும். புதிய linux-image package எப்போதும் இதை உருவாக்கும். எந்தெந்த package-கள் reboot கோரியுள்ளன என்பதை .pkgs கோப்பு பட்டியலிடும். முதல் கட்டளை No such file or directory என்று பதிலளித்தால், கடைசியாக machine reboot செய்யப்பட்டதிலிருந்து எந்தப் புதிய reboot-ம் கோரப்படவில்லை என்று அர்த்தம். தற்போதைய Ubuntu-வில் /var/run என்பது /run-க்கான symlink ஆகும், எனவே எந்தப் பாதையைப் பயன்படுத்தினாலும் ஒரே கோப்பையே சென்றடையும்.

அந்தக் கொடி (flag) tmpfs-ல் இருப்பதால், ஒவ்வொரு reboot-க்குப் பிறகும் அது reset ஆகிவிடும். எனவே, kernel-ஐ வைத்தே இதை உறுதிப்படுத்தவும்:

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

uname -r நீங்கள் தற்போது இயக்கும் kernel-ஐக் காட்டும். இரண்டாவது கட்டளை வட்டில் (disk) நிறுவப்பட்டுள்ள kernel package-களைக் காட்டும். அந்தப் பட்டியலில் uname -r காட்டும் பதிப்பை விடப் புதியதாக ஒரு linux-image இருந்தால், Livepatch-ன் நிலை எதுவாக இருந்தாலும், machine பழைய kernel-லேயே இயங்குகிறது என்று அர்த்தம். இதுவே மிக முக்கியமான சரிபார்ப்பு, ஏனெனில் live patching என்பது இயங்கும் kernel-ஐப் பாதுகாப்பாக வைத்திருக்கவே உருவாக்கப்பட்டது, அதைத் தற்போதைய பதிப்பிற்கு (current) மாற்ற அல்ல.

Userspace-ல் இதே கேள்வியைச் சரிபார்க்க, Ubuntu Server-ல் இயல்பாகவே நிறுவப்பட்டிருக்கும் needrestart-ஐப் பயன்படுத்தலாம். இது நீக்கப்பட்ட library கோப்புகளை இன்னும் பயன்படுத்திக்கொண்டிருக்கும் இயங்கும் service-களைப் பட்டியலிடும்.

sudo needrestart -r l

-r l கொடி "list only" என்பதைக் குறிக்கிறது, எனவே இது எதையும் மாற்றாமல் தகவலை மட்டும் வழங்கும்.

ஏன் reboot செய்வது தவிர்க்க முடியாதது

வட்டில் உள்ள kernel மாறாமல் அப்படியே இருக்கும். Live patches இயங்கிக்கொண்டிருக்கும் kernel-ல் மட்டுமே ஏற்றப்படும்; அவை boot image-ல் எழுதப்படுவதில்லை. எனவே, bootloader எந்த linux-image-ஐத் தேர்ந்தெடுக்கிறதோ, அதிலேயே நீங்கள் reboot செய்வீர்கள். அதன் பிறகு, Livepatch client தற்போதைய சூழலுக்குப் பொருந்தும் patches-ஐ மீண்டும் செயல்படுத்தும். இந்த இரண்டு நிகழ்வுகளுக்கும் இடைப்பட்ட நேரத்தில், நீங்கள் patch செய்யப்படாத குறியீட்டையே இயக்குவீர்கள். பழைய kernel-ஐ விட, தற்போதைய kernel-ஐ boot செய்வதற்கு இதுவே கூடுதல் காரணமாகும்.

ஒவ்வொரு kernel series-க்கும் தனித்தனியான பாதுகாப்பு வழங்கப்படுகிறது, மேலும் அந்த series காலாவதியாகும். நீங்கள் இயக்கும் series ஆதரவு பட்டியலில் இருந்து நீக்கப்பட்டால், kernel state வரிசையில் பாதுகாப்புத் தகவல்கள் கிடைப்பது நின்றுவிடும். இதற்குப் புதிய kernel-க்கு மாறுவது மட்டுமே ஒரே தீர்வு. அதற்கு reboot அவசியம். LTS release-களில், புதிய series பொதுவாக hardware enablement kernel-ஆக 26.04.1 போன்ற point release மூலம் உங்களுக்குக் கிடைக்கும். எனவே, மாற்றத்திற்கான கோப்புகள் ஏற்கனவே உங்கள் archive-ல் இருக்கும்; நீங்கள் திட்டமிட்டு ஒருமுறை boot செய்வது மட்டுமே பாக்கி.

நடுத்தர மற்றும் குறைந்த தீவிரத்தன்மை கொண்ட kernel திருத்தங்கள் live patch செய்யப்படுவதில்லை. அவை வட்டில் உள்ள தொகுப்பிலேயே (package) இருக்கும்; நீங்கள் boot செய்யும்போது மட்டுமே அவை அமலுக்கு வரும்.

நீண்ட காலம் இயங்கும் kernel-களில், patching மூலம் நீக்க முடியாத சில நிலைகளும் (state) தேங்கிவிடும். Canonical நிறுவனத்தின் நிலைப்பாட்டை மேற்கோள் காட்டுவது பொருத்தமானது, ஏனெனில் அதுவே உண்மையானது: Livepatch "என்பது reboot செய்வதற்கு மாற்றல்ல. திட்டமிடப்படாத reboot-களைத் தவிர்ப்பதன் மூலம் உங்களுக்கு அதிகக் கட்டுப்பாட்டை வழங்கும் ஒரு கருவி மட்டுமே." இதில் கவனிக்க வேண்டிய முக்கிய வார்த்தை திட்டமிடப்படாத (unscheduled) என்பதாகும். நீங்கள் reboot செய்தே ஆக வேண்டும். எப்போது செய்ய வேண்டும் என்பதை நீங்களே முடிவு செய்கிறீர்கள்.

மீண்டும் தொடங்கும் வகையில் reboot-ஐ திட்டமிடுதல்

நீங்கள் console-ஐ அணுக முடியாவிட்டால், VPS reboot என்பது ஒரு வழிப் பயணமாகிவிடும். reboot கட்டளையைத் தட்டச்சு செய்வதற்கு முன், கணினி மீண்டும் இயங்காத பட்சத்தில் உங்களால் உள்ளே நுழைய முடியும் என்பதை உறுதிப்படுத்திக் கொள்ளுங்கள்.

• உங்கள் சேவை வழங்குநர் (provider) control panel-ல் serial console அல்லது VNC (virtual network computing) வசதியை வழங்குகிறாரா என்பதை உறுதிப்படுத்திக் கொள்ளுங்கள். செயலிழப்பு ஏற்படும் போது தேடுவதை விட, இப்போதே அதைத் திறந்து சரிபார்க்கவும்.
• df -h /boot கட்டளையைப் பயன்படுத்தி காலியாக உள்ள இடத்தைச் சரிபார்க்கவும். /boot முழுமையாக நிரம்பியிருந்தால், kernel package தனது initramfs (initial RAM filesystem)-ஐ எழுதும் போது தோல்வியடையும். இது முழுமையடையாத image-ஐக் காட்டும் bootloader entry-ஐ உருவாக்கிவிடும்.
• குறைந்தது ஒரு பழைய, சரியாக இயங்கும் kernel-ஐ நிறுவி வைத்திருக்கவும். GRUB அதை "Advanced options for Ubuntu" என்பதன் கீழ் பட்டியலிடும். புதிய kernel தோல்வியடையும் போது, அதிலிருந்து boot செய்வதுதான் விரைவான மீட்பு முறையாகும்.
• உங்களுக்குத் தேவைப்படுவதற்கு முன்பே உங்கள் சேவை வழங்குநரின் rescue mode-ஐக் கண்டறியவும். reboot-க்குப் பிறகு console-ல் initramfs prompt தெரிந்தால், அங்கிருந்துதான் பழுதுநீக்கம் செய்ய வேண்டும்.

நீங்கள் விழித்திருக்கும் நேரத்தில் reboot-ஐத் திட்டமிடுங்கள்:

sudo shutdown -r +5 "Kernel update, back in a moment"

இது ஐந்து நிமிடங்களுக்குப் பிறகு reboot-ஐத் திட்டமிட்டு, உள்நுழைந்துள்ள பயனர்களுக்குச் செய்தியை அனுப்பும். sudo shutdown -c கட்டளை அதை ரத்து செய்யும். கணினி மீண்டும் வந்ததும், இரண்டு பகுதிகளையும் உறுதிப்படுத்தவும்:

uname -r
sudo canonical-livepatch status

uname -r இப்போது புதிய kernel-ஐக் காட்ட வேண்டும், மேலும் status வெளியீடு புதிய தொடர் சரியாக உள்ளடக்கப்பட்டுள்ளதை உறுதிப்படுத்த வேண்டும். கணினி மீண்டும் வரவே இல்லை என்றால், பிழை பெரும்பாலும் network-ல் இருக்காது, boot path-ல் தான் இருக்கும். அதற்கான மீட்பு வழிமுறை kernel update-க்குப் பிறகு boot ஆகாத VPS-ஐச் சரிசெய்யும் வழிகாட்டி-ல் உள்ளது.

பழைய kernels-ஐ ஏன் நீக்க வேண்டும்

Live patching இந்தச் சிக்கலை மேலும் தீவிரமாக்குகிறது. ஏனெனில், இது reboot செய்வதற்கான அவசியத்தைக் குறைக்கிறது, அதே சமயம் linux-image packages தொடர்ந்து நிறுவப்படுகின்றன. ஒவ்வொரு kernel-ம் ஒரு boot image, ஒரு initramfs, ஒரு modules tree மற்றும் பொதுவாக ஒரு headers package ஆகியவற்றை நிறுவுகிறது. சில நூறு megabytes அளவுள்ள தனி /boot partition கொண்ட சிறிய VPS-ல், மூன்றோ நான்கோ kernels-ஐ நிறுவினாலே அது நிரம்பிவிடும்.

/boot முழுமையாக நிரம்பினால், அடுத்த kernel நிறுவல் தோல்வியடையும். இதனால், ஒரு machine தனக்குத் தேவையான update-ஐயே பெற முடியாமல் போகிறது. apt autoremove கட்டளை பழைய kernels-ஐ நீக்க உதவும், ஆனால் ஒரு machine-ஐ reboot செய்யாதபோது, அவை நீக்கப்படுவதற்குத் தகுதியற்றவையாக இருக்கலாம். ஏனெனில், நீங்கள் தற்போது இயக்கி வரும் kernel-ஐ package manager நீக்காது.

எனவே, எவை நிறுவப்பட்டுள்ளன என்பதைச் சரிபார்க்கவும். தற்போது இயங்கும் kernel மற்றும் நன்கு செயல்படும் ஒரு fallback kernel ஆகியவற்றை மட்டும் வைத்துக்கொண்டு, மற்றவற்றை Ubuntu-வில் பழைய kernels-ஐ பாதுகாப்பாக நீக்கும் முறை மூலம் நீக்கவும். uname -r தற்போது எந்த kernel-ஐக் காட்டுகிறதோ, அதை ஒருபோதும் நீக்க வேண்டாம்.

FAQ

Live kernel patching பயன்படுத்தினால் நான் என் VPS-ஐ ஒருபோதும் reboot செய்ய வேண்டியதில்லை என்பதா?

இல்லை. Live patches இயங்கும் kernel-க்குள் ஏற்றப்படுகின்றன, அவை boot image-ல் எழுதப்படுவதில்லை. எனவே, வட்டில் உள்ள linux-image நீங்கள் boot செய்த அதே பதிப்பிலேயே இருக்கும். Canonical இதைத் தெளிவாகக் கூறுகிறது: Livepatch "reboot செய்வதற்கு மாற்றல்ல. இது திட்டமிடப்படாத reboot-களைத் தவிர்ப்பதன் மூலம் உங்களுக்கு அதிகக் கட்டுப்பாட்டை வழங்கும் ஒரு கருவி." உங்கள் kernel series பயன்பாட்டிலிருந்து நீக்கப்படும்போது இதற்கான ஆதரவும் முடிந்துவிடும். மேலும், நடுத்தர தீவிரத்தன்மை கொண்ட kernel திருத்தங்கள் (medium severity kernel fixes) எப்போதுமே live patch செய்யப்படுவதில்லை. கட்டாயப்படுத்தப்படும் வரை காத்திருக்காமல், நீங்களே ஒரு கால அட்டவணையை உருவாக்கி maintenance reboot-ஐத் திட்டமிடுங்கள்.

Live kernel patching உண்மையில் patches-ஐப் பொருத்துகிறதா என்பதை நான் எப்படிச் சரிபார்ப்பது?

sudo canonical-livepatch status கட்டளையை இயக்கி இரண்டு வரிகளைப் படிக்கவும். உங்கள் இயங்கும் kernel series இந்தச் சேவையின் கீழ் வருகிறதா என்பதை kernel state தெரிவிக்கும், மேலும் அந்த kernel-க்கான patches ஏற்றப்பட்டுள்ளதா என்பதை patch state தெரிவிக்கும். நீங்கள் ls /sys/kernel/livepatch/ கட்டளையைப் பயன்படுத்தி kernel பக்கத்தையும் நேரடியாகச் சரிபார்க்கலாம்; இது ஏற்றப்பட்ட ஒவ்வொரு patch-க்கும் ஒரு directory-ஐப் பட்டியலிடும். பட்டியல் காலியாக இருந்தால், client என்ன சொன்னாலும், தற்போது நினைவகத்தில் (memory) எந்தப் patch-ம் செய்யப்படவில்லை என்று அர்த்தம்.

தனிப்பட்ட VPS-ல் Ubuntu Pro இலவசமா?

ஆம், ஆவணப்படுத்தப்பட்ட வரம்பிற்குள் இது இலவசம். Canonical-ன் கூற்றுப்படி, Ubuntu Pro "தனிப்பட்ட பயன்பாட்டிற்கு 5 physical machines வரை எப்போதும் இலவசம்". ஆகஸ்ட் 2026 நிலவரப்படி, அதிகாரப்பூர்வ Ubuntu Community உறுப்பினர்களுக்கு இது 50 machines வரை உயர்கிறது. வணிக ரீதியான பயன்பாட்டிற்குச் சந்தா (subscription) தேவை. உங்கள் Ubuntu Pro கணக்குப் பக்கத்திலிருந்து ஒரு token-ஐப் பெற்று, sudo pro attach TOKEN மூலம் machine-ஐ இணைத்து, பின் sudo pro enable livepatch மூலம் சேவையைச் செயல்படுத்தவும்.

Livepatch இயங்கிய பிறகும் ஒரு kernel CVE ஏன் இன்னும் சரிசெய்யப்படாததாகக் காட்டப்படுகிறது?

பொதுவாக இரண்டு காரணங்கள் இருக்கலாம். முதலாவது, அந்தத் திருத்தம் தீவிரத்தன்மை வரம்பிற்கு (severity threshold) கீழே இருக்கலாம். ஏனெனில், Canonical "critical மற்றும் high Common Vulnerability Scoring System (CVSS) மற்றும் Ubuntu Priority மதிப்பீடுகளைக் கொண்ட kernel பாதிப்புகளை" மட்டுமே live patch செய்கிறது; மற்றவற்றை வட்டில் உள்ள package-ன் பொறுப்பிற்கு விட்டுவிடுகிறது. இரண்டாவது, அந்தத் திருத்தத்தை ஒரு function body-ன் மாற்றமாகச் செய்ய முடியாமல் இருக்கலாம். உதாரணமாக, upstream ஒரு data structure-ஐ மாற்றியிருந்தால், ஏற்கனவே ஒதுக்கப்பட்ட (allocated) objects-ல் அதை live patching மூலம் பாதுகாப்பாகச் செய்ய முடியாது. இரண்டு நிலைகளிலும் தீர்வு ஒன்றுதான்: மேம்படுத்தப்பட்ட kernel package-ஐ நிறுவி, அதில் boot செய்யவும்.

Live kernel patching எவற்றையெல்லாம் உள்ளடக்குவதில்லை?

Userspace-ஐ இது உள்ளடக்குவதில்லை. Livepatch "OpenSSL அல்லது glibc போன்ற userspace libraries-ஐப் patch செய்யாது, ஏனெனில் அது unattended-upgrades அல்லது ஒரு systems management கருவியின் பொறுப்பாகும்" என்று Canonical தெளிவாகக் கூறுகிறது. இது புதிய kernel பதிப்பையோ அல்லது புதிய அம்சங்களையோ வழங்க முடியாது, ஏனெனில் இது நீங்கள் ஏற்கனவே இயக்கும் series-க்குள் இருக்கும் function bodies-ஐ மட்டுமே மாற்றுகிறது. மேலும், இது __init செயல்பாடுகளைப் patch செய்ய முடியாது, ஏனெனில் server இயங்கத் தொடங்கும்போதே அவை இயங்கி நினைவகத்திலிருந்து நீக்கப்பட்டிருக்கும்.