VPS میں live kernel patching یا reboot: فرق کیا ہے؟

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

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

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

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

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

kernel میں لائیو patching کے لیے ایک built-in 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 خود kernel کے function tracer، ftrace، کو استعمال کرتی ہے۔ زیادہ تر kernel functions کو function کے بالکل آغاز میں ایک call instruction کے ساتھ compile کیا جاتا ہے، اس سے پہلے کہ 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 ہوتا ہے، اس کے اندر موجود کوئی ایک line نہیں۔

زیادہ مشکل حصہ running system کو محفوظ طریقے سے تبدیل کرنا ہے۔ اگر function تبدیل کرتے وقت کسی CPU کے stack پر پرانا code ابھی چل رہا ہو تو پرانے اور نئے behaviour کا امتزاج پیدا ہو سکتا ہے۔ Upstream Linux اس صورتِ حال کو per-task consistency model کے ذریعے handle کرتا ہے۔ kernel documentation اسے ایک hybrid model کہتی ہے: "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 پر یہی معمول کی ابتدائی state ہوتی ہے۔

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

Function bodies کو patch کیا جاتا ہے۔ باقی ہر چیز 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 کے لیے انہیں ہاتھ سے لکھنا پڑتا ہے؛ یہ خودکار نہیں ہوتے۔
• ایسے fixes جو بیک وقت کئی functions میں پھیلے ہوں۔ اگر کسی fix میں functions کے ایک گروپ کے درمیان lock ordering تبدیل ہو تو ان سب کو ایک ساتھ تبدیل کرنا ضروری ہوتا ہے، اور consistency model پورے machine کو ایک لمحے پر freeze کرنے کے بجائے tasks کو تبدیل کرتا ہے۔
• Initialisation code۔ __init سے نشان زد functions server کے up ہونے تک پہلے ہی چل کر free ہو چکے ہوتے ہیں، اس لیے redirect کرنے کے لیے کچھ باقی نہیں رہتا۔
• نئے kernel versions اور نئی features۔ Live patching آپ کو ایک ہی kernel series کے اندر ایک patch level سے دوسرے 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 نہیں ہوتا، اس لیے اسی machine پر 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 کے مطابق یہ "is and always will be free for personal use on up to 5 physical machines" ہے، جبکہ سرکاری Ubuntu Community اراکین کے لیے یہ حد 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 کو support کرتا ہے، جن میں وہ 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 فوری check کراتا ہے۔ جس server کی آپ کو فکر ہے، اس پر script کو shell میں pipe کرنے سے پہلے installer پڑھ لیں۔

kpatch اور kGraft اس ٹیکنالوجی کے پیش رو ہیں۔ kGraft، SUSE سے آیا تھا، جبکہ kpatch، Red Hat سے آیا تھا۔ آج upstream Linux میں live patching core دونوں تصورات کے امتزاج پر مبنی ہے۔ kpatch خود مرحلہ وار ختم ہو رہا ہے۔ اس کے README کے مطابق Linux 6.19 سے "the kpatch project is deprecated and in 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 step مکمل ہونے کے لیے 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 جس پر کوئی patches لاگو نہ ہوئے ہوں، client کا مسئلہ ہے۔ Uncovered kernel، kernel کا مسئلہ ہے، اور client کی کوئی setting اسے درست نہیں کر سکتی۔

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

Live patching ہنگامی ضرورت ختم کر دیتی ہے، اس لیے زیرِ التوا 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 ہمیشہ یہ file بناتا ہے۔ .pkgs file ان packages کی فہرست دیتی ہے جنہوں نے reboot کی درخواست کی ہے۔ اگر پہلی command کا جواب No such file or directory ہو، تو machine کے آخری boot کے بعد کسی package نے reboot کی درخواست نہیں کی۔ موجودہ Ubuntu میں /var/run، /run کی symbolic link ہے، اس لیے دونوں paths اسی file تک پہنچتے ہیں۔

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

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

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

اسی سوال کے 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 پر boot ہوتا ہے جسے bootloader منتخب کرتا ہے، اور پھر Livepatch client ان patches کو دوبارہ apply کر دیتا ہے جو اب بھی قابلِ اطلاق ہوں۔ ان دونوں مراحل کے درمیان سسٹم unpatched code چلا رہا ہوتا ہے۔ یہ اس بات کی ایک اور وجہ ہے کہ پرانے kernel کے بجائے موجودہ kernel پر boot کرنا چاہیے۔

Coverage ہر kernel series کے لیے الگ ہوتی ہے، اور series ریٹائر ہو جاتی ہیں۔ جب آپ کی running series supported list سے خارج ہو جاتی ہے تو kernel state لائن coverage رپورٹ کرنا بند کر دیتی ہے، اور واحد حل نیا kernel ہے۔ اس کے لیے reboot کرنا پڑتا ہے۔

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

طویل عرصے تک چلنے والے kernels ایسی state بھی جمع کر لیتے ہیں جسے patching صاف نہیں کرتی۔ Canonical کا اپنا مؤقف یہاں نقل کرنا مناسب ہے، کیونکہ یہی دیانت دارانہ وضاحت ہے: Livepatch "reboot کرنے کا متبادل نہیں ہے۔ یہ unscheduled reboots کو روک کر آپ کو زیادہ control دینے والا tool ہے۔" اس بیان میں اصل مفہوم 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) میں لکھنے سے ناکام کر دیتا ہے۔ اس کے نتیجے میں bootloader entry ایسی image کی طرف اشارہ کر سکتی ہے جو کبھی مکمل نہیں ہوئی۔
• کم از کم ایک معلوم طور پر درست پرانا kernel نصب رکھیں۔ GRUB اسے "Advanced options for Ubuntu" کے تحت دکھاتا ہے۔ نیا kernel ناکام ہونے پر اسے boot کرنا recovery کا تیز ترین طریقہ ہے۔
• ضرورت پڑنے سے پہلے اپنے provider کا rescue mode تلاش کر لیں۔ اگر reboot کے بعد console پر initramfs prompt دکھائی دے تو repair وہیں کی جاتی ہے۔

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

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

اس سے reboot پانچ منٹ بعد کے لیے schedule ہوتا ہے اور 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 route اس guide میں موجود ہے جو kernel update کے بعد boot نہ ہونے والے 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 ناکام ہو جاتا ہے۔ یوں machine وہ update بھی install نہیں کر پاتی جس کی اسے ضرورت ہوتی ہے۔ apt autoremove path اہل ہونے کے بعد پرانے kernels صاف کر دیتا ہے، لیکن ایسی machine پر جو کبھی reboot نہیں ہوتی، وہ ہمیشہ اہل نہیں ہوتے۔ اس کی وجہ یہ ہے کہ package manager اس kernel کو remove نہیں کرتا جس کے بارے میں ممکن ہو کہ آپ ابھی اسی کو چلا رہے ہوں۔

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

FAQ

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

نہیں۔ Live patches چلتے ہوئے kernel میں load ہوتے ہیں اور boot image میں نہیں لکھے جاتے، اس لیے disk پر موجود linux-image اسی version پر رہتا ہے جس سے آپ نے boot کیا تھا۔ Canonical اسے واضح طور پر بیان کرتا ہے: Livepatch "reboot کرنے کا متبادل نہیں ہے۔ یہ ایک ایسا tool ہے جو غیر مقررہ 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 ہو چکے ہیں یا نہیں۔ آپ ls /sys/kernel/livepatch/ کے ذریعے kernel side بھی براہ راست check کر سکتے ہیں، جو ہر loaded patch کے لیے ایک directory دکھاتا ہے۔ خالی listing کا مطلب ہے کہ اس وقت memory میں کچھ بھی patched نہیں ہے، چاہے client کچھ بھی بتا رہا ہو۔

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

ہاں، ایک documented limit کے اندر۔ Canonical کے الفاظ کے مطابق Ubuntu Pro "ذاتی استعمال کے لیے 5 physical machines تک مفت ہے اور ہمیشہ مفت رہے گا"، جبکہ 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 "critical اور high Common Vulnerability Scoring System (CVSS) اور Ubuntu Priority ratings والی kernel vulnerabilities" کو live patch کرتا ہے اور باقی fixes کو disk پر موجود package کے لیے چھوڑ دیتا ہے۔ یا fix کو function body میں change کے طور پر بیان نہ کیا جا سکتا ہو، مثلاً 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 ہو چکے ہوتے ہیں۔