VPS पर Live Kernel Patching: क्या Reboot जरूरी है?

VPS पर live kernel patching क्या करती है

Live kernel patching चलते हुए सिस्टम पर kernel security fixes लागू करती है, जिसके लिए न तो reboot की आवश्यकता होती है और न ही connections drop होते हैं। एक function की fixed copy को kernel module के रूप में load किया जाता है, और पुराने function के लिए आने वाली हर call को नई copy पर redirect कर दिया जाता है, जबकि सर्वर traffic serve करना जारी रखता है। यही एक mechanism यह स्पष्ट करता है कि live patching किसमें सक्षम है और क्या नहीं कर सकती।

यह समय बचाती है। यह reboot की आवश्यकता को पूरी तरह खत्म नहीं करती। जिस सर्वर पर छह महीने से live patching की जा रही है, वह अभी भी disk पर मौजूद पुराने kernel image से ही boot है, और वे सभी patches केवल memory में ही मौजूद हैं।

Live patching को अक्सर managed plan के एक feature के रूप में बेचा जाता है। एक unmanaged सर्वर पर आप इसे दो commands के साथ स्वयं enable कर सकते हैं, जिसे 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 के साथ build किया गया है। इसके बिना, उस machine पर कोई भी live patching service काम नहीं कर सकती।

Redirection के लिए ftrace का उपयोग किया जाता है, जो kernel का function tracer है। अधिकांश kernel functions को function के बिल्कुल शुरुआत में एक call instruction के साथ compile किया जाता है, इससे पहले कि arguments या stack को touch किया जाए। Ftrace इस call site को एक hook के रूप में उपयोग करता है। जब कोई patch apply किया जाता है, तो live patching core target function पर एक ftrace handler register करता है, और यह handler execution को replacement function की ओर भेज देता है। Kernel documentation इसे स्पष्ट रूप से बताता है: "Livepatching को आमतौर पर function parameters या stack के किसी भी तरह से modify होने से पहले, function entry की शुरुआत में ही code को redirect करने की आवश्यकता होती है।"

इस वाक्य के दो परिणाम निकलते हैं, और दोनों ही बाद में महत्वपूर्ण होते हैं। केवल वही function patchable है जिसे ftrace hook कर सकता है, इसलिए जिस function को उस entry call के बिना compile किया गया है, उसे patch नहीं किया जा सकता। और patching की इकाई एक पूरा function होता है, न कि उसके अंदर की कोई एक लाइन।

अधिक कठिन हिस्सा live system को सुरक्षित रूप से switch करना है। यदि function को swap करते समय पुरानी code किसी CPU के stack पर चल रही है, तो आपको पुराने और नए व्यवहार का मिश्रण मिलेगा। Upstream Linux इसे per-task consistency model के साथ संभालता है, जिसे kernel docs में एक hybrid के रूप में वर्णित किया गया है: "यह kGraft के per-task consistency और syscall barrier switching का उपयोग करता है, जिसे kpatch के stack trace switching के साथ मिलाया गया है।" Tasks एक-एक करके नए code पर move होते हैं, केवल तभी जब kernel यह दिखा सके कि वह task वर्तमान में किसी patched function के अंदर नहीं है। जब तक हर task move नहीं हो जाता, patch transition की स्थिति में रहता है।

आप स्वयं परिणाम देख सकते हैं। Applied patches /sys/kernel/livepatch के अंतर्गत दिखाई देते हैं, जहाँ हर patch के लिए एक directory होती है, और उसके अंदर patched functions की सूची होती है।

ls /sys/kernel/livepatch/

एक खाली सूची का मतलब है कि memory में कोई live patch load नहीं है, जो कि एक fresh server पर सामान्य शुरुआती स्थिति होती है।

लाइव कर्नल पैचिंग किन समस्याओं को ठीक नहीं कर सकती

केवल फंक्शन बॉडी को पैच किया जाता है। बाकी किसी भी चीज़ में बदलाव नहीं होता।

• बदले हुए डेटा स्ट्रक्चर। यदि अपस्ट्रीम फिक्स किसी struct में कोई फील्ड जोड़ता है या किसी मौजूदा फील्ड का अर्थ बदलता है, तो पहले से आवंटित और उपयोग में मौजूद ऑब्जेक्ट्स को फिर से लिखने का कोई सुरक्षित तरीका नहीं है। kpatch प्रोजेक्ट सीधे तौर पर इस स्थिति को स्पष्ट करता है: "जो पैच स्थिर रूप से आवंटित (statically allocated) डेटा को संशोधित करते हैं, वे सीधे समर्थित नहीं हैं।" शैडो वेरिएबल्स और कॉलबैक एक वर्कअराउंड के रूप में मौजूद हैं, लेकिन उन्हें हर पैच के लिए मैन्युअल रूप से लिखना पड़ता है, यह स्वचालित नहीं है।
• एक साथ कई फंक्शन्स में फैले हुए फिक्स। एक ऐसा फिक्स जो फंक्शन्स के समूह में लॉक ऑर्डरिंग को बदलता है, उसे उन सभी में एक साथ बदलाव की आवश्यकता होती है, और कंसिस्टेंसी मॉडल पूरे मशीन को एक ही क्षण में फ्रीज करने के बजाय टास्क को स्विच करता है।
• इनिशियलाइज़ेशन कोड। __init के रूप में चिह्नित फंक्शन्स आपके सर्वर के चालू होने तक पहले ही चल चुके होते हैं और फ्री हो चुके होते हैं, इसलिए रीडायरेक्ट करने के लिए कुछ भी शेष नहीं रहता।
• नए कर्नल वर्ज़न और नए फीचर्स। लाइव पैचिंग आपको एक कर्नल सीरीज़ के भीतर पैच लेवल पर आगे ले जाती है। यह आपको कभी भी एक सीरीज़ से दूसरी सीरीज़ में नहीं ले जाती है, और यह कभी भी कोई फीचर नहीं जोड़ती है। यदि आपको किसी नई सीरीज़ से कुछ चाहिए, जैसे कि Linux 7.1 में आए बदलाव, तो आपको उस कर्नल को इंस्टॉल करना होगा और उसे बूट करना होगा।
• यूज़रस्पेस। Canonical स्वयं इस सीमा को स्पष्ट करता है: "Canonical Livepatch, OpenSSL या glibc जैसी यूज़रस्पेस लाइब्रेरीज़ को पैच नहीं करता है, क्योंकि यह unattended-upgrades या किसी सिस्टम मैनेजमेंट टूल की जिम्मेदारी है।" एक पुराने OpenSSL के साथ लाइव पैच किया गया कर्नल एक पूरी तरह से पैच किया हुआ सर्वर नहीं है, इसलिए उसी बॉक्स पर unattended upgrades के माध्यम से यूज़रस्पेस पैकेज को मैनेज करना जारी रखें।

Ubuntu की सर्विस पर गंभीरता की एक सीमा भी है। Canonical का कहना है कि यह "क्रिटिकल और हाई Common Vulnerability Scoring System (CVSS) और Ubuntu प्रायोरिटी रेटिंग वाली कर्नल कमजोरियों को पैच करता है।" एक CVE (common vulnerabilities and exposures) आइडेंटिफायर एक खामी का नाम बताता है, और CVSS उससे जुड़ा स्कोर है। मध्यम रेटिंग वाली कर्नल CVE को डिस्क पर मौजूद पैकेज में ठीक किया जाता है और उसे लाइव पैच नहीं किया जाता है, इसलिए वह आपके चल रहे कर्नल तक अगले रीबूट पर ही पहुँचती है, उससे पहले नहीं।

Live kernel patching के विकल्प क्या हैं?

सामान्य उपयोग में तीन मुख्य प्रणालियाँ हैं, और ये सभी एक ही kernel machinery का उपयोग करती हैं।

Canonical Livepatch को Ubuntu Pro के माध्यम से प्रदान किया जाता है। Ubuntu Pro व्यक्तिगत उपयोग के लिए निःशुल्क है, और Canonical के अनुसार यह "5 भौतिक मशीनों तक व्यक्तिगत उपयोग के लिए हमेशा निःशुल्क रहेगा", जो आधिकारिक Ubuntu Community सदस्यों के लिए 50 मशीनों तक बढ़ जाता है। अगस्त 2026 तक यही प्रलेखित सीमा है। व्यावसायिक उपयोग के लिए सशुल्क सदस्यता की आवश्यकता होती है। कवरेज प्रति kernel series और प्रति flavour के आधार पर दी जाती है, जिसमें समर्थित long term support (LTS) releases के general availability (GA) kernels और उनके hardware enablement (HWE) kernels शामिल हैं। यह generic, aws, azure, gcp, oracle, ibm और lowlatency जैसे flavours पर उपलब्ध है। उस पर निर्भर होने से पहले अपने kernel की तुलना Canonical की प्रकाशित kernel सूची से करें।

KernelCare, जो TuxCare द्वारा प्रदान किया जाता है, एक व्यावसायिक agent है जो कई distributions को कवर करता है, जिनमें वे भी शामिल हैं जिनका कोई first-party service नहीं है। इसका प्रलेखित इंस्टॉलेशन एक vendor script, curl -s -L https://kernelcare.com/installer | bash, और उसके बाद key-based licence के लिए /usr/bin/kcarectl --register KEY है। इसके बाद agent अपने स्वयं के schedule पर नए patches की जाँच करता है, और /usr/bin/kcarectl --update एक जाँच को बाध्य (force) करता है। जिस सर्वर की आप परवाह करते हैं, उस पर shell में pipe करने से पहले installer को अवश्य पढ़ें।

kpatch और kGraft इसके पूर्वज हैं। kGraft SUSE से आया था, kpatch Red Hat से, और आज upstream Linux में live patching core इन दोनों विचारों का मिश्रण है। kpatch स्वयं समाप्त हो रहा है: इसके README में उल्लेख है कि Linux 6.19 से "kpatch project deprecated है और maintenance mode में है", जहाँ kpatch-build को upstream kernel में klp-build द्वारा प्रतिस्थापित किया जा रहा है। RHEL और इसके rebuilds पर, आपको patches को हाथ से बनाने के बजाय distribution की अपनी service का उपयोग करना चाहिए।

इस आधार पर चुनाव करें कि आपका distribution क्या समर्थन करता है और आपका licence क्या अनुमति देता है। प्रत्येक स्थिति में kernel-level परिणाम समान ही होता है।

Ubuntu पर Canonical Livepatch को कैसे सक्षम करें

सबसे पहले अपने Ubuntu Pro अकाउंट पेज से एक टोकन प्राप्त करें। नीचे दिए गए दोनों commands के लिए आउटबाउंड नेटवर्क एक्सेस की आवश्यकता होती है, क्योंकि क्लाइंट अटैच होने और पैच प्राप्त करने के लिए Canonical के सर्वर्स से संपर्क करता है।

sudo pro attach TOKEN
sudo pro status

बिना टोकन के sudo pro attach चलाने पर ब्राउज़र-आधारित प्रक्रिया शुरू होती है और Canonical की साइट पर दर्ज करने के लिए एक कोड मिलता है। अटैच करने पर अनुशंसित सेवाएं स्वतः सक्षम हो जाती हैं, जिसमें वर्तमान LTS रिलीज़ पर Livepatch शामिल है। यदि आप स्वयं सेवाएं चुनना चाहते हैं, तो sudo pro attach --no-auto-enable का उपयोग करें।

यदि Livepatch पहले से चालू नहीं है:

sudo pro enable livepatch
sudo canonical-livepatch status

यह सेवा canonical-livepatch स्नैप से चलती है, इसलिए इनेबल स्टेप पूरा होने के लिए snapd का काम करना आवश्यक है। pro status सेवाओं की पात्रता और स्थिति की एक तालिका प्रिंट करता है। canonical-livepatch status प्रति-कर्नेल विवरण प्रिंट करता है, और 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 बताता है कि क्या आप जिस सीरीज़ का उपयोग कर रहे हैं वह सेवा द्वारा कवर की गई है या नहीं, और यदि आप ऐसा कर्नेल बूट करते हैं जिसे Livepatch सपोर्ट नहीं करता है, तो यह पंक्ति खराब हो जाती है। patch state बताता है कि क्या उस कर्नेल पर लागू होने वाले पैच वास्तव में लोड किए गए हैं। बिना पैच वाला कवर्ड कर्नेल एक क्लाइंट समस्या है। एक अनकवर्ड कर्नेल एक कर्नेल समस्या है, और कोई भी क्लाइंट सेटिंग इसे ठीक नहीं कर सकती है।

मुझे कैसे पता चलेगा कि रीबूट लंबित (pending) है?

Live patching आपातकालीन स्थिति को समाप्त कर देता है, इसलिए लंबित रीबूट स्पष्ट नहीं रहता है। आपको इसे स्वयं खोजना होगा।

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

जब किसी इंस्टॉल किए गए पैकेज को प्रभावी होने के लिए रीस्टार्ट की आवश्यकता होती है, तो पैकेज मैनेजर /var/run/reboot-required बनाता है, और एक नया linux-image पैकेज हमेशा इसे बनाता है। .pkgs फ़ाइल उन पैकेजों की सूची रखती है जिन्होंने रीबूट का अनुरोध किया है। यदि पहला कमांड No such file or directory उत्तर देता है, तो मशीन के अंतिम बार बूट होने के बाद से किसी ने रीबूट का अनुरोध नहीं किया है। वर्तमान Ubuntu पर /var/run, /run का एक सिम्बॉलिक लिंक है, इसलिए कोई भी पाथ उसी फ़ाइल तक पहुँचता है।

वह फ्लैग tmpfs में रहता है और हर बूट पर रीसेट हो जाता है, इसलिए इसे स्वयं कर्नल के साथ सत्यापित करें:

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

uname -r उस कर्नल को प्रिंट करता है जिसे आप चला रहे हैं। दूसरा कमांड डिस्क पर इंस्टॉल किए गए कर्नल पैकेजों को प्रिंट करता है। उस सूची में linux-image का होना, जो uname -r द्वारा रिपोर्ट किए गए कर्नल से नया है, इसका मतलब है कि मशीन एक पुराना कर्नल चला रही है, चाहे Livepatch की स्थिति कुछ भी कहे। यह वह जाँच है जो मायने रखती है, क्योंकि live patching को चल रहे कर्नल को सुरक्षित बनाने के लिए बनाया गया है, न कि उसे वर्तमान (latest) बनाने के लिए।

उसी प्रश्न के यूजर्सपेस (userspace) भाग के लिए, needrestart Ubuntu Server पर डिफ़ॉल्ट रूप से इंस्टॉल होता है और उन चल रही सेवाओं को सूचीबद्ध करता है जो अभी भी डिलीट की गई लाइब्रेरी फ़ाइलों को होल्ड किए हुए हैं।

sudo needrestart -r l

-r l फ्लैग पेयर का अर्थ है "केवल सूचीबद्ध करें" (list only), इसलिए यह कुछ भी बदलता नहीं है और केवल रिपोर्ट करता है।

Reboot की आवश्यकता क्यों बनी रहती है

डिस्क पर मौजूद kernel में कोई बदलाव नहीं होता है। Live patches को चलते हुए kernel में लोड किया जाता है और उन्हें कभी भी boot image में नहीं लिखा जाता है। इसलिए, reboot करने पर आप उसी linux-image पर आते हैं जिसे bootloader चुनता है, और फिर Livepatch client उन patches को दोबारा लागू करता है जो अभी भी प्रभावी हैं। इन दोनों स्थितियों के बीच आप unpatched code चला रहे होते हैं, जो पुराने kernel के बजाय वर्तमान kernel को boot करने का एक और कारण है।

Coverage प्रति kernel series होती है, और series को समय के साथ retired कर दिया जाता है। जब आपकी चल रही series supported list से बाहर हो जाती है, तो kernel state लाइन coverage रिपोर्ट करना बंद कर देती है, और इसका एकमात्र समाधान एक नया kernel है। इसके लिए reboot करना आवश्यक है। LTS release पर, नई series आमतौर पर 26.04.1 जैसे point release में शामिल hardware enablement kernel के रूप में आप तक पहुँचती है। इसलिए, replacement पहले से ही archive में मौजूद होता है और केवल एक boot की कमी होती है जिसे आप schedule कर सकते हैं।

Medium और low severity वाले kernel fixes को कभी भी live patch नहीं किया जाता है। वे डिस्क पर package में ही रहते हैं और आप तक तभी पहुँचते हैं जब आप reboot करते हैं।

लंबे समय तक चलने वाले kernels में ऐसी स्थिति (state) भी जमा हो जाती है जिसे patching साफ नहीं कर पाती है। Canonical का अपना पक्ष उद्धृत करने योग्य है, क्योंकि यह ईमानदार है: Livepatch "reboot करने का विकल्प नहीं है। यह एक ऐसा टूल है जो आपको unscheduled reboots को रोककर अधिक नियंत्रण देता है।" यहाँ मुख्य शब्द unscheduled है। आपको फिर भी reboot करना पड़ता है। आप बस यह चुनते हैं कि कब करना है।

रीबूट को शेड्यूल करना जो वापस आ जाए

यदि आप कंसोल तक नहीं पहुँच सकते हैं, तो VPS रीबूट एकतरफा होता है। reboot टाइप करने से पहले, सुनिश्चित करें कि यदि मशीन वापस न आए तो आप उसे एक्सेस कर सकें।

• पुष्टि करें कि आपका प्रदाता कंट्रोल पैनल में सीरियल कंसोल या VNC (virtual network computing) व्यू प्रदान करता है, और इसे आउटेज के दौरान खोलने के बजाय अभी खोलें।
• df -h /boot के साथ खाली जगह की जाँच करें। एक भरा हुआ /boot कर्नेल पैकेज को उसके initramfs (initial RAM filesystem) को लिखते समय विफल कर देता है, जिससे बूटलोडर एंट्री ऐसी इमेज पर पॉइंट कर सकती है जो कभी पूरी नहीं हुई थी।
• कम से कम एक ज्ञात-अच्छे पुराने कर्नेल को इंस्टॉल रखें। GRUB इसे "Advanced options for Ubuntu" के अंतर्गत सूचीबद्ध करता है, और जब कोई नया कर्नेल विफल हो जाता है तो इसे बूट करना सबसे तेज़ रिकवरी है।
• जरूरत पड़ने से पहले अपने प्रदाता का रेस्क्यू मोड ढूँढ लें। यदि रीबूट के बाद कंसोल एक initramfs प्रॉम्प्ट दिखाता है, तो मरम्मत वहीं होती है।

फिर ऐसे समय में रीबूट करें जब आप जाग रहे हों:

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

यह रीबूट को पांच मिनट बाद के लिए शेड्यूल करता है और लॉग-इन उपयोगकर्ताओं को एक संदेश भेजता है। sudo shutdown -c इसे रद्द कर देता है। जब मशीन वापस आ जाए, तो दोनों हिस्सों की पुष्टि करें:

uname -r
sudo canonical-livepatch status

uname -r को अब नए कर्नेल की रिपोर्ट करनी चाहिए, और स्टेटस आउटपुट को नई सीरीज को कवर किए जाने की रिपोर्ट देनी चाहिए। यदि मशीन बिल्कुल भी वापस नहीं आती है, तो दोष लगभग हमेशा नेटवर्क के बजाय बूट पाथ में होता है, और रिकवरी का रास्ता कर्नेल अपडेट के बाद बूट न होने वाले VPS के लिए गाइड में दिया गया है।

पुराने kernels को साफ करना क्यों आवश्यक है

Live patching इस समस्या को कम करने के बजाय और बढ़ा देता है, क्योंकि यह reboot करने की आवश्यकता को खत्म कर देता है जबकि linux-image packages install होते रहते हैं। प्रत्येक kernel एक boot image, एक initramfs, एक modules tree और आमतौर पर एक headers package install करता है। कुछ सौ megabytes के अलग /boot partition वाले छोटे VPS पर, इनमें से तीन या चार ही उसे भर देते हैं।

एक पूर्ण /boot फिर अगले kernel install को बाधित कर देता है, और इसी तरह एक मशीन उस update को लेने में असमर्थ हो जाती है जिसकी उसे वास्तव में आवश्यकता है। apt autoremove path पुराने kernels को तब हटा देता है जब वे इसके योग्य हो जाते हैं, लेकिन ऐसी मशीन पर जो कभी reboot नहीं होती, वे हमेशा योग्य नहीं होते, क्योंकि package manager उस kernel को नहीं हटाएगा जिसे आप शायद अभी भी चला रहे हों।

इसलिए जाँचें कि क्या install है, चल रहे kernel और एक ज्ञात-अच्छे (known-good) fallback को रखें, और बाकी को Ubuntu पर पुराने kernels को हटाने की सुरक्षित प्रक्रिया का उपयोग करके हटा दें। उस kernel को कभी न हटाएँ जिसे uname -r वर्तमान में रिपोर्ट करता है।

FAQ

क्या live kernel patching का मतलब यह है कि मुझे कभी भी अपने VPS को reboot नहीं करना पड़ेगा?

नहीं। Live patches चलते हुए kernel में लोड होते हैं और boot image में नहीं लिखे जाते, इसलिए डिस्क पर मौजूद linux-image उसी version पर रहता है जिससे आपने boot किया था। Canonical इसे स्पष्ट रूप से कहता है: Livepatch "reboot करने का विकल्प नहीं है। यह एक ऐसा टूल है जो आपको अनियोजित reboot से बचाकर अधिक नियंत्रण देता है।" जब आपकी kernel series retired हो जाती है, तो कवरेज भी समाप्त हो जाती है, और मध्यम गंभीरता (medium severity) वाले kernel fixes को कभी भी live patch नहीं किया जाता है। मजबूरन reboot करने के बजाय, अपनी पसंद की आवृत्ति पर maintenance reboot शेड्यूल करें।

मैं यह कैसे जाँचूँ कि live kernel patching वास्तव में patches लागू कर रहा है?

sudo canonical-livepatch status चलाएँ और दो पंक्तियाँ पढ़ें। kernel state रिपोर्ट करता है कि क्या आपकी चल रही kernel series सेवा द्वारा कवर की गई है, और patch state रिपोर्ट करता है कि क्या उस kernel के लिए patches लोड किए गए हैं। आप ls /sys/kernel/livepatch/ के साथ सीधे kernel साइड की भी जाँच कर सकते हैं, जो प्रत्येक लोड किए गए patch के लिए एक directory सूचीबद्ध करता है। खाली सूची का मतलब है कि अभी memory में कुछ भी patch नहीं किया गया है, चाहे client कुछ भी कहे।

क्या व्यक्तिगत VPS पर Ubuntu Pro मुफ्त है?

हाँ, एक निर्धारित सीमा के भीतर। Canonical का कहना है कि Ubuntu Pro "अगस्त 2026 तक 5 physical machines तक व्यक्तिगत उपयोग के लिए हमेशा मुफ्त रहेगा", और आधिकारिक Ubuntu Community सदस्यों के लिए यह सीमा 50 machines तक है। व्यावसायिक उपयोग के लिए सशुल्क सदस्यता (paid subscription) की आवश्यकता होती है। आप अपने Ubuntu Pro अकाउंट पेज से प्राप्त token का उपयोग करके sudo pro attach TOKEN के साथ एक machine को जोड़ते हैं, फिर sudo pro enable livepatch के साथ सेवा को सक्षम करते हैं।

Livepatch चलने के बाद भी kernel CVE क्यों unfixed के रूप में सूचीबद्ध है?

आमतौर पर इसके दो कारण होते हैं। हो सकता है कि fix गंभीरता सीमा (severity threshold) से नीचे हो, क्योंकि Canonical केवल "critical और high Common Vulnerability Scoring System (CVSS) और Ubuntu Priority रेटिंग वाले kernel vulnerabilities" को ही live patch करता है और बाकी को डिस्क पर मौजूद package के लिए छोड़ देता है। या फिर fix को function body में बदलाव के रूप में व्यक्त नहीं किया जा सकता है, उदाहरण के लिए जब upstream ने data structure बदल दिया हो, जिसे live patching पहले से आवंटित objects पर सुरक्षित रूप से नहीं कर सकता है। दोनों ही मामलों का समाधान एक ही है: अपडेट किया गया kernel package इंस्टॉल करें और उसमें boot करें।

Live kernel patching किन चीजों को बिल्कुल भी कवर नहीं करता है?

Userspace को। Canonical स्पष्ट है कि Livepatch "OpenSSL या glibc जैसी userspace libraries को patch नहीं करता है, क्योंकि यह unattended-upgrades या किसी systems management टूल की जिम्मेदारी है।" यह नया kernel version या नया feature भी प्रदान नहीं कर सकता है, क्योंकि यह केवल उसी series के भीतर function bodies को बदलता है जिसे आप पहले से चला रहे हैं। और यह __init functions को patch नहीं कर सकता है, जो सर्वर के चालू होने तक पहले ही चल चुके होते हैं और memory से हटा दिए जाते हैं।