VPS-এ live kernel patching বনাম reboot: কোনটি দরকার?

VPS-এ live kernel patching কী করে

Live kernel patching কোনো reboot ছাড়াই এবং কোনো connection বিচ্ছিন্ন না করেই চলমান মেশিনে kernel security fix প্রয়োগ করে। কোনো function-এর সংশোধিত copy kernel module হিসেবে load করা হয়। এরপর পুরোনো function-এ প্রতিটি call নতুন copy-তে redirect করা হয়, আর সার্ভারটি network traffic পরিবেশন করতে থাকে। এই প্রক্রিয়াই বোঝায় live patching কোন কাজে কার্যকর এবং কোন কাজ এটি করতে পারে না।

এটি সময় দেয়। তবে reboot-এর প্রয়োজন শেষ করে না। ছয় মাস ধরে live patched থাকা কোনো server disk-এ থাকা পুরোনো kernel image দিয়েই boot করা থাকে। ওই সময়ে প্রয়োগ করা প্রতিটি patch শুধু memory-তেই থাকে।

Live patching-কে প্রায়ই managed plan-এর একটি feature হিসেবে দেওয়া হয়। unmanaged box-এ আপনি নিজেই দুটি command দিয়ে এটি enable করতে পারেন। তাই managed ও unmanaged VPS-এর পার্থক্যের জন্য অতিরিক্ত অর্থ দেওয়ার আগে বিষয়টি জানা দরকার।

লাইভ kernel patching কীভাবে কাজ করে?

kernel-এর মধ্যে একটি live patching core রয়েছে, যা CONFIG_LIVEPATCH দিয়ে compile করা হয়। আপনার চলমান kernel-এ এটি আছে কি না পরীক্ষা করুন:

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

CONFIG_LIVEPATCH=y লেখা একটি line-এর অর্থ হলো, আপনি যে kernel চালাচ্ছেন সেটি এই core-সহ build করা হয়েছে। এটি না থাকলে ওই machine-এ কোনো live patching service কাজ করতে পারবে না।

এই redirection-এর জন্য ftrace ব্যবহার করা হয়। ftrace হলো kernel-এর function tracer। অধিকাংশ kernel function-এর একেবারে শুরুতে একটি call instruction compile করা থাকে। এর আগে function-এর argument বা stack পরিবর্তন করা হয় না। ftrace এই call site-কে hook হিসেবে ব্যবহার করে। কোনো patch প্রয়োগ করা হলে 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-ই hook করা যায়, যেটিতে ftrace hook বসাতে পারে। তাই entry call ছাড়া compile করা কোনো function একেবারেই patch করা যায় না। আর patching-এর unit হলো সম্পূর্ণ একটি function; কোনো function-এর ভেতরের একটি line কখনো নয়।

চলমান system নিরাপদে পরিবর্তন করাই কঠিন অংশ। function পরিবর্তনের সময় কোনো CPU-এর stack-এ পুরোনো code চলতে থাকলে পুরোনো ও নতুন আচরণের মিশ্রণ তৈরি হবে। Upstream Linux এই সমস্যা per-task consistency model দিয়ে সমাধান করে। kernel documentation-এ এটিকে একটি hybrid model বলা হয়েছে: “it uses kGraft's per-task consistency and syscall barrier switching combined with kpatch's stack trace switching.” Kernel নিশ্চিত করতে পারলেই যে কোনো task বর্তমানে patched function-এর ভেতরে নেই, তখন task-গুলো একে একে নতুন code-এ যায়। সব task স্থানান্তরিত না হওয়া পর্যন্ত patch transition অবস্থায় থাকে।

আপনি নিজেই ফলাফল দেখতে পারেন। প্রয়োগ করা patch-গুলো /sys/kernel/livepatch-এর অধীনে দেখা যায়। প্রতিটি patch-এর জন্য একটি directory থাকে, এবং তার ভেতরে patched function-গুলোর তালিকা থাকে।

ls /sys/kernel/livepatch/

তালিকা খালি থাকলে memory-তে কোনো live patch loaded নেই। নতুন server-এ এটিই স্বাভাবিক প্রাথমিক অবস্থা।

লাইভ kernel patching যা ঠিক করতে পারে না

শুধু function body patch করা হয়। অন্য কিছু patch করা হয় না।

• পরিবর্তিত data structure। upstream fix কোনো struct-এ field যোগ করলে বা বিদ্যমান field-এর অর্থ বদলালে ইতিমধ্যে বরাদ্দ করা ও ব্যবহৃত object নিরাপদে পুনর্লিখনের কোনো উপায় থাকে না। kpatch project একই বিষয় সরাসরি বলেছে: "যে patch-গুলো statically allocated data পরিবর্তন করে, সেগুলো সরাসরি সমর্থিত নয়।" Shadow variable এবং callback workaround হিসেবে ব্যবহার করা যায়, তবে এগুলো প্রতিটি patch-এর জন্য হাতে লিখতে হয়; স্বয়ংক্রিয়ভাবে তৈরি হয় না।
• একসঙ্গে একাধিক function-এ ছড়িয়ে থাকা fix। একদল function-এর মধ্যে lock ordering পরিবর্তন করতে হলে সব function একসঙ্গে পরিবর্তন করতে হয়। Consistency model পুরো machine এক মুহূর্তে freeze না করে task পরিবর্তন করে।
• Initialisation code। __init দিয়ে চিহ্নিত function-গুলো server চালু হওয়ার আগেই একবার চলে এবং memory থেকে মুক্ত হয়ে যায়। তাই redirect করার মতো কিছু অবশিষ্ট থাকে না।
• নতুন kernel version এবং নতুন feature। Live patching একটি kernel series-এর ভেতরে patch level পরিবর্তন করে। এটি কখনও একটি series থেকে পরবর্তী series-এ নিয়ে যায় না এবং কোনো feature যোগ করে না। নতুন series-এর কোনো feature, যেমন Linux 7.1-এ যুক্ত হওয়া পরিবর্তনগুলো, দরকার হলে সেই kernel install করে সেটি boot করতে হবে।
• Userspace। Canonical সীমাটি স্পষ্টভাবে বলেছে: "Canonical Livepatch OpenSSL বা glibc-এর মতো userspace library patch করে না, কারণ এটি unattended-upgrades বা কোনো systems management tool-এর দায়িত্ব।" পুরোনো OpenSSL-এর পাশে live patched kernel থাকলেই server patched হয় না। তাই একই machine-এ userspace package পরিচালনার দায়িত্ব unattended upgrades-এর ওপর রাখুন।

Ubuntu-এর service-এ severity-রও একটি সীমা আছে। Canonical বলেছে, এটি "critical এবং high Common Vulnerability Scoring System (CVSS) এবং Ubuntu Priority rating-যুক্ত kernel vulnerability patch করে।" CVE (common vulnerabilities and exposures) identifier একটি flaw শনাক্ত করে, আর CVSS হলো সেই flaw-এর সঙ্গে যুক্ত score। Medium-rated kernel CVE disk-এ থাকা package-এ fix করা হয়, live patch করা হয় না। তাই এটি পরবর্তী reboot-এ running kernel-এ প্রয়োগ হবে, তার আগে নয়।

লাইভ kernel patching-এর বিকল্প কী?

সাধারণভাবে তিনটি lineage ব্যবহার করা হয়, এবং সবগুলো একই kernel machinery ব্যবহার করে।

Canonical Livepatch Ubuntu Pro-এর মাধ্যমে সরবরাহ করা হয়। ব্যক্তিগত ব্যবহারের জন্য Ubuntu Pro বিনামূল্যে। Canonical-এর ভাষ্য অনুযায়ী, এটি “সর্বদা ব্যক্তিগত ব্যবহারের জন্য সর্বোচ্চ 5টি physical machine-এ বিনামূল্যে থাকবে”; official Ubuntu Community সদস্যদের জন্য সীমা 50টি machine। August 2026 অনুযায়ী এটিই নথিভুক্ত সীমা। Commercial use-এর জন্য paid subscription প্রয়োজন। Coverage প্রতিটি kernel series ও flavour অনুযায়ী দেওয়া হয়। এতে supported long term support (LTS) release-এর general availability (GA) kernel এবং তাদের hardware enablement (HWE) kernel অন্তর্ভুক্ত থাকে। generic, aws, azure, gcp, oracle, ibm এবং lowlatency-এর মতো flavour-গুলোও এর আওতায় পড়ে। এর ওপর নির্ভর করার আগে Canonical-এর প্রকাশিত kernel list-এর সঙ্গে আপনার kernel মিলিয়ে দেখুন।

KernelCare, TuxCare-এর তৈরি একটি commercial agent। এটি first-party service না থাকা distribution-সহ বহু distribution সমর্থন করে। এর নথিভুক্ত installation পদ্ধতিতে vendor script, curl -s -L https://kernelcare.com/installer | bash, চালাতে হয়। এরপর key-based licence-এর জন্য /usr/bin/kcarectl --register KEY চালাতে হয়। Agent নিজস্ব schedule অনুযায়ী নতুন patch পরীক্ষা করে। /usr/bin/kcarectl --update চালালে তাৎক্ষণিকভাবে পরীক্ষা বাধ্যতামূলক হয়। গুরুত্বপূর্ণ server-এ script-টি 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 এবং এর rebuild-গুলোর ক্ষেত্রে patch হাতে তৈরি না করে distribution-এর নিজস্ব service ব্যবহার করুন।

আপনার distribution কী সমর্থন করে এবং আপনার licence কী অনুমতি দেয়, তার ভিত্তিতে নির্বাচন করুন। প্রতিটি ক্ষেত্রে kernel-level ফলাফল একই।

Ubuntu-তে Canonical Livepatch কীভাবে চালু করবেন

প্রথমে আপনার Ubuntu Pro account page থেকে একটি token নিন। নিচের দুটি command চালানোর জন্য কার্যকর outbound network access প্রয়োজন, কারণ client সংযুক্ত হতে এবং patch সংগ্রহ করতে Canonical-এর server-এ যোগাযোগ করে।

sudo pro attach TOKEN
sudo pro status

token ছাড়া sudo pro attach চালালে এর পরিবর্তে browser-ভিত্তিক একটি প্রক্রিয়া শুরু হয় এবং Canonical-এর site-এ প্রবেশ করানোর জন্য একটি code দেখায়। সংযুক্ত করার সময় সুপারিশকৃত service-গুলো স্বয়ংক্রিয়ভাবে চালু হয়। বর্তমান LTS release-এ এর মধ্যে Livepatch-ও থাকে। আপনি নিজে service বেছে নিতে চাইলে sudo pro attach --no-auto-enable ব্যবহার করুন।

Livepatch ইতিমধ্যে চালু না থাকলে:

sudo pro enable livepatch
sudo canonical-livepatch status

service-টি canonical-livepatch snap থেকে চলে। তাই enable প্রক্রিয়া শেষ করতে snapd সচল থাকতে হবে। pro status entitlement এবং status-সহ service-গুলোর একটি table দেখায়। 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

দুটি line-এ প্রয়োজনীয় তথ্য থাকে। আপনি যে series চালাচ্ছেন, সেটি service দ্বারা আদৌ সমর্থিত কি না kernel state তা জানায়। Livepatch সমর্থন করে না এমন kernel দিয়ে boot করলে এই line-টির status খারাপ দেখায়। ওই kernel-এর জন্য প্রযোজ্য patch সত্যিই load হয়েছে কি না patch state তা জানায়। সমর্থিত kernel-এ কোনো patch প্রয়োগ না হলে সমস্যা client-এ। kernel সমর্থিত না হলে সমস্যা kernel-এ, এবং কোনো client setting তা ঠিক করতে পারে না।

কীভাবে বুঝব যে reboot করা দরকার?

Live patching জরুরি পরিস্থিতি দূর করে। তাই reboot করা দরকার কি না, তা আর সবসময় স্পষ্ট থাকে না। আপনাকে নিজেই এটি পরীক্ষা করতে হবে।

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

কোনো installed package কার্যকর করতে restart প্রয়োজন হলে package manager /var/run/reboot-required তৈরি করে। নতুন linux-image package ইনস্টল হলেও এটি তৈরি হয়। কোন package-গুলো restart চেয়েছে, তা .pkgs file-এ তালিকাভুক্ত থাকে। প্রথম command-এর ফলাফল যদি No such file or directory হয়, তাহলে মেশিনটি সর্বশেষ boot হওয়ার পর কোনো package reboot চায়নি। বর্তমান Ubuntu-তে /var/run হলো /run-এর একটি symlink। তাই যেকোনো path ব্যবহার করলেই একই file পাওয়া যায়।

এই flag একটি tmpfs-এ থাকে এবং প্রতিটি boot-এর সময় reset হয়। তাই kernel নিজে পরীক্ষা করে ফলাফল নিশ্চিত করুন:

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

uname -r আপনি যে kernel চালাচ্ছেন, সেটি দেখায়। দ্বিতীয় command disk-এ ইনস্টল করা kernel package-গুলো দেখায়। ওই তালিকায় uname -r যে kernel version দেখায়, তার চেয়ে নতুন কোনো linux-image থাকলে মেশিনটি পুরোনো kernel চালাচ্ছে, Livepatch-এর status যা-ই হোক না কেন। এই পরীক্ষাটিই গুরুত্বপূর্ণ। কারণ live patching চলমান kernel-কে নিরাপদ রাখার জন্য তৈরি, সেটিকে সর্বশেষ version-এ উন্নীত করার জন্য নয়।

একই প্রশ্নের userspace অংশের জন্য needrestart Ubuntu Server-এ default হিসেবে ইনস্টল থাকে। এটি এমন running service-গুলোর তালিকা দেয়, যেগুলো এখনও মুছে ফেলা library file ধরে রেখেছে।

sudo needrestart -r l

-r l flag pair-এর অর্থ হলো “শুধু তালিকা দেখান”। তাই এটি কোনো পরিবর্তন করে না।

রিবুটের প্রয়োজন কেন কখনো পুরোপুরি দূর হয় না

ডিস্কে থাকা kernel অপরিবর্তিত থাকে। Livepatch চলমান kernel-এ patch লোড করে, কিন্তু সেগুলো কখনো boot image-এ লেখা হয় না। তাই reboot করলে bootloader যে linux-image নির্বাচন করে, সেখান থেকেই সিস্টেম চালু হয়। এরপর Livepatch client এখনো প্রযোজ্য patch-গুলো আবার প্রয়োগ করে। এই দুই মুহূর্তের মাঝখানে সিস্টেম unpatched code চালায়। তাই পুরোনো kernel-এর পরিবর্তে বর্তমান kernel দিয়ে boot করাও গুরুত্বপূর্ণ।

Coverage প্রতিটি kernel series অনুযায়ী নির্ধারিত হয়, এবং series অবসরপ্রাপ্ত হয়। আপনার চলমান series সমর্থিত তালিকা থেকে বাদ পড়লে kernel state line আর coverage দেখায় না। তখন একমাত্র সমাধান হলো নতুন kernel ব্যবহার করা। এর জন্য reboot করতে হবে।

Medium এবং low severity-এর kernel fix কখনো live patch করা হয় না। সেগুলো ডিস্কে থাকা package-এ থাকে এবং আপনি boot করার পরই সেগুলো কার্যকর হয়।

দীর্ঘ সময় চলা kernel-এ এমন state-ও জমে, যা patching পরিষ্কার করে না। Canonical-এর নিজস্ব অবস্থান এখানে উল্লেখ করা প্রাসঙ্গিক, কারণ এটি বাস্তব বিষয়টি স্পষ্টভাবে বলে: Livepatch “reboot করার বিকল্প নয়। এটি unscheduled reboot প্রতিরোধ করে আপনাকে আরও নিয়ন্ত্রণ দেওয়ার একটি tool।” এখানে মূল অর্থ বহনকারী শব্দটি হলো unscheduled। আপনাকে তবুও reboot করতে হবে। শুধু কখন করবেন, তা আপনি ঠিক করবেন।

পুনরায় চালুর সময় নির্ধারণ করে কীভাবে সার্ভারকে আবার চালু করবেন

Console-এ পৌঁছাতে না পারলে VPS reboot একমুখী প্রক্রিয়া হয়ে যায়। reboot টাইপ করার আগে নিশ্চিত করুন যে মেশিনটি ফিরে না এলে আপনি আবার কীভাবে প্রবেশ করবেন।

• আপনার provider control panel-এ serial console বা VNC (virtual network computing) view দেয় কি না নিশ্চিত করুন। outage শুরু হওয়ার পরে নয়, এখনই সেটি খুলে রাখুন।
• df -h /boot দিয়ে খালি space পরীক্ষা করুন। /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 নির্ধারণ করে এবং logged-in user-দের একটি message পাঠায়। sudo shutdown -c এটি বাতিল করে। মেশিন ফিরে এলে উভয় দিক যাচাই করুন:

uname -r
sudo canonical-livepatch status

uname -r-এ এখন নতুন kernel দেখানো উচিত। status output-এও নতুন series covered হিসেবে দেখানো উচিত। মেশিন একেবারেই ফিরে না এলে সমস্যা প্রায় সব সময় network-এর পরিবর্তে boot path-এ থাকে। সে ক্ষেত্রে recovery পদ্ধতিটি হলো kernel update-এর পরে boot না হওয়া VPS-সংক্রান্ত guide।

পুরোনো kernel এখনও কেন পরিষ্কার করতে হয়

Live patching এই সমস্যার সমাধান না করে বরং বাড়ায়, কারণ linux-image package ইনস্টল হতে থাকলেও reboot করার জরুরি প্রয়োজন থাকে না। প্রতিটি kernel একটি boot image, একটি initramfs, একটি modules tree এবং সাধারণত একটি headers package ইনস্টল করে। কয়েকশ megabyte-এর আলাদা /boot partition-সহ ছোট VPS-এ তিন বা চারটি kernel-ই সেটি পূর্ণ করে ফেলে।

/boot পূর্ণ হয়ে গেলে পরবর্তী kernel install ব্যর্থ হয়। ফলে মেশিনটি প্রয়োজনীয় update-টিও নিতে পারে না। apt autoremove path পুরোনো kernel eligible হলে সেগুলো সরিয়ে দেয়। কিন্তু যে মেশিন কখনও reboot হয় না, সেখানে পুরোনো kernel সব সময় eligible হয় না। কারণ package manager মনে করে, আপনি এখনও যে kernel ব্যবহার করছেন সেটি সরানো উচিত নয়।

তাই ইনস্টল করা kernel-গুলো পরীক্ষা করুন। বর্তমানে চলমান kernel এবং একটি যাচাই করা fallback kernel রাখুন। বাকি kernel-গুলো Ubuntu-তে পুরোনো kernel নিরাপদে সরানোর পদ্ধতি অনুসরণ করে সরান। uname -r বর্তমানে যে kernel দেখাচ্ছে, সেটি কখনও সরাবেন না।

FAQ

লাইভ kernel patching করলে কি আমার VPS আর কখনও reboot করতে হবে না?

না। Live patch চলমান kernel-এ লোড হয়, কিন্তু boot image-এ লেখা হয় না। তাই disk-এর linux-image আপনি যে version boot করেছিলেন, সেই version-এই থাকে। Canonical বিষয়টি সরাসরি জানায়: Livepatch “reboot-এর বিকল্প নয়। অনির্ধারিত reboot ঠেকিয়ে এটি আপনাকে আরও নিয়ন্ত্রণ দেয়।” আপনার kernel series অবসরপ্রাপ্ত হলে coverage-ও শেষ হয়। এছাড়া medium severity-এর kernel fix কখনও live patch করা হয় না। কোনো reboot বাধ্যতামূলক হওয়ার অপেক্ষা না করে, আপনার নির্ধারিত cadence অনুযায়ী maintenance reboot schedule করুন।

লাইভ kernel patching সত্যিই patch প্রয়োগ করছে কি না কীভাবে পরীক্ষা করব?

sudo canonical-livepatch status চালিয়ে দুটি line পড়ুন। kernel state জানায়, আপনার চলমান kernel series service-এর আওতায় আছে কি না। patch state জানায়, ওই kernel-এর patch-গুলো লোড হয়েছে কি না। ls /sys/kernel/livepatch/ ব্যবহার করে kernel-এর দিক থেকেও সরাসরি পরীক্ষা করতে পারেন। এটি লোড হওয়া প্রতিটি patch-এর জন্য একটি করে directory দেখায়। Listing খালি হলে client ভিন্ন কিছু জানালেও, এই মুহূর্তে memory-তে কোনো patch প্রয়োগ করা নেই।

ব্যক্তিগত VPS-এ Ubuntu Pro কি বিনামূল্যে?

হ্যাঁ, নির্ধারিত সীমার মধ্যে। Canonical-এর ভাষ্য অনুযায়ী, Ubuntu Pro “ব্যক্তিগত ব্যবহারের জন্য সর্বদা বিনামূল্যে থাকবে, সর্বোচ্চ 5টি physical machine পর্যন্ত”। August 2026 অনুযায়ী, official Ubuntu Community member-দের জন্য সীমাটি 50টি machine। 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 rating-যুক্ত kernel vulnerability” live patch করে। বাকি fix disk-এ থাকা package-এর ওপর ছেড়ে দেয়। অথবা fix-টি function body পরিবর্তনের মাধ্যমে নিরাপদে প্রয়োগ করা সম্ভব নাও হতে পারে। যেমন upstream কোনো data structure পরিবর্তন করলে এমনটি হতে পারে। ইতিমধ্যে allocate করা object-এর ওপর live patching এভাবে নিরাপদে কাজ করতে পারে না। দুই ক্ষেত্রেই সমাধান একই: updated kernel package install করুন এবং সেটিতে boot করুন।

লাইভ kernel patching একেবারেই কী cover করে না?

Userspace। Canonical স্পষ্টভাবে জানায়, Livepatch “OpenSSL বা glibc-এর মতো userspace library patch করে না, কারণ এটি unattended-upgrades বা systems management tool-এর দায়িত্ব।” এটি নতুন kernel version বা নতুন feature-ও দিতে পারে না। কারণ আপনি যে series ইতিমধ্যে চালাচ্ছেন, তার ভেতরে শুধু function body প্রতিস্থাপন করে। এছাড়া __init function-ও patch করতে পারে না। Server চালু হওয়ার সময়ের মধ্যে ওই function-গুলো ইতিমধ্যে run হয়ে memory থেকে মুক্ত হয়ে যায়।