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 को ट्रैक नहीं करता है। Canonical का 6.8.0-79 बाद के kernels से backport किए गए हजारों fixes को शामिल करता है, इसलिए यह वह कोड नहीं है जिसे Linus ने मार्च 2024 में 6.8 के रूप में tag किया था। यही कारण है कि "मेरा kernel पुराना है" कहना सुनने में जितना गंभीर लगता है, वास्तव में उतना नहीं है। फीचर्स पुराने हो सकते हैं, लेकिन security fixes आमतौर पर पुराने नहीं होते।

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

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 है या नहीं, यह जाँचें सबसे पहले आता है, और NVMe और SATA SSD के बीच का अंतर यह बताता है कि उत्तर आपके नंबर्स को क्यों बदल देता है।

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

स्टोरेज से संबंधित अन्य छोटी लेकिन महत्वपूर्ण बातें: ublk, जो एक यूजर-स्पेस ब्लॉक ड्राइवर है, में zero-copy 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 के पास यह सुविधा नहीं थी। अब एक 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% है, जो वह मेमोरी है जिसे 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 मशीन से आई है। यदि आप x86 के बजाय एक Arm VPS चलाते हैं, तो यह 7.1 का वह बदलाव है जो आपके अपने measurements में सबसे अधिक दिखाई देने की संभावना है, हालाँकि दो या चार cores पर यह उस पैमाने पर नहीं होगा।

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

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

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

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

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

clone3() में नई प्रोसेस और कंटेनर कंट्रोल्स

clone3() में तीन फ्लैग्स जोड़े गए हैं, और प्रत्येक फ्लैग उस कमी को दूर करता है जिसे सुपरवाइजर वर्षों से मैन्युअल रूप से हल करते आ रहे थे। CLONE_AUTOREAP चाइल्ड प्रोसेस को एग्जिट होने पर खुद को रीप (reap) करने के लिए बाध्य करता है, ताकि वह कभी भी ज़ोंबी (zombie) न बने और ऐसे पैरेंट का इंतज़ार न करे जो शायद कभी wait() कॉल न करे। CLONE_NNP क्रिएशन के समय ही चाइल्ड पर no_new_privs सेट कर देता है, जो क्लोन होने और चाइल्ड द्वारा खुद के लिए फ्लैग सेट करने के बीच के समय के अंतराल (window) को बंद कर देता है। CLONE_PIDFD_AUTOKILL चाइल्ड के जीवनकाल को पैरेंट को वापस किए गए pidfd से जोड़ देता है: pidfd को क्लोज करते ही चाइल्ड किल हो जाता है, इसलिए यदि कोई सुपरवाइजर क्रैश होता है तो वह अनाथ (orphans) प्रोसेस को पीछे नहीं छोड़ सकता।

माउंट नेमस्पेस (mount namespaces) के लिए भी यही सुधार किए गए हैं। clone3() के लिए CLONE_EMPTY_MNTNS और unshare() के लिए UNSHARE_EMPTY_MNTNS एक खाली माउंट नेमस्पेस बनाते हैं, बजाय इसके कि पैरेंट के माउंट्स की पूरी कॉपी बनाई जाए जिसे बाद में रनटाइम को अनमाउंट करना पड़ता है। FSMOUNT_NAMESPACE, fsmount() को सीधे एक नई नेमस्पेस में फाइलसिस्टम प्लेस करने की अनुमति देता है। कंटेनर रनटाइम्स एक दशक से इसे मैन्युअल रूप से असेंबल कर रहे थे, इसलिए एक ही कॉल में इसे करने का मतलब है कि अब रनटाइम को होस्ट के माउंट्स से भरी नेमस्पेस से शुरुआत नहीं करनी पड़ती।

वर्चुअलाइजेशन की तरफ, guest_memfd अब userfaultfd को सपोर्ट करता है, ताकि हाइपरवाइजर यूजर स्पेस से गेस्ट पेज फॉल्ट्स को हैंडल कर सके। Arm पर प्रोटेक्टेड KVM को एनोनिमस मेमोरी सपोर्ट मिला है, जिसे मर्ज में ही प्रोडक्शन के लिए तैयार न होने के रूप में वर्णित किया गया है।

Kernel 7.1 आपके सर्वर पर कब आएगा

Fedora में यह पहले से उपलब्ध है। Fedora 44 का अपडेट रिपॉजिटरी जुलाई और अगस्त 2026 के दौरान 7.1 सीरीज पर आ गया था, क्योंकि Fedora अपने रिलीज के भीतर ही kernel को नई स्टेबल लाइन्स पर rebase करता है। Arch और openSUSE Tumbleweed में भी यही कारण है। ये मशीनें टेस्टिंग के लिए हैं, न कि अपनी सर्विसेज चलाने के लिए।

बाकी सभी डिस्ट्रोस इंतजार करते हैं, और यह इंतजार जानबूझकर किया जाता है। Debian 13 को 6.12 के साथ रिलीज किया गया था और यह अपने पूरे जीवनकाल में 6.12 पर ही रहेगा, जिसमें केवल fixes को backport किया जाता है। RHEL 10 को 6.12.0 के साथ रिलीज किया गया था और यह भी ऐसा ही करता है। Ubuntu 26.04 LTS को अप्रैल 2026 में 7.0 के साथ रिलीज किया गया था। Ubuntu 24.04 LTS में एक hardware enablement stack है, जो बाद के Ubuntu रिलीज से नया kernel LTS में लाता है। 24.04.4 पॉइंट रिलीज के अनुसार यह stack 6.17 पर है, और 27 अगस्त 2026 को 24.04.5 के साथ इसके 7.0 पर जाने की योजना है। पॉइंट रिलीज Ubuntu का नया वर्जन नहीं होता, बल्कि यह वही 24.04 है जिसमें अब तक के सभी अपडेट्स को फ्रेश इंस्टाल मीडिया में शामिल कर दिया जाता है, इसलिए 24.04.5 आपके पहले से पैच किए गए सर्वर पर क्या बदलता है यह केवल HWE kernel लाइन है और इसके अलावा बहुत कम चीजें बदलती हैं।

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

यदि आप वास्तव में एक स्टेबल सर्वर पर नया 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

रीबूट के बाद, जांचें कि आपने वास्तव में क्या बूट किया है:

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

uname -r को अब नई लाइन दिखानी चाहिए, और dpkg -l उन सभी kernel इमेजेस को दिखाता है जो अभी भी इंस्टाल हैं। यदि uname -r पुराना वर्जन दिखाता है जबकि dpkg -l नया वर्जन लिस्ट करता है, तो पैकेज इंस्टाल हो गया है लेकिन बूटलोडर डिफॉल्ट नहीं बदला है: GRUB मेनू एंट्रीज को देखें। /var/run/reboot-required का मौजूद होने का मतलब है कि एक पैकेज ने kernel को अपग्रेड किया है और उसके बाद से रीबूट नहीं हुआ है, जो कि सबसे आम कारण है कि एक पैच किया गया सर्वर अभी भी असुरक्षित कोड चला रहा है।

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

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

इसके अपवाद वास्तविक हैं लेकिन सीमित हैं: ऐसा hardware जिसे पुराना kernel support नहीं करता, या performance में ऐसा बदलाव जिसे आपने अपने workload पर मापा है और जिसके परिणामों की जिम्मेदारी लेने के लिए आप तैयार हैं। VPS पर पहली स्थिति लगभग कभी लागू नहीं होती, क्योंकि जो hardware आप देखते हैं वह virtual होता है। बाकी सब चीजों के लिए, distribution kernel को current रखें और जब यह कहे तो 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 लाइन है जिस पर आपका distribution आधारित है, और उसके बाद का हिस्सा distribution का अपना build नंबर है, जिसमें backported fixes शामिल होते हैं। इसके बाद systemd-detect-virt चलाएँ। यदि यह lxc या openvz प्रिंट करता है, तो आप container virtualization पर हैं, आप host का kernel साझा कर रहे हैं, और आप इसे बदल नहीं सकते। यदि यह kvm प्रिंट करता है, तो आप अपनी खुद की kernel image boot करते हैं और upgrades करने की जिम्मेदारी आपकी है।

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

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

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

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

Linux 7.1 में ऐसी कौन सी चीज़ है जो virtual private server पर मायने रखती है?

चार चीजें। Hardware queue leasing एक container को native speed पर AF_XDP के लिए एक वास्तविक NIC queue का उपयोग करने देती है। Swap rework का तीसरा चरण static swap map को हटा देता है और आपके swap device के लिए kernel द्वारा रखे जाने वाले metadata को लगभग 30% तक कम कर देता है। MGLRU page young flags को बैचों में जाँच सकता है, जिसका सबसे बड़ा लाभ 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 error दे सकता है, जिससे package आधा कॉन्फ़िगर रह जाता है: पुराने kernels को sudo apt autoremove --purge के साथ साफ़ करें, फिर reinstall करें। पुराने kernel के लिए बनाए गए out-of-tree modules लोड होना बंद हो जाते हैं, इसलिए DKMS द्वारा प्रबंधित किसी भी चीज़ को फिर से build करना पड़ता है, और एक विफल rebuild तब तक पता नहीं चलता जब तक कि runtime पर module गायब न हो जाए। और यदि reboot के बाद भी uname -r पुराना वर्शन दिखाता है जबकि dpkg -l नई image को सूचीबद्ध करता है, तो install में कुछ भी खराब नहीं हुआ है: bootloader का डिफ़ॉल्ट विकल्प नहीं बदला है।