VPS پر live kernel patching یا reboot: کیا بہتر ہے؟

VPS پر live kernel patching کیا کرتی ہے

Live kernel patching چلتی ہوئی machine پر kernel کی security fixes لاگو کرتی ہے، اس کے لیے reboot ضروری نہیں ہوتا اور connections بھی منقطع نہیں ہوتے۔ کسی function کی fixed copy کو kernel module کے طور پر load کیا جاتا ہے، اور پرانے function کی ہر call کو نئی copy کی طرف redirect کر دیا جاتا ہے، جبکہ server network traffic فراہم کرتا رہتا ہے۔ یہی طریقۂ کار واضح کرتا ہے کہ live patching کن کاموں کے لیے مفید ہے اور کیا نہیں کر سکتی۔

اس سے وقت ملتا ہے۔ یہ reboot کی ضرورت ختم نہیں کرتی۔ جو server چھ ماہ تک live patched رہا ہو، وہ disk پر موجود پرانی kernel image سے ہی boot ہوا ہوتا ہے، اور ان تمام patches میں سے ہر ایک صرف memory میں موجود ہوتا ہے۔

Live patching کو اکثر managed plan کی feature کے طور پر پیش کیا جاتا ہے۔ unmanaged box پر آپ اسے خود دو commands سے enable کر سکتے ہیں۔ اس فرق کی قیمت ادا کرنے سے پہلے یہ بات جاننا مفید ہے کہ managed اور unmanaged VPS میں کیا فرق ہے۔

لائیو kernel patching کیسے کام کرتی ہے؟

kernel میں ایک built-in live patching core موجود ہوتا ہے، جسے CONFIG_LIVEPATCH کے ساتھ compile کیا جاتا ہے۔ اپنے running kernel میں اسے چیک کریں:

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

CONFIG_LIVEPATCH=y دکھانے والی سطر کا مطلب ہے کہ آپ کا running kernel اس core کے ساتھ build کیا گیا تھا۔ اس کے بغیر کوئی live patching service اس machine پر کوئی کام نہیں کر سکتی۔

Redirection کے لیے ftrace استعمال ہوتا ہے، جو kernel کا function tracer ہے۔ زیادہ تر kernel functions کو اس طرح compile کیا جاتا ہے کہ function کے بالکل شروع میں call instruction موجود ہو، اس سے پہلے کہ arguments یا stack کو تبدیل کیا جائے۔ ftrace اس call site کو hook کے طور پر استعمال کرتا ہے۔ جب patch apply کیا جاتا ہے تو live patching core target function پر ftrace handler register کرتا ہے، اور handler execution کو اس کے بجائے replacement function کی طرف بھیج دیتا ہے۔ kernel documentation میں اسے واضح طور پر بیان کیا گیا ہے: "Livepatching typically needs to redirect the code at the very beginning of the function entry before the function parameters or the stack are in any way modified."

اس جملے سے دو نتائج نکلتے ہیں، اور دونوں آگے اہم ہیں۔ صرف وہی function patch کیا جا سکتا ہے جسے ftrace hook کر سکے، اس لیے entry call کے بغیر compile کیا گیا function بالکل patch نہیں ہو سکتا۔ مزید یہ کہ patching unit پورا function ہوتا ہے، اس function کے اندر ایک single line کبھی نہیں۔

زیادہ مشکل حصہ live system کو محفوظ طریقے سے switch کرنا ہے۔ اگر function swap کرتے وقت کسی CPU کے stack پر پرانا code اب بھی چل رہا ہو تو پرانے اور نئے behavior کا مرکب پیدا ہو جاتا ہے۔ Upstream Linux اسے per-task consistency model کے ذریعے handle کرتا ہے، جسے kernel docs ایک hybrid کے طور پر بیان کرتے ہیں: "it uses kGraft's per-task consistency and syscall barrier switching combined with kpatch's stack trace switching." Tasks ایک ایک کر کے نئے code پر منتقل ہوتے ہیں، اور یہ صرف اس وقت ہوتا ہے جب kernel ثابت کر سکے کہ task اس وقت patched function کے اندر موجود نہیں ہے۔ جب تک ہر task منتقل نہیں ہو جاتا، patch transition میں رہتا ہے۔

آپ نتیجہ خود دیکھ سکتے ہیں۔ Applied patches /sys/kernel/livepatch کے تحت ظاہر ہوتے ہیں۔ ہر patch کے لیے ایک directory ہوتی ہے، اور اس کے اندر patched functions کی فہرست موجود ہوتی ہے۔

ls /sys/kernel/livepatch/

خالی listing کا مطلب ہے کہ memory میں کوئی live patch loaded نہیں ہے۔ نئے server پر یہ معمول کی ابتدائی حالت ہے۔

لائیو kernel patching کیا درست نہیں کر سکتی

صرف function bodies پر patch لگائی جاتی ہے۔ باقی کسی چیز پر نہیں۔

• بدلے ہوئے data structures۔ اگر upstream fix کسی struct میں field شامل کرتی ہے یا موجودہ field کے مفہوم کو بدلتی ہے تو پہلے سے allocate اور زیرِ استعمال objects کو محفوظ طریقے سے دوبارہ لکھنے کا کوئی طریقہ نہیں ہوتا۔ kpatch project اسی صورتِ حال کو براہِ راست بیان کرتا ہے: "Patches which modify statically allocated data are not directly supported." Shadow variables اور callbacks بطور workaround موجود ہیں، لیکن یہ ہر patch کے لیے دستی طور پر لکھے جاتے ہیں، خودکار طور پر نہیں۔
• ایک ہی وقت میں کئی functions میں پھیلی ہوئی fixes۔ اگر کوئی fix functions کے ایک گروپ میں lock ordering تبدیل کرتی ہے تو ان سب کو بیک وقت تبدیل کرنا ضروری ہوتا ہے، اور consistency model پوری machine کو ایک لمحے پر freeze کرنے کے بجائے tasks کو تبدیل کرتا ہے۔
• Initialisation code۔ __init سے نشان زد functions آپ کے server کے up ہونے تک پہلے ہی run ہو کر free ہو چکے ہوتے ہیں، اس لیے redirect کرنے کے لیے کچھ باقی نہیں رہتا۔
• نئے kernel versions اور نئی features۔ Live patching آپ کو ایک kernel series کے اندر patch level پر آگے لے جاتی ہے۔ یہ کبھی ایک series سے اگلی series میں منتقل نہیں کرتی، اور نہ ہی کوئی feature شامل کرتی ہے۔ اگر آپ کو نئی series کی کوئی چیز چاہیے، مثلاً Linux 7.1 میں شامل ہونے والی تبدیلیاں، تو وہ kernel install کریں اور اسے boot کریں۔
• Userspace۔ Canonical اس حد کو خود بیان کرتا ہے: "Canonical Livepatch does not patch userspace libraries like OpenSSL or glibc, because that is the responsibility of unattended-upgrades or a systems management tool." stale OpenSSL کے ساتھ live patched kernel، patched server نہیں ہوتا۔ اس لیے اسی box پر userspace packages کی ذمہ داری unattended upgrades کو سونپیں۔

Ubuntu کی service میں severity کی ایک حد بھی ہے۔ Canonical کے مطابق یہ "patches kernel vulnerabilities with critical and high Common Vulnerability Scoring System (CVSS) and Ubuntu Priority ratings." ایک CVE (common vulnerabilities and exposures) identifier ایک flaw کی شناخت کرتا ہے، جبکہ CVSS اس سے منسلک score ہوتا ہے۔ medium-rated kernel CVE کو disk پر موجود package میں fix کیا جاتا ہے اور live patch نہیں کیا جاتا۔ اس لیے یہ آپ کے running kernel تک اگلے reboot پر پہنچتا ہے، اس سے پہلے نہیں۔

لائیو kernel patching کے کیا اختیارات ہیں؟

عام طور پر تین سلسلے استعمال ہوتے ہیں، اور یہ سب ایک ہی kernel mechanism کو چلاتے ہیں۔

Canonical Livepatch Ubuntu Pro کے ذریعے فراہم کیا جاتا ہے۔ Ubuntu Pro ذاتی استعمال کے لیے مفت ہے، اور Canonical کے مطابق یہ "ذاتی استعمال کے لیے ہمیشہ مفت رہے گا، زیادہ سے زیادہ 5 physical machines پر"، جبکہ official Ubuntu Community members کے لیے یہ حد 50 machines ہے۔ August 2026 تک یہی دستاویزی حد ہے۔ تجارتی استعمال کے لیے paid subscription درکار ہے۔ Coverage ہر kernel series اور ہر flavour کے لیے دی جاتی ہے۔ اس میں supported long term support (LTS) releases کے general availability (GA) kernels اور ان کے hardware enablement (HWE) kernels شامل ہیں۔ یہ coverage generic، aws، azure، gcp، oracle، ibm اور lowlatency جیسے flavours پر لاگو ہوتی ہے۔ اس پر انحصار کرنے سے پہلے اپنے kernel کو Canonical کی شائع کردہ kernel list سے ضرور ملائیں۔

KernelCare، TuxCare کی طرف سے فراہم کردہ ایک commercial agent ہے، جو متعدد distributions کو cover کرتا ہے، جن میں وہ distributions بھی شامل ہیں جن کی کوئی first-party service نہیں ہے۔ اس کی دستاویزی installation 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 فوری جانچ پر مجبور کرتا ہے۔ کسی اہم server پر اسے 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 میں ہے"، اور upstream kernel میں kpatch-build کو klp-build سے تبدیل کیا جا رہا ہے۔ RHEL اور اس کی rebuilds پر patches خود بنانے کے بجائے distribution کی اپنی service استعمال کریں۔

انتخاب اس بنیاد پر کریں کہ آپ کی distribution کس چیز کو support کرتی ہے اور آپ کا licence کس چیز کی اجازت دیتا ہے۔ ہر صورت میں kernel-level نتیجہ ایک ہی ہوتا ہے۔

Ubuntu پر Canonical Livepatch کیسے فعال کریں

پہلے اپنے Ubuntu Pro اکاؤنٹ کے صفحے سے token حاصل کریں۔ ذیل میں دی گئی دونوں commands کے لیے outbound network access کا فعال ہونا ضروری ہے، کیونکہ client attach ہونے اور patches حاصل کرنے کے لیے Canonical کے servers سے رابطہ کرتا ہے۔

sudo pro attach TOKEN
sudo pro status

sudo pro attach کو token کے بغیر چلانے سے اس کے بجائے browser-based flow شروع ہوتا ہے اور ایسا code دکھایا جاتا ہے جسے Canonical کی site پر درج کرنا ہوتا ہے۔ Attach کرنے سے تجویز کردہ services خودکار طور پر فعال ہو جاتی ہیں۔ موجودہ LTS release میں ان services میں Livepatch شامل ہوتا ہے۔ اگر آپ services خود منتخب کرنا چاہتے ہیں تو sudo pro attach --no-auto-enable استعمال کریں۔

اگر Livepatch پہلے سے فعال نہ ہو:

sudo pro enable livepatch
sudo canonical-livepatch status

یہ service canonical-livepatch snap سے چلتی ہے، اس لیے enable کا مرحلہ مکمل ہونے کے لیے snapd کا درست طور پر کام کرنا ضروری ہے۔ pro status services کی ایک table دکھاتی ہے جس میں ان کی entitlement اور status شامل ہوتی ہے۔ canonical-livepatch status ہر kernel کی تفصیلی معلومات دکھاتی ہے، اور Canonical کی documentation اس شکل میں output دکھاتی ہے:

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

دو lines جواب فراہم کرتی ہیں۔ kernel state بتاتی ہے کہ آپ جو series چلا رہے ہیں، وہ service کے دائرۂ کار میں شامل ہے یا نہیں۔ جب آپ ایسا kernel boot کرتے ہیں جسے Livepatch support نہیں کرتا، تو یہی line غلط حالت ظاہر کرتی ہے۔ patch state بتاتی ہے کہ اس kernel پر لاگو ہونے والے patches واقعی load ہوئے ہیں یا نہیں۔ ایسا covered kernel جس پر کوئی patch apply نہ ہوا ہو، client کا مسئلہ ہے۔ ایسا uncovered kernel، kernel کا مسئلہ ہے، اور client کی کوئی setting اسے درست نہیں کر سکتی۔

ریبوٹ کے زیر التوا ہونے کا کیسے معلوم کریں؟

Livepatching ہنگامی ضرورت ختم کر دیتی ہے، اس لیے زیر التوا reboot کی نشاندہی خودکار طور پر واضح نہیں رہتی۔ آپ کو اسے خود تلاش کرنا پڑتا ہے۔

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

Package manager /var/run/reboot-required بناتا ہے جب کسی installed package کی تبدیلیاں مؤثر ہونے کے لیے restart درکار ہو، اور ہر نیا linux-image package ہمیشہ یہ فائل بناتا ہے۔ .pkgs فائل ان packages کی فہرست دیتی ہے جنہوں نے reboot کی درخواست کی ہے۔ اگر پہلی command کا جواب No such file or directory ہو تو آخری boot کے بعد کسی چیز نے reboot کی درخواست نہیں کی۔ موجودہ Ubuntu میں /var/run، /run کا symbolic link ہے، اس لیے دونوں paths اسی فائل تک پہنچتے ہیں۔

یہ flag ایک tmpfs میں موجود ہوتا ہے اور ہر boot پر reset ہو جاتا ہے، اس لیے اسے خود kernel کے خلاف verify کریں:

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

uname -r اس kernel کو دکھاتا ہے جو اس وقت چل رہا ہے۔ دوسری command disk پر installed kernel packages دکھاتی ہے۔ اگر اس فہرست میں موجود کوئی linux-image، uname -r کی رپورٹ کردہ version سے نیا ہو تو Livepatch status کچھ بھی کہے، machine پرانا kernel چلا رہی ہے۔ یہی اہم check ہے، کیونکہ live patching کا مقصد running kernel کو محفوظ بنانا ہے، اسے current بنانا نہیں۔

اسی سوال کے userspace حصے کے لیے needrestart Ubuntu Server پر default طور پر installed ہوتا ہے اور ان running services کی فہرست دیتا ہے جو اب بھی deleted library files کو کھولے ہوئے ہیں۔

sudo needrestart -r l

-r l flags کی جوڑی کا مطلب "صرف فہرست بنائیں" ہے، اس لیے یہ صرف معلومات دکھاتی ہے اور کوئی تبدیلی نہیں کرتی۔

ریبوٹ کی ضرورت کبھی ختم کیوں نہیں ہوتی

ڈسک پر موجود kernel تبدیل نہیں ہوتا۔ Live patches چلتے ہوئے kernel میں load ہوتے ہیں اور boot image میں کبھی نہیں لکھے جاتے۔ اس لیے reboot کے بعد سسٹم اسی linux-image پر چلتا ہے جسے bootloader منتخب کرتا ہے، اور Livepatch client ان patches کو دوبارہ apply کرتا ہے جو اب بھی قابلِ اطلاق ہوں۔ ان دونوں مراحل کے درمیان سسٹم unpatched code چلا رہا ہوتا ہے۔ یہ موجودہ kernel کے بجائے پرانا kernel boot نہ کرنے کی ایک اور وجہ ہے۔

Coverage ہر kernel series کے لیے الگ ہوتی ہے، اور series ریٹائر ہو جاتی ہیں۔ جب آپ کی چلتی ہوئی series supported list سے خارج ہو جاتی ہے تو kernel state لائن coverage رپورٹ کرنا بند کر دیتی ہے، اور واحد حل نیا kernel ہے۔ اس کے لیے reboot کرنا پڑتا ہے۔ LTS release میں نئی series عموماً hardware enablement kernel کے طور پر 26.04.1 جیسی point release میں شامل ہو کر آپ تک پہنچتی ہے۔ یوں replacement پہلے ہی archive میں موجود ہوتا ہے، اور صرف آپ کے مقرر کردہ وقت پر boot درکار ہوتا ہے۔

درمیانی اور کم severity والے kernel fixes کو کبھی live patch نہیں کیا جاتا۔ وہ ڈسک پر موجود package میں رہتے ہیں اور آپ تک صرف boot کے بعد پہنچتے ہیں۔

طویل عرصے تک چلنے والے kernels ایسی state بھی جمع کر لیتے ہیں جسے patching صاف نہیں کرتی۔ Canonical کا اپنا مؤقف یہاں نقل کرنا مناسب ہے، کیونکہ یہی درست وضاحت ہے: Livepatch "reboot کرنے کا متبادل نہیں ہے۔ یہ ایک ایسا tool ہے جو unscheduled reboots روک کر آپ کو زیادہ control دیتا ہے۔" اس جملے میں بنیادی معنی unscheduled کا ہے۔ آپ پھر بھی reboot کرتے ہیں۔ وقت کا انتخاب آپ کرتے ہیں۔

واپس آن لائن ہونے والے reboot کو شیڈول کرنے کا طریقہ

اگر آپ console تک رسائی حاصل نہ کر سکیں تو VPS کا reboot یک طرفہ کارروائی بن جاتا ہے۔ reboot چلانے سے پہلے یقینی بنائیں کہ machine واپس نہ آنے کی صورت میں آپ دوبارہ رسائی حاصل کر سکتے ہیں۔

• تصدیق کریں کہ آپ کا provider control panel میں serial console یا VNC (virtual network computing) view فراہم کرتا ہے، اور اسے outage کے دوران نہیں بلکہ ابھی کھول کر رکھیں۔
• df -h /boot سے خالی جگہ چیک کریں۔ مکمل /boot kernel package کو اس کے initramfs (initial RAM filesystem) لکھتے وقت fail کر دیتا ہے۔ اس کے نتیجے میں bootloader entry ایسی image کی طرف اشارہ کر سکتی ہے جو مکمل نہیں ہوئی۔
• کم از کم ایک معلوم طور پر درست پرانا kernel انسٹال رکھیں۔ GRUB اسے "Advanced options for Ubuntu" کے تحت دکھاتا ہے۔ نیا kernel fail ہونے کی صورت میں اسے boot کرنا recovery کا تیز ترین طریقہ ہے۔
• ضرورت پڑنے سے پہلے اپنے provider کا rescue mode تلاش کر لیں۔ اگر reboot کے بعد console پر initramfs prompt دکھائی دے تو repair وہیں کی جاتی ہے۔

اس کے بعد reboot ایسے وقت شیڈول کریں جب آپ بیدار ہوں:

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

اس سے reboot پانچ منٹ بعد کے لیے شیڈول ہوتا ہے اور logged-in users کو message بھیجا جاتا ہے۔ sudo shutdown -c اسے cancel کرتا ہے۔ machine واپس آنے کے بعد دونوں حصوں کی تصدیق کریں:

uname -r
sudo canonical-livepatch status

uname -r کو اب نیا kernel report کرنا چاہیے، اور status output میں نئی series کو covered دکھانا چاہیے۔ اگر machine بالکل واپس نہ آئے تو خرابی تقریباً ہمیشہ network کے بجائے boot path میں ہوتی ہے۔ ایسی صورت میں recovery کا طریقہ kernel update کے بعد boot نہ ہونے والے VPS کی رہنما دستاویز میں دیا گیا ہے۔

پرانے kernels کو صاف کرنا اب بھی کیوں ضروری ہے

Live patching اس مسئلے کو بہتر بنانے کے بجائے مزید سنگین بنا دیتی ہے، کیونکہ linux-image packages مسلسل install ہوتے رہتے ہیں اور reboot کرنے کی ضرورت کا دباؤ کم ہو جاتا ہے۔ ہر kernel ایک boot image، ایک initramfs، ایک modules tree اور عموماً ایک headers package install کرتا ہے۔ چند سو megabytes کی الگ /boot partition والے چھوٹے VPS میں ان میں سے تین یا چار packages اسے بھر دیتے ہیں۔

مکمل /boot کے بعد اگلا kernel install نہیں ہو پاتا۔ یوں machine وہ update بھی install نہیں کر پاتی جس کی اسے ضرورت ہے۔ apt autoremove path ایسے پرانے kernels صاف کر دیتا ہے جو removal کے لیے eligible ہوں، لیکن ایسی machine پر جو کبھی reboot نہیں ہوتی، وہ ہمیشہ eligible نہیں ہوتے۔ اس کی وجہ یہ ہے کہ package manager ایسے kernel کو remove نہیں کرے گا جسے آپ اب بھی چلا رہے ہوں۔

اس لیے installed kernels کی فہرست دیکھیں، running kernel اور ایک معلوم طور پر درست fallback رکھیں، اور باقی کو Ubuntu پر پرانے kernels remove کرنے کے محفوظ طریقہ کار کے مطابق remove کریں۔ uname -r اس وقت جس kernel کی اطلاع دیتا ہے، اسے کبھی remove نہ کریں۔

FAQ

کیا live kernel patching کا مطلب ہے کہ مجھے اپنے VPS کو کبھی reboot نہیں کرنا پڑے گا؟

نہیں۔ Live patches چلتے ہوئے kernel میں load ہوتے ہیں اور boot image میں نہیں لکھے جاتے، اس لیے disk پر موجود linux-image اسی version پر رہتا ہے جس سے آپ نے boot کیا تھا۔ Canonical اسے واضح طور پر بیان کرتا ہے: Livepatch "rebooting کا متبادل نہیں ہے۔ یہ ایک ایسا tool ہے جو unscheduled reboots کو روک کر آپ کو زیادہ control دیتا ہے۔" جب آپ کی kernel series retired ہو جاتی ہے تو coverage بھی ختم ہو جاتی ہے، اور medium severity والے kernel fixes کو کبھی live patch نہیں کیا جاتا۔ کسی reboot کے آپ پر مسلط ہونے کا انتظار کرنے کے بجائے اپنی منتخب کردہ cadence کے مطابق maintenance reboot schedule کریں۔

میں کیسے جانچوں کہ live kernel patching واقعی patches apply کر رہی ہے؟

sudo canonical-livepatch status چلائیں اور دو lines پڑھیں۔ kernel state بتاتا ہے کہ آیا آپ کی running kernel series اس service کے دائرۂ کار میں شامل ہے، جبکہ patch state بتاتا ہے کہ آیا اس kernel کے patches load ہو چکے ہیں۔ آپ kernel side کو براہِ راست ls /sys/kernel/livepatch/ کے ذریعے بھی check کر سکتے ہیں، جو ہر loaded patch کے لیے ایک directory دکھاتا ہے۔ خالی listing کا مطلب ہے کہ اس وقت memory میں کچھ بھی patched نہیں ہے، چاہے client کچھ بھی بتا رہا ہو۔

کیا personal VPS پر Ubuntu Pro مفت ہے؟

ہاں، ایک documented limit کے اندر۔ Canonical کے مطابق Ubuntu Pro "5 physical machines تک personal use کے لیے مفت ہے اور ہمیشہ رہے گا"، جبکہ August 2026 تک official Ubuntu Community members کے لیے یہ حد 50 machines ہے۔ Commercial use کے لیے paid subscription درکار ہے۔ اپنے Ubuntu Pro account page سے حاصل کردہ token کے ذریعے sudo pro attach TOKEN سے machine attach کریں، پھر sudo pro enable livepatch کے ذریعے service enable کریں۔

Livepatch چلنے کے بعد بھی kernel CVE unfixed کیوں درج ہوتا ہے؟

عام طور پر اس کی دو وجوہات ہوتی ہیں۔ Fix severity threshold سے کم ہو سکتا ہے، کیونکہ Canonical live patches صرف "critical اور high Common Vulnerability Scoring System (CVSS) اور Ubuntu Priority ratings والی kernel vulnerabilities" کو patch کرتا ہے اور باقی کام disk پر موجود package کے لیے چھوڑ دیتا ہے۔ یا fix کو function body میں تبدیلی کے طور پر express نہ کیا جا سکتا ہو، مثلاً جب upstream نے data structure تبدیل کیا ہو۔ Live patching پہلے سے allocated objects پر ایسی تبدیلی محفوظ طریقے سے نہیں کر سکتی۔ دونوں صورتوں کا حل ایک ہی ہے: updated kernel package install کریں اور اس میں boot کریں۔

live kernel patching مکمل طور پر کن چیزوں کا احاطہ نہیں کرتی؟

Userspace۔ Canonical واضح طور پر کہتا ہے کہ Livepatch "OpenSSL یا glibc جیسی userspace libraries کو patch نہیں کرتا، کیونکہ یہ unattended-upgrades یا systems management tool کی ذمہ داری ہے۔" یہ نیا kernel version یا نیا feature بھی فراہم نہیں کر سکتا، کیونکہ یہ صرف اس series کے اندر function bodies replace کرتا ہے جو آپ پہلے ہی چلا رہے ہیں۔ اس کے علاوہ یہ __init functions کو patch نہیں کر سکتا، کیونکہ server کے up ہونے تک وہ پہلے ہی run ہو چکے ہوتے ہیں اور memory سے free ہو چکے ہوتے ہیں۔