Linux kernel 7.1: सर्वर के लिए मुख्य बदलाव और जानकारी

Linux kernel 7.1 में नया क्या है

Linux kernel 7.1 को 14 June 2026 को, 7.0 के नौ सप्ताह बाद release किया गया था। एक VPS (virtual private server) tenant के लिए, महत्वपूर्ण बदलाव चार क्षेत्रों में हैं: storage और filesystems, networking, memory management, और process तथा container control। इस release का बाकी हिस्सा मुख्य रूप से desktop और graphics से संबंधित कार्य है, जिसे headless server कभी load नहीं करता।

आपको सबसे पहले एक और उत्तर की आवश्यकता है। 7.1 लगभग निश्चित रूप से आपके सर्वर पर नहीं चल रहा है, और यह लंबे समय तक नहीं चलेगा। kernel.org 7.1 को longterm release के रूप में सूचीबद्ध नहीं करता है। 11 August 2026 तक, longterm lines 6.18, 6.12, 6.6, 6.1, 5.15 और 5.10 हैं, और प्रत्येक mainstream server distribution इनमें से किसी एक पर या स्वयं द्वारा maintain की जाने वाली line पर आधारित होती है। "Kernel में नया" और "आपके सर्वर पर नया" के बीच वर्षों का अंतर होता है, इसलिए यह मार्गदर्शिका दोनों पहलुओं को कवर करती है।

आपका VPS अभी कौन सा kernel चला रहा है

uname -r
uname -srm
systemd-detect-virt

uname -r वर्तमान में चल रहे kernel release को print करता है। Ubuntu 24.04 पर यह 6.8.0-79-generic जैसा दिखता है। पहले डैश के पहले का हिस्सा upstream line है। उसके बाद का सब कुछ आपके distribution का अपना build number है, और यह upstream को बिल्कुल भी track नहीं करता है। Canonical का 6.8.0-79 बाद के kernels से backport किए गए हजारों fixes को साथ लेकर चलता है, इसलिए यह वह code नहीं है जिसे Linus ने मार्च 2024 में 6.8 के रूप में tag किया था। यही कारण है कि "मेरा kernel पुराना है" कहने का अर्थ जितना सुनाई देता है, उससे कहीं कम होता है। features पुराने हो सकते हैं, लेकिन security fixes आमतौर पर पुराने नहीं होते।

systemd-detect-virt आपको बताता है कि क्या आप kernel को बदल भी सकते हैं या नहीं। यह एक full virtual machine पर kvm print करता है, जहाँ आप अपना खुद का kernel image boot करते हैं और एक upgrade वास्तव में एक upgrade होता है। यह container virtualisation पर lxc या openvz print करता है, जहाँ host kernel साझा (shared) होता है। एक container plan पर uname -r provider का kernel दिखाता है, kernel package install करने से आप कुछ भी boot नहीं कर पाएंगे, और इस release का कोई भी feature तब तक आपके लिए उपलब्ध नहीं होगा जब तक provider host को नए kernel पर reboot नहीं करता। kernel से संबंधित कोई भी काम करने से पहले इस जाँच को चलाएं।

[
  {
    "distro": "Ubuntu 26.04 LTS (7.0)",
    "releases_behind_7_1": 1,
    "notes": "GA kernel, shipped with the April 2026 release"
  },
  {
    "distro": "Ubuntu 24.04 LTS, HWE (6.17)",
    "releases_behind_7_1": 4,
    "notes": "6.17 came with 24.04.4; 7.0 is rolling out ahead of 24.04.5 on 27 August 2026"
  },
  {
    "distro": "Debian 13 trixie (6.12)",
    "releases_behind_7_1": 9,
    "notes": "upstream longterm line, kernel.org projected EOL December 2028"
  },
  {
    "distro": "RHEL 10 and its rebuilds (6.12)",
    "releases_behind_7_1": 9,
    "notes": "Red Hat backports fixes into its own frozen 6.12 stream"
  },
  {
    "distro": "Ubuntu 24.04 LTS, GA (6.8)",
    "releases_behind_7_1": 13,
    "notes": "the default unless you install the HWE stack"
  },
  {
    "distro": "Ubuntu 22.04 LTS, GA (5.15)",
    "releases_behind_7_1": 26,
    "notes": "upstream longterm line, kernel.org projected EOL December 2026"
  }
]

यह 6 platforms हैं, और उनमें से कोई भी 7.1 boot नहीं करता है। सबसे नया Ubuntu 26.04 LTS (7.0) है, जो upstream release से 1 पीछे है। support में सबसे पुराना 26 releases पीछे है। Ubuntu 24.04 का default GA kernel 13 releases पीछे है, और Debian 13 तथा RHEL 10, 6.12 longterm line पर 9 पीछे हैं। releases की गिनती करना एक मोटा पैमाना है, क्योंकि यह उन सभी चीजों को अनदेखा कर देता है जिन्हें distributions backport करते हैं, लेकिन यह अंतर के स्वरूप को दर्शाता है। यदि आप यह तौल रहे हैं कि इनमें से किसे चलाना है, तो सर्वर पर LTS बनाम interim release का trade-off इन संख्याओं के पीछे का मुख्य निर्णय है।

7.1 में स्टोरेज और फाइलसिस्टम

7.1 संस्करण ब्लॉक लेयर के बजाय सीधे फाइलसिस्टम के भीतर T10 PI (प्रोटेक्शन इंफॉर्मेशन) को जनरेट और सत्यापित करने की क्षमता जोड़ता है, साथ ही इसमें लचीला T10 अलाइनमेंट सपोर्ट भी शामिल है। T10 PI प्रत्येक ब्लॉक के साथ जुड़े अतिरिक्त बाइट्स होते हैं, जिनमें एक चेकसम और एक टैग होता है जो यह पहचानता है कि डेटा किस ब्लॉक का है। इससे गलत दिशा में लिखे गए या अधूरे (torn) राइट्स को पकड़ लिया जाता है, बजाय इसके कि उन्हें सही डेटा के रूप में वापस दिया जाए। VPS टेनेंट के लिए समस्या हार्डवेयर की है। इंटीग्रिटी मेटाडेटा को डिवाइस द्वारा एक्सपोज़ किया जाना चाहिए, और एक वर्चुअल डिस्क सामान्यतः इसे एक्सपोज़ नहीं करती है।

ls /sys/block/vda/integrity/

अधिकांश VPS डिस्क पर यह No such file or directory रिटर्न करता है, क्योंकि ब्लॉक लेयर integrity डायरेक्टरी तभी बनाती है जब डिवाइस इंटीग्रिटी सपोर्ट को रजिस्टर करता है। वह एरर यहाँ सामान्य उत्तर है, कोई खराबी नहीं। यदि आप स्टोरेज फीचर्स के बारे में और पढ़ने से पहले यह जानना चाहते हैं कि आपकी डिस्क वास्तव में क्या है, तो VPS डिस्क वास्तव में NVMe है या नहीं, यह जांचना सबसे पहले आता है, और VPS पर NVMe और SATA SSD के बीच का अंतर बताता है कि उत्तर आपके नंबर्स को क्यों बदल देता है।

Btrfs को मेमोरी दबाव के तहत कॉपी-ऑन-राइट एम्प्लीफिकेशन के लिए फिक्स मिले हैं, साथ ही एक बदलाव जो ट्रैक की गई रेंज में पहले एक्सटेंट को क्लियर करने की गति बढ़ाता है, जिसे मर्ज में बताए गए सैंपल वर्कलोड पर 10% अधिक थ्रूपुट के रूप में रिपोर्ट किया गया है। इसका शटडाउन ऑपरेशन अब एक्सपेरिमेंटल के रूप में चिह्नित नहीं है। XFS iomap के माध्यम से ज़ीरो रेंज फ्लशिंग और लुकअप में सुधार करता है, और रियल-टाइम ग्रुप ज्योमेट्री में एक राइट पॉइंटर जोड़ता है, जो ज़ोन किए गए डिवाइस के लिए आधार तैयार करता है। इस रिलीज़ में NTFS को पूरी तरह से फिर से लिखा गया है, जिसमें पूर्ण राइट सपोर्ट और iomap कन्वर्जन शामिल है, जो तब महत्वपूर्ण होता है जब आप अपने सर्वर पर Windows मशीन से डिस्क इमेज माउंट करते हैं।

स्टोरेज से संबंधित अन्य छोटी बातें जो जानने योग्य हैं: ublk, जो यूजर-स्पेस ब्लॉक ड्राइवर है, में ज़ीरो-कॉपी I/O जोड़ा गया है; io_uring में SCSI पासथ्रू कमांड्स जोड़े गए हैं; SED-OPAL सेल्फ-एनक्रिप्टिंग ड्राइव सपोर्ट में STACK_RESET कमांड और विस्तारित सिंगल यूजर मोड जोड़ा गया है; डायरेक्ट-एक्सेस डिवाइस के लिए एक नया fs-dax कैरेक्टर ड्राइवर है; और VFS ने inode->i_ino को unsigned long से बढ़ाकर u64 कर दिया है, जो 32-बिट बिल्ड्स पर इनोड नंबर की सीमा को हटा देता है। नेटवर्क फाइलसिस्टम की तरफ, इन-कर्नेल NFS सर्वर अब sign_fh माउंट विकल्प के माध्यम से अपने फाइल हैंडल को साइन कर सकता है, और CIFS क्लाइंट ने O_TMPFILE सीख लिया है।

नेटवर्किंग: queue leasing, और यह एक container को क्या प्रदान करता है

नेटवर्किंग में मुख्य बदलाव hardware queue leasing है। एक virtual netdev अब एक ऐसी queue को lease पर ले सकता है जो physical netdev की वास्तविक queue से जुड़ी हो, और उसके लिए proxy के रूप में कार्य कर सकता है। इसका उद्देश्य containers हैं। अब तक, जिस container को AF_XDP (address family express data path, वह socket type जो raw packets को network stack के माध्यम से copy किए बिना सीधे user space तक पहुँचाता है) की आवश्यकता होती थी, उसे पूरे device का एक्सेस देना पड़ता था। leased queue के साथ, इसे एक hardware queue मिलती है, जो native speed पर AF_XDP और memory providers को चलाती है, जबकि host के पास NIC का शेष हिस्सा सुरक्षित रहता है। यह io_uring के zero-copy path में AF_XDP support के साथ आता है।

सामान्य पक्ष पर, sockfs में sockets अब user.* extended attributes स्वीकार करते हैं। एक path-based AF_UNIX socket पहले से ही अपने नीचे मौजूद filesystem से xattr support प्राप्त करता था, लेकिन केवल sockfs में रहने वाले socket के पास ऐसा कोई support नहीं था। अब एक process किसी socket को label कर सकती है, और एक eBPF program उस label के आधार पर filtering कर सकता है।

दो चीजें हटा दी गई हैं। UDP-Lite को हटा दिया गया है, क्योंकि इसके कोई users नहीं मिले। IPv6 को अब loadable module के रूप में build नहीं किया जा सकता: यदि आपको IPv6 चाहिए, तो इसे kernel में ही compile करना होगा। दूसरा बदलाव किसी भी distribution kernel पर दिखाई नहीं देता है, क्योंकि सामान्य server distributions पहले से ही IPv6 को build-in रखते हैं।

Memory management: swap table पूर्ण हो गया है

Swap rework अपने तीसरे चरण में पहुँच गया है, और यह चरण static swap map को हटा देता है। Swap count अब सीधे swap table में रहता है। रिपोर्ट की गई बचत static swap metadata का लगभग 30% है। यह वह memory है जिसे kernel आपके swap device के आकार के अनुपात में रखता है, चाहे उसमें कुछ भी swap किया गया हो या न हो। पूर्ण शब्दों में, यह एक छोटी swap file पर कम होता है, और आपके द्वारा configure किए गए swap के साथ बढ़ता है।

MGLRU (multi-generational least recently used, नया page reclaim algorithm) अब एक बार में एक page के बजाय batches में pages पर young flag की जाँच कर सकता है। इस बदलाव के साथ प्रकाशित आँकड़ा Arm64 32-core सर्वर पर 60% से अधिक का सुधार दर्शाता है। Batching का लाभ वहाँ सबसे अधिक मिलता है जहाँ प्रति-page लागत सबसे अधिक होती है, यही कारण है कि यह संख्या एक बड़े Arm machine से आई है। यदि आप x86 के बजाय एक Arm VPS चलाते हैं, तो यह 7.1 का वह बदलाव है जो आपके अपने मापन में सबसे अधिक दिखाई देने की संभावना है, हालाँकि दो या चार cores पर यह उस पैमाने पर नहीं होगा।

यहाँ यह भी शामिल है: dying memory cgroups से transfers हटा दिए गए हैं, khugepaged अब कम CPU के साथ scan करता है, और maple tree को उसके बड़े node handling के आसपास एक बड़ा refactor मिला है। इनमें से कोई भी ऐसी चीज़ नहीं है जिसे आप configure करते हैं। ये वे चीज़ें हैं जिन्हें आप थोड़े कम system time के रूप में महसूस करते हैं।

Schedulers: sched_ext sub-schedulers, और FRED डिफ़ॉल्ट रूप से सक्षम

sched_ext, जो एक extensible scheduler class है, आपको BPF प्रोग्राम के रूप में CPU scheduler लिखने और उसे runtime पर लोड करने की सुविधा देता है। यह 6.12 में आया था। 7.1 में sub-schedulers के लिए मुख्य संरचना जोड़ी गई है, ताकि भविष्य में एक control group अपने स्वयं के scheduler के अंतर्गत चल सके। इस वाक्य को ध्यान से पढ़ें। 7.1 में इसका कार्यान्वयन अभी पूरा नहीं हुआ है, विशेष रूप से enqueue path अभी मौजूद नहीं है, इसलिए यह भविष्य के release के लिए आधार तैयार करने जैसा है, न कि ऐसी चीज़ जिसे आप आज ही चालू कर सकें।

Intel FRED (flexible return and event delivery) अब उन हार्डवेयर पर डिफ़ॉल्ट रूप से सक्षम है जो इसका समर्थन करते हैं। FRED पुराने x86 event delivery path को एक अधिक व्यवस्थित path से बदल देता है, और यह 6.9 के बाद से kernel में fred=on बूट तर्क के पीछे मौजूद था। इसे डिफ़ॉल्ट रूप से चालू करने का अर्थ यह है कि shipping हार्डवेयर का पर्याप्त परीक्षण किया जा चुका है। अब तक प्रकाशित आंकड़े, जो I/O heavy workloads पर 4% से 7% के दायरे में हैं, client silicon पर Phoronix परीक्षण से आए हैं। इसलिए, जब तक आप अपने स्वयं के workload का मापन न कर लें, तब तक सर्वर पर इसके लाभ की उम्मीद न करें।

Proxy execution में remote lock owner को बढ़ावा देने के लिए donor migration की सुविधा जोड़ी गई है, EEVDF में negative lag से संबंधित सुधार किए गए हैं, और high-resolution timer core को काफी हद तक फिर से लिखा गया है। ये latency-quality में सुधार करने वाले बदलाव हैं जिन्हें कोई भी configuration file प्रदर्शित नहीं करती है।

clone3() में नई प्रक्रिया और कंटेनर नियंत्रण

clone3() में तीन flags जोड़े गए हैं, और प्रत्येक एक ऐसी कमी को दूर करता है जिसे supervisors वर्षों से मैन्युअल रूप से हल कर रहे थे। CLONE_AUTOREAP child process को exit होने पर खुद को reap करने के लिए मजबूर करता है, ताकि वह कभी भी zombie न बने और उस parent का इंतज़ार न करे जो शायद कभी wait() कॉल न करे। CLONE_NNP creation के समय ही child पर no_new_privs सेट कर देता है, जो clone और child द्वारा खुद flag सेट करने के बीच के समय के अंतराल (window) को समाप्त करता है। CLONE_PIDFD_AUTOKILL child के जीवनकाल को parent को लौटाए गए pidfd से जोड़ देता है: pidfd बंद होते ही child kill हो जाता है, ताकि यदि supervisor की मृत्यु हो जाए तो वह पीछे अनाथ (orphans) न छोड़े।

Mount namespaces के साथ भी ऐसा ही किया गया है। clone3() के लिए CLONE_EMPTY_MNTNS और unshare() के लिए UNSHARE_EMPTY_MNTNS एक खाली mount namespace बनाते हैं, न कि parent के mounts की वह पूरी कॉपी जिसे runtime को बाद में unmount करना पड़ता था। FSMOUNT_NAMESPACE, fsmount() को सीधे एक नई namespace में filesystem रखने की अनुमति देता है। Container runtimes एक दशक से इसे मैन्युअल रूप से जोड़ रहे थे, इसलिए अब एक ही कॉल में ऐसा करने का अर्थ है कि runtime को अब host के mounts से भरी namespace से शुरुआत नहीं करनी पड़ती।

Virtualisation के पक्ष में, guest_memfd अब userfaultfd का समर्थन करता है, ताकि hypervisor user space से guest page faults को संभाल सके। Arm पर Protected KVM को anonymous memory support प्राप्त हुआ है, जिसे merge के विवरण में ही production ready नहीं बताया गया है।

Kernel 7.1 आपके सर्वर पर कब आता है

Fedora में यह पहले से मौजूद है। Fedora 44 update repository जुलाई और अगस्त 2026 के दौरान 7.1 series पर स्थानांतरित हो गई, क्योंकि Fedora अपने kernel को एक release के भीतर नई stable lines पर rebase करता है। Arch और openSUSE Tumbleweed में भी यही कारण है। ये मशीनें परीक्षण के लिए हैं, न कि उन पर अपनी services चलाने के लिए।

बाकी सब इंतज़ार करते हैं, और यह इंतज़ार design के अनुसार ही है। Debian 13, 6.12 के साथ ship हुआ था और release के पूरे जीवनकाल तक 6.12 पर ही रहता है, जिसमें fixes को backport किया जाता है। RHEL 10, 6.12.0 के साथ ship हुआ और वही प्रक्रिया अपनाता है। Ubuntu 26.04 LTS अप्रैल 2026 में 7.0 के साथ ship हुआ। Ubuntu 24.04 LTS में एक hardware enablement stack है, जो बाद के Ubuntu releases से एक नया kernel LTS में लाता है। 24.04.4 point release के अनुसार वह stack 6.17 पर है, और 27 अगस्त 2026 को 24.04.5 के साथ 7.0 पर जाने के लिए निर्धारित है।

यहाँ वह हिस्सा है जिसे लोग गलत समझते हैं। एक HWE stack उस kernel पर jump करता है जिसे नवीनतम interim release ले जाती है, इसलिए यह एक upstream line को पूरी तरह से छोड़ सकता है। 7.0 एक Ubuntu LTS में है। 7.1 शायद कभी भी किसी का आधार न बने, क्योंकि इसके बाद आने वाली interim release एक बाद की line को ले जाएगी। 7.1 से आपके LTS तक जो पहुँचता है, वह fixes हैं, जिन्हें उस line में backport किया जाता है जिस पर आप हैं। features अधिकतर पीछे ही रह जाते हैं।

यदि आप वास्तव में एक stable सर्वर पर नया kernel चाहते हैं, तो समर्थित रास्ते सीमित हैं।

# Ubuntu 24.04 LTS: install the hardware enablement stack
sudo apt update
sudo apt install --install-recommends linux-generic-hwe-24.04
sudo reboot

# Debian 13, with trixie-backports enabled in your apt sources
apt-cache policy linux-image-amd64
sudo apt install -t trixie-backports linux-image-amd64
sudo reboot

Reboot के बाद, जाँचें कि आपने वास्तव में क्या boot किया है:

uname -r
dpkg -l 'linux-image-*' | grep ^ii
ls /var/run/reboot-required

uname -r को अब नई line दिखानी चाहिए, और dpkg -l हर उस kernel image को दिखाता है जो अभी भी installed है। यदि uname -r पुराना version दिखाता है जबकि dpkg -l नए वाले को सूचीबद्ध करता है, तो package install हो गया लेकिन bootloader default नहीं बदला: GRUB menu entries को देखें। /var/run/reboot-required का अस्तित्व यह दर्शाता है कि एक package ने kernel को upgrade किया है और उसके बाद से कोई reboot नहीं हुआ है, जो सबसे आम कारण है कि एक patched सर्वर अभी भी vulnerable code को execute कर रहा है।

क्या आपको production VPS पर 7.1 का उपयोग करना चाहिए

नहीं, और इसका कारण केवल सावधानी बरतना नहीं है। एक distribution kernel वास्तव में एक support contract होता है। Canonical, Red Hat, SUSE और Debian प्रत्येक अपने frozen line में security fixes को backport करते हैं और उन्हें अपने साथ आने वाले userspace के साथ test करते हैं। किसी third-party archive से लिया गया या स्वयं build किया गया mainline kernel आपको नई सुविधाएँ तो देता है, लेकिन यह सुरक्षा संबंधी जिम्मेदारी भी आप पर डाल देता है, क्योंकि आपके build के लिए कोई भी fixes backport नहीं कर रहा होता है। आप स्वयं kernel के maintainer बन जाते हैं।

इसके अपवाद वास्तविक हैं लेकिन बहुत सीमित हैं: ऐसा hardware जिसे पुराना kernel support नहीं करता, या performance में ऐसा बदलाव जिसे आपने अपने workload पर मापा है और जिसके परिणामों की जिम्मेदारी लेने के लिए आप तैयार हैं। VPS पर पहला कारण लगभग कभी लागू नहीं होता, क्योंकि आप जो hardware देखते हैं वह virtual होता है। बाकी सभी चीजों के लिए, distribution kernel को current रखें और जब यह reboot करने के लिए कहे तो reboot करें। यदि distribution upgrade आपकी सूची में है, तो Ubuntu 24.04 से 26.04 पर जाना आपको एक ही चरण में 6.8 से 7.0 पर ले जाता है, जो किसी भी एक kernel package द्वारा दिए जाने वाले बदलाव से कहीं बड़ा jump है।

FAQ

मैं यह कैसे जाँचूँ कि मेरा VPS कौन सा Linux kernel चला रहा है?

uname -r चलाएँ। यह 6.8.0-79-generic जैसा कुछ प्रिंट करेगा। पहले डैश से पहले की संख्या वह upstream line है जिस पर आपका distribution आधारित है, और उसके बाद की हर चीज़ distribution का अपना build number है, जिसमें backported fixes शामिल होते हैं। फिर systemd-detect-virt चलाएँ। यदि यह lxc या openvz प्रिंट करता है, तो आप container virtualisation पर हैं, आप host का kernel साझा कर रहे हैं, और आप इसे बदल नहीं सकते। यदि यह kvm प्रिंट करता है, तो आप अपनी खुद की kernel image boot करते हैं और upgrades की जिम्मेदारी आपकी है।

क्या Linux 7.1 एक longterm support kernel है?

नहीं। 11 August 2026 तक kernel.org पर सूचीबद्ध longterm lines 6.18, 6.6, 6.12, 6.1, 5.15 और 5.10 हैं, और 7.1 इनमें शामिल नहीं है। यह एक सामान्य stable release है, और अगली mainline release के आते ही इसकी stable line को हटा दिया जाता है। यदि आप ऐसा kernel चाहते हैं जिसमें वर्षों के fixes पहले से हों और वर्षों के fixes भविष्य में आने वाले हों, तो वह वही है जो आपके distribution का kernel पहले से ही है।

Ubuntu या Debian kernel 7.1 कब ship करेंगे?

संभवतः डिफ़ॉल्ट रूप से कभी नहीं। Debian 13 अपनी release के पूरे जीवनकाल में 6.12 पर रहता है, और RHEL 10 6.12.0 पर रहता है। Ubuntu 26.04 LTS ने 7.0 ship किया था, और Ubuntu hardware enablement stack उस kernel पर jump करता है जो सबसे नई interim release में होता है, इसलिए यह पूरी तरह से एक upstream line को छोड़ सकता है। Ubuntu 24.04 LTS अपने HWE kernel को 27 August 2026 को 24.04.5 point release के साथ 7.0 पर ले जाने के लिए निर्धारित है। 7.1 के fixes आप तक पुरानी line में backports के रूप में पहुँचेंगे। सुविधाएँ आमतौर पर नहीं पहुँचेंगी।

Linux 7.1 में VPS पर वास्तव में क्या मायने रखता है?

चार चीजें। Hardware queue leasing एक container को native speed पर AF_XDP के लिए एक वास्तविक NIC queue का उपयोग करने देती है। Swap rework का तीसरा चरण static swap map को हटा देता है और आपके swap device के लिए kernel द्वारा रखे गए metadata को 30% तक कम कर देता है। MGLRU page young flags को batches में जाँच सकता है, जिसका सबसे बड़ा लाभ many-core Arm सर्वर पर देखा गया है। और clone3() को CLONE_AUTOREAP, CLONE_NNP और CLONE_PIDFD_AUTOKILL प्राप्त हुए हैं, जो child processes की निगरानी को सुरक्षित बनाते हैं। Filesystem-level T10 protection information भी आ गया है, लेकिन एक virtual disk शायद ही कभी उस integrity metadata को expose करती है जिसकी उसे आवश्यकता होती है।

क्या मेरा kernel upgrade करने से मेरा VPS खराब हो जाएगा?

सामान्य विफलताएँ boot के समय होती हैं। एक पूर्ण /boot install के दौरान update-initramfs को No space left on device के साथ विफल कर देता है, जिससे package आधा configured रह जाता है: पुराने kernels को sudo apt autoremove --purge के साथ साफ़ करें, फिर reinstall करें। पुराने kernel के विरुद्ध बनाए गए out-of-tree modules load होना बंद हो जाते हैं, इसलिए DKMS द्वारा प्रबंधित किसी भी चीज़ को फिर से बनाना (rebuild) पड़ता है, और एक विफल rebuild तब तक silent रहता है जब तक कि runtime पर module गायब न हो जाए। और यदि reboot के बाद भी uname -r पुराना version दिखाता है जबकि dpkg -l नई image को सूचीबद्ध करता है, तो install में कुछ भी खराब नहीं हुआ है: bootloader default नहीं बदला है।