VPS पर live kernel patching क्या है और यह कब काम आती है

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 patch किया गया है, वह अभी भी disk पर मौजूद पुराने kernel image से ही boot है, और वे सभी patches केवल memory में ही मौजूद हैं।

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

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 कर सकता है, इसलिए बिना उस entry call के compile किए गए function को बिल्कुल भी 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 पर जाते हैं, केवल तभी जब 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 data) को संशोधित करते हैं, वे सीधे समर्थित नहीं हैं।" इसके समाधान के रूप में शैडो वेरिएबल्स और कॉलबैक मौजूद हैं, लेकिन उन्हें हर पैच के लिए मैन्युअल रूप से लिखना पड़ता है, वे स्वचालित नहीं होते।
• एक साथ कई फंक्शन्स में फैले हुए फिक्स। ऐसा फिक्स जो फंक्शन्स के समूह में लॉक ऑर्डरिंग को बदलता है, उसे उन सभी फंक्शन्स में एक साथ बदलाव की आवश्यकता होती है। कंसिस्टेंसी मॉडल पूरी मशीन को एक ही क्षण में फ्रीज करने के बजाय टास्क को स्विच करता है।
• इनिशियलाइज़ेशन कोड। __init के रूप में चिह्नित फंक्शन्स आपके सर्वर के चालू होने तक पहले ही रन होकर फ्री हो चुके होते हैं, इसलिए रीडायरेक्ट करने के लिए कुछ भी शेष नहीं बचता।
• नए कर्नल वर्ज़न और नए फीचर्स। लाइव पैचिंग आपको एक कर्नल सीरीज़ के भीतर ही पैच लेवल पर आगे ले जाती है। यह आपको कभी भी एक सीरीज़ से दूसरी सीरीज़ में नहीं ले जाती और न ही कोई नया फीचर जोड़ती है। यदि आपको किसी नई सीरीज़ से कुछ चाहिए, जैसे कि Linux 7.1 में आए बदलाव, तो आपको उस कर्नल को इंस्टॉल करके बूट करना होगा।
• यूज़रस्पेस। Canonical स्वयं इस सीमा को स्पष्ट करता है: "Canonical Livepatch, OpenSSL या glibc जैसी यूज़रस्पेस लाइब्रेरीज़ को पैच नहीं करता है, क्योंकि यह unattended-upgrades या सिस्टम मैनेजमेंट टूल की जिम्मेदारी है।" पुराने OpenSSL के साथ लाइव पैच किया गया कर्नल एक पूरी तरह से पैच किया हुआ सर्वर नहीं है, इसलिए उसी बॉक्स पर यूज़रस्पेस पैकेज को संभालने के लिए unattended upgrades को चालू रखें।

Ubuntu की सर्विस पर गंभीरता (severity) की एक सीमा भी है। 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 अपने निर्धारित समय पर नए patches की जाँच करता है, और /usr/bin/kcarectl --update एक manual जाँच को बाध्य करता है। किसी भी महत्वपूर्ण सर्वर पर इसे सीधे shell में pipe करने से पहले installer को अवश्य पढ़ें।

kpatch और kGraft इसके पूर्वज हैं। kGraft SUSE से आया था, kpatch Red Hat से, और आज upstream Linux में live patching का मूल इन दोनों विचारों का मिश्रण है। 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 सपोर्ट नहीं करता है, तो यह पंक्ति खराब (bad) हो जाती है। 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 का एक सिम्बॉलिक लिंक (symlink) है, इसलिए कोई भी पाथ उसी फ़ाइल तक पहुँचता है।

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

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

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

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

sudo needrestart -r l

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

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

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

Coverage प्रति kernel series होती है, और series को retired कर दिया जाता है। जब आपकी running series supported list से बाहर हो जाती है, तो kernel state line coverage की रिपोर्ट देना बंद कर देती है, और इसका एकमात्र समाधान एक नया kernel है। इसके लिए reboot करना आवश्यक है।

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

लंबे समय तक चलने वाले kernels में ऐसी स्थिति (state) भी जमा हो जाती है जिसे patching साफ नहीं करती है। Canonical का अपना पक्ष उद्धृत करने योग्य है, क्योंकि यह ईमानदार है: Livepatch "reboot करने का विकल्प नहीं है। यह एक ऐसा tool है जो आपको 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 retire हो जाती है, तो कवरेज भी समाप्त हो जाती है, और मध्यम गंभीरता (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 सूचीबद्ध करता है। एक खाली सूची का मतलब है कि अभी मेमोरी में कुछ भी patch नहीं किया गया है, चाहे client कुछ भी कहे।

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

हाँ, एक प्रलेखित सीमा के भीतर। Canonical का कहना है कि Ubuntu Pro "अगस्त 2026 तक 5 physical मशीनों तक व्यक्तिगत उपयोग के लिए मुफ्त है और हमेशा रहेगा", जो आधिकारिक Ubuntu Community सदस्यों के लिए 50 मशीनों तक है। व्यावसायिक उपयोग के लिए सशुल्क सदस्यता की आवश्यकता होती है। आप अपने Ubuntu Pro अकाउंट पेज से प्राप्त token का उपयोग करके sudo pro attach TOKEN के साथ एक मशीन जोड़ते हैं, फिर 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 नहीं कर सकता, जो सर्वर के चालू होने तक चल चुके होते हैं और मेमोरी से हटा दिए गए होते हैं।