Linux kernel 7.1 मध्ये server साठी नवीन काय?

Linux kernel 7.1 मध्ये नवीन काय आहे

Linux kernel 7.1 हे 14 June 2026 रोजी, 7.0 नंतर नऊ आठवड्यांनी, release झाले. VPS (virtual private server) वापरकर्त्यासाठी महत्त्वाचे बदल चार क्षेत्रांत आहेत: storage आणि filesystems, networking, memory management, तसेच process आणि container control. या release मधील उर्वरित काम प्रामुख्याने desktop आणि graphics संबंधित आहे. Headless server वर ते सहसा load होत नाही.

मात्र त्यापूर्वी दुसऱ्या प्रश्नाचे उत्तर आवश्यक आहे. तुमच्या server वर 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 आहेत. मुख्य server distributions यांपैकी एखाद्या line वर किंवा स्वतः maintain केलेल्या line वर आधारित असतात. “kernel मध्ये नवीन” आणि “तुमच्या server वर नवीन” यांमध्ये अनेक वर्षांचे अंतर असते. त्यामुळे या मार्गदर्शिकेत दोन्ही भागांचा समावेश आहे.

तुमचा VPS सध्या कोणते kernel चालवत आहे

uname -r
uname -srm
systemd-detect-virt

uname -r चालू kernel release दाखवते. Ubuntu 24.04 वर ते 6.8.0-79-generic असे दिसते. पहिल्या dash च्या आधीचा भाग upstream line असतो. त्यानंतरचा संपूर्ण भाग तुमच्या distribution चा स्वतःचा build number असतो आणि तो upstream शी अजिबात समक्रमित नसतो. Canonical चे 6.8.0-79 नंतरच्या kernels मधील हजारो fixes backport करते. त्यामुळे ते मार्च 2024 मध्ये Linus ने 6.8 म्हणून tag केलेला code नाही. म्हणून “माझे kernel जुने आहे” या विधानाचा अर्थ ऐकू येतो तितका सरळ नसतो. Features जुने असतात. मात्र security fixes सहसा जुने नसतात.

systemd-detect-virt वापरून तुम्ही kernel बदलू शकता की नाही हे समजते. पूर्ण virtual machine वर, जिथे तुम्ही तुमची स्वतःची kernel image boot करता आणि upgrade म्हणजे प्रत्यक्ष upgrade असते, ते kvm दाखवते. Container virtualisation वर, जिथे host kernel shared असते, ते lxc किंवा openvz दाखवते. Container plan वर uname -r provider चे kernel दाखवते. Kernel package install केल्याने तुम्ही boot करू शकणाऱ्या kernel मध्ये कोणताही बदल होत नाही. Provider ने host अधिक नवीन kernel वर reboot करेपर्यंत या release मधील कोणतेही feature तुम्हाला उपलब्ध होत नाही. कोणतेही kernel work नियोजित करण्यापूर्वी ही तपासणी करा.

[
  {
    "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 करत नाही. सर्वांत नवीन platform Ubuntu 26.04 LTS (7.0) आहे. ते upstream release पेक्षा 1 releases मागे आहे. अजूनही support मध्ये असलेले सर्वांत जुने platform 26 releases मागे आहे. Ubuntu 24.04 चे default GA kernel 13 releases मागे आहे. Debian 13 आणि RHEL 10 ही 6.12 longterm line वर 9 releases मागे आहेत. Releases मोजणे हा अंदाजे मापदंड आहे, कारण distributions कडून backport केलेल्या सर्व गोष्टी त्यात धरल्या जात नाहीत. तरीही या अंतराचे स्वरूप त्यातून दिसते. यांपैकी कोणते run करायचे याचा विचार करत असाल, तर server वर LTS आणि interim release मधील trade-off हा या संख्यांमागील मुख्य निर्णय आहे.

7.1 मधील storage आणि filesystems

7.1 मध्ये केवळ block layer मध्येच नव्हे, तर filesystem च्या आत T10 PI (protection information) तयार आणि पडताळण्याची क्षमता जोडली आहे. यासोबत लवचिक T10 alignment support देखील मिळते. T10 PI म्हणजे प्रत्येक block ला जोडलेले अतिरिक्त bytes. त्यात checksum आणि data कोणत्या block शी संबंधित आहे हे ओळखणारा tag असतो. त्यामुळे misdirected किंवा torn write चुकून योग्य data म्हणून परत दिला जाण्याऐवजी पकडला जातो. VPS tenant साठी अडचण hardware ची आहे. Integrity metadata device ने उपलब्ध करून देणे आवश्यक असते. Virtual disk मध्ये ते सहसा उपलब्ध नसते.

ls /sys/block/vda/integrity/

बहुतेक VPS disks वर यामुळे No such file or directory परत मिळते. Device ने integrity support नोंदवल्यावरच block layer integrity directory तयार करते. त्यामुळे येथे मिळणारी ही error सामान्य आहे; ती fault दर्शवत नाही. Storage features मध्ये पुढे जाण्यापूर्वी तुमची disk प्रत्यक्षात काय आहे हे जाणून घ्यायचे असल्यास VPS disk प्रत्यक्षात NVMe आहे का ते तपासणे हा पहिला टप्पा आहे. तसेच VPS वरील NVMe आणि SATA SSD मधील फरक यामुळे तुमचे numbers का बदलतात हे स्पष्ट होते.

Btrfs मध्ये memory pressure असताना copy-on-write amplification साठी fixes मिळतात. Tracked range मधील पहिला extent clear करण्याची प्रक्रिया वेगवान करणारा बदलही जोडला आहे. Merge मध्ये नमूद केलेल्या sample workload वर throughput 10% अधिक नोंदवला गेला आहे. त्याचे shutdown operation आता experimental म्हणून marked नाही. XFS मध्ये iomap द्वारे zero range flushing आणि lookup सुधारले आहेत. तसेच real-time group geometry मध्ये write pointer जोडला आहे. हा zoned devices साठी आवश्यक पाया आहे. या release मध्ये NTFS चे पूर्ण rewrite झाले आहे. त्यात full write support आणि iomap conversion आहे. Windows machine वरील disk image तुमच्या server वर mount करायची असल्यास हे महत्त्वाचे ठरते.

लक्षात ठेवण्यासारख्या इतर storage बाबी: ublk या user-space block driver मध्ये zero-copy I/O जोडले आहे; io_uring मध्ये SCSI passthrough commands जोडले आहेत; SED-OPAL self-encrypting drive support मध्ये STACK_RESET command आणि extended single user mode जोडले आहे; direct-access devices साठी नवीन fs-dax character driver उपलब्ध आहे; आणि VFS ने inode->i_ino ची रुंदी unsigned long वरून u64 केली आहे. त्यामुळे 32-bit builds मधील inode number ceiling दूर होते. Network filesystem च्या बाबतीत, in-kernel NFS server आता sign_fh mount option द्वारे file handles वर स्वाक्षरी करू शकतो. CIFS client मध्ये O_TMPFILE support जोडले आहे.

नेटवर्किंग: queue leasing आणि कंटेनरला मिळणारे फायदे

नेटवर्किंगमधील मुख्य बदल म्हणजे hardware queue leasing. आता virtual netdev कडे physical netdev वरील वास्तविक queue शी बांधलेली queue lease करता येते आणि तो तिच्यासाठी proxy म्हणून काम करू शकतो. याचा उद्देश containers आहेत. आतापर्यंत AF_XDP (address family express data path; network stack मधून raw packets copy न करता थेट user space कडे देणारा socket प्रकार) वापरू इच्छिणाऱ्या container ला जवळजवळ संपूर्ण 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 वर filter लागू करू शकतो.

दोन गोष्टी काढून टाकण्यात आल्या आहेत. वापरकर्ते आढळले नाहीत, म्हणून UDP-Lite काढून टाकण्यात आले आहे. IPv6 आता loadable module म्हणून build करता येणार नाही. IPv6 हवे असल्यास ते kernel मध्ये compiled in असावे लागेल. हा बदल कोणत्याही distribution kernel मध्ये दिसणार नाही, कारण सर्वसाधारण server distributions आधीपासूनच IPv6 compiled in ठेवतात.

मेमरी व्यवस्थापन: swap table चे काम पूर्ण

swap मधील पुनर्रचनेचा हा तिसरा टप्पा आहे. या टप्प्यात static swap map काढून टाकला आहे. आता swap count थेट swap table मध्ये ठेवला जातो. नोंदवलेली बचत static swap metadata च्या सुमारे 30% इतकी आहे. swap device मध्ये काहीही swap झाले नसले, तरी kernel ही memory swap device च्या आकाराच्या प्रमाणात राखून ठेवतो. लहान swap file वर ही बचत प्रत्यक्ष प्रमाणात कमी असते. तुम्ही configure केलेल्या swap चे प्रमाण वाढल्यावर ही बचतही वाढते.

MGLRU (multi-generational least recently used, म्हणजे नवीन page reclaim algorithm) आता pages वरील young flag एकावेळी एका page ऐवजी batches मध्ये तपासू शकते. या बदलासोबत प्रसिद्ध केलेल्या आकडेवारीनुसार Arm64 32-core server वर 60% पेक्षा जास्त सुधारणा झाली. प्रत्येक page वरील खर्च जिथे जास्त असतो, तिथे batching चा सर्वाधिक फायदा होतो. म्हणूनच हा आकडा मोठ्या Arm मशीनवरून मिळाला. तुम्ही x86 ऐवजी Arm VPS चालवत असाल, तर 7.1 मधील तुमच्या स्वतःच्या मोजमापांत दिसण्याची सर्वाधिक शक्यता असलेला हा बदल आहे. मात्र two किंवा four cores असलेल्या प्रणालीवर ही सुधारणा त्या प्रमाणात दिसणार नाही.

यामध्ये आणखी काही बदल आहेत: dying memory cgroups मधून transfers आता होत नाहीत, khugepaged कमी CPU वापरून scans करते आणि maple tree मध्ये त्याच्या big node handling भोवती मोठी refactor करण्यात आली आहे. यापैकी कोणतीही गोष्ट तुम्हाला configure करावी लागत नाही. प्रणालीचा system time किंचित कमी झाल्याचे तुम्हाला जाणवेल.

शेड्युलर: sched_ext उप-शेड्युलर आणि FRED आता डीफॉल्टने सक्षम

sched_ext हा विस्तारक्षम scheduler class आहे. त्याद्वारे BPF program म्हणून CPU scheduler लिहून तो runtime वर load करता येतो. तो 6.12 मध्ये समाविष्ट झाला. 7.1 मध्ये sub-schedulers साठी मूलभूत रचना जोडली आहे. त्यामुळे भविष्यात एखादा control group स्वतःच्या scheduler अंतर्गत चालवता येईल. हे वाक्य काळजीपूर्वक वाचा. 7.1 मध्ये ही अंमलबजावणी पूर्ण झालेली नाही. विशेषतः enqueue path अद्याप उपलब्ध नाही. त्यामुळे हे आज सुरू करता येणारे feature नसून पुढील release साठीची पायाभूत तयारी आहे.

Intel FRED (flexible return and event delivery) ला समर्थन देणाऱ्या hardware वर ते आता डीफॉल्टने सक्षम आहे. FRED जुन्या x86 event delivery path ऐवजी अधिक सुसंगत path वापरतो. fred=on boot argument मागे ठेवून ते 6.9 पासून kernel मध्ये उपलब्ध आहे. ते डीफॉल्टने सक्षम करण्याचा निर्णय म्हणजे उपलब्ध hardware वर पुरेशा चाचण्या झाल्या आहेत, असा संकेत आहे. आतापर्यंत प्रकाशित मोजमापांमध्ये I/O-heavy workloads वर 4% ते 7% सुधारणा दिसते. ही मोजमापे client silicon वर Phoronix testing मधून मिळाली आहेत. त्यामुळे स्वतःच्या workload चे मोजमाप करेपर्यंत server साठी अशी सुधारणा गृहीत धरू नका.

Proxy execution मध्ये remote lock owner ला boost करण्यासाठी donor migration जोडले आहे. EEVDF मध्ये negative lag संदर्भातील दुरुस्त्या करण्यात आल्या आहेत. High-resolution timer core ची मोठ्या प्रमाणावर पुनर्रचना करण्यात आली आहे. ही latency आणि गुणवत्ता सुधारणा आहेत. त्यांच्यासाठी कोणत्याही configuration file मध्ये पर्याय उपलब्ध नाही.

clone3() मधील नवीन प्रक्रिया आणि कंटेनर नियंत्रणे

clone3() मध्ये तीन flags जोडण्यात आले आहेत. प्रत्येक flag मुळे supervisors अनेक वर्षे हाताने भरून काढत असलेली एक कमतरता दूर होते. CLONE_AUTOREAP मुळे child exit झाल्यावर स्वतःच reap होते. त्यामुळे parent ने कदाचित कधीही wait() call न केल्यास ते zombie म्हणून प्रतीक्षा करत राहत नाही. CLONE_NNP child तयार होताच त्यावर no_new_privs सेट करते. त्यामुळे clone झाल्यानंतर child ने स्वतःसाठी हा flag सेट करेपर्यंत असलेली कालमर्यादा संपते. CLONE_PIDFD_AUTOKILL child चे lifetime parent ला परत मिळालेल्या pidfd शी जोडते. pidfd बंद केल्यावर child kill होते. त्यामुळे supervisor बंद पडल्यास orphan प्रक्रिया चालू राहत नाहीत.

Mount namespaces साठीही अशीच सुविधा देण्यात आली आहे. CLONE_EMPTY_MNTNS साठी clone3() आणि UNSHARE_EMPTY_MNTNS साठी unshare() वापरल्यास त्यामध्ये काहीही नसलेला mount namespace तयार होतो. नेहमीच्या पद्धतीत parent च्या mounts ची संपूर्ण प्रत त्यात तयार होते आणि runtime ला ती नंतर unmount करावी लागते. FSMOUNT_NAMESPACE मुळे fsmount() filesystem थेट नवीन namespace मध्ये ठेवू शकते. Container runtimes हे काम गेल्या दशकभरापासून हाताने करत आहेत. आता ते एका call मध्ये करता येते. त्यामुळे runtime ला host चे mounts असलेल्या namespace पासून सुरुवात करावी लागत नाही.

Virtualisation च्या बाजूने, guest_memfd आता userfaultfd ला support करते. त्यामुळे hypervisor user space मधून guest page faults हाताळू शकतो. Arm वरील Protected KVM ला anonymous memory चे support मिळाले आहे. मात्र merge च्या वर्णनातच हे production साठी अद्याप तयार नसल्याचे नमूद केले आहे.

तुमच्या सर्व्हरवर kernel 7.1 कधी उपलब्ध होईल

Fedora मध्ये ते आधीच उपलब्ध आहे. Fedora 44 update repository जुलै आणि ऑगस्ट 2026 दरम्यान 7.1 मालिकेवर गेले, कारण Fedora एखाद्या release च्या कालावधीत आपला kernel नवीन stable series वर rebase करते. Arch आणि openSUSE Tumbleweed मध्येही ते याच कारणामुळे उपलब्ध आहे. ही यंत्रे चाचणीसाठी वापरा; सेवा चालवण्यासाठी नाही.

इतर सर्व distributions प्रतीक्षा करतात आणि ही प्रतीक्षा जाणीवपूर्वक असते. Debian 13 हे 6.12 सह release झाले आणि release च्या संपूर्ण कालावधीत 6.12 वरच राहते. त्यामध्ये fixes backport केले जातात. RHEL 10 हे 6.12.0 सह release झाले आणि तेही अशीच पद्धत वापरते. Ubuntu 26.04 LTS हे एप्रिल 2026 मध्ये 7.0 सह release झाले. Ubuntu 24.04 LTS मध्ये hardware enablement stack आहे. हा stack नंतरच्या Ubuntu releases मधून नवीन kernel LTS मध्ये आणतो. 24.04.4 point release नुसार हा stack 6.17 वर आहे. 27 August 2026 रोजी नियोजित 24.04.5 सह तो 7.0 वर जाणार आहे.

लोकांकडून येथे नेहमी चूक होते. HWE stack नवीनतम interim release मध्ये असलेला kernel स्वीकारतो. त्यामुळे upstream ची एखादी series पूर्णपणे वगळली जाऊ शकते. 7.0 हा Ubuntu LTS मध्ये आहे. 7.1 कदाचित कोणत्याही LTS चा base होणार नाही, कारण त्यानंतरचे interim release त्यापेक्षा पुढील series वापरेल. 7.1 मधील fixes तुमच्या LTS पर्यंत पोहोचतात, पण ते तुम्ही वापरत असलेल्या series मध्ये backport केलेले असतात. बहुतेक features मात्र त्या नवीन series मध्येच राहतात.

Stable server वर नवीन kernel हवा असल्यास supported मार्ग थोडेच आहेत.

# 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

रीबूटनंतर प्रत्यक्षात कोणता kernel boot झाला ते तपासा:

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

uname -r मध्ये आता नवीन series दिसली पाहिजे आणि dpkg -l मध्ये अद्याप installed असलेले सर्व kernel images दिसतात. uname -r मध्ये जुनी version दिसत असेल आणि dpkg -l मध्ये नवीन version सूचीबद्ध असेल, तर package installed झाले आहे; मात्र bootloader default बदललेला नाही. GRUB menu entries तपासा. /var/run/reboot-required अस्तित्वात असल्यास package ने kernel upgrade केला आहे, पण त्यानंतर reboot झालेले नाही. Patched server अजूनही vulnerable code execute करत असण्याचे हे सर्वात सामान्य कारण आहे.

Production VPS वर 7.1 चा पाठपुरावा करावा का

नाही. याचे कारण केवळ सावधगिरी नाही. Distribution kernel हा support contract असतो. Canonical, Red Hat, SUSE आणि Debian त्यांच्या स्थिर release line मध्ये security fixes backport करतात आणि त्याच्यासोबत वितरित केलेल्या userspace विरुद्ध त्यांची चाचणी घेतात. Third-party archive मधील mainline kernel किंवा स्वतः build केलेला kernel तुम्हाला नवीन features देतो, पण हे काम तुमच्यावर सोपवतो, कारण तुमच्या build मध्ये fixes backport करणारे कोणीही नसते. त्यामुळे kernel maintain करण्याची जबाबदारी तुमच्यावर येते.

अपवाद खरे आहेत, पण मर्यादित आहेत: जुन्या kernel ला चालवता न येणारे hardware किंवा स्वतःच्या workload वर मोजून पाहिलेला performance बदल, ज्याचे परिणाम स्वीकारण्याइतकी तुम्हाला त्याची आवश्यकता आहे. VPS मध्ये पहिला अपवाद जवळजवळ लागू होत नाही, कारण तुम्हाला दिसणारे hardware virtual असते. इतर सर्व बाबतीत distribution kernel अद्ययावत ठेवा आणि तो reboot करण्यास सांगेल तेव्हा reboot करा. Distribution upgrade आधीच तुमच्या यादीत असल्यास, Ubuntu 24.04 वरून 26.04 कडे स्थलांतर एका टप्प्यात तुम्हाला 6.8 वरून 7.0 पर्यंत नेते. हा बदल कोणतेही एकटे kernel package देऊ शकते त्यापेक्षा मोठा आहे.

FAQ

माझा VPS कोणता Linux kernel चालवत आहे हे कसे तपासू?

uname -r चालवा. त्यात 6.8.0-79-generic सारखे आउटपुट दिसते. पहिल्या dash पूर्वीचा क्रमांक म्हणजे तुमचे distribution ज्या upstream line वर आधारित build करते ती line. त्यानंतरचा संपूर्ण भाग म्हणजे distribution चा स्वतःचा build number. त्यात backported fixes समाविष्ट असतात. त्यानंतर systemd-detect-virt चालवा. त्यात lxc किंवा openvz दिसल्यास तुम्ही container virtualisation वर आहात. तुम्ही host चा kernel share करता आणि तो बदलू शकत नाही. त्यात kvm दिसल्यास तुम्ही तुमची स्वतःची kernel image boot करता. तिचे upgrades तुम्हालाच करावे लागतात.

Linux 7.1 हा longterm support kernel आहे का?

नाही. 11 August 2026 रोजी kernel.org वर सूचीबद्ध longterm lines 6.18, 6.12, 6.6, 6.1, 5.15 आणि 5.10 आहेत. 7.1 त्यात नाही. हे एक सामान्य stable release आहे. पुढील mainline release आल्यानंतर त्याची stable line लवकरच बंद केली जाते. अनेक वर्षे fixes मिळालेला आणि पुढेही अनेक वर्षे fixes मिळणारा kernel हवा असल्यास, तुमच्या distribution चा kernel आधीपासून तसाच असतो.

Ubuntu किंवा Debian kernel 7.1 कधी ship करतील?

बहुधा default म्हणून कधीच नाही. Release च्या संपूर्ण कालावधीत Debian 13 हे 6.12 वरच राहते. RHEL 10 हे 6.12.0 वरच राहते. Ubuntu 26.04 LTS ने 7.0 ship केले. Ubuntu hardware enablement stack नवीनतम interim release मध्ये असलेला kernel स्वीकारतो. त्यामुळे एखादी upstream line पूर्णपणे वगळली जाऊ शकते. Ubuntu 24.04 LTS चे HWE kernel 27 August 2026 रोजी 24.04.5 point release सोबत 7.0 वर जाण्याचे नियोजित आहे. 7.1 मधील fixes जुन्या line मध्ये backports म्हणून तुमच्यापर्यंत पोहोचतील. मात्र features सहसा पोहोचणार नाहीत.

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 एकाच वेळी तपासू शकतो. अनेक-core Arm server वर याचा सर्वाधिक published gain दिसतो. तसेच clone3() ला CLONE_AUTOREAP, CLONE_NNP आणि CLONE_PIDFD_AUTOKILL मिळाले आहेत. त्यामुळे child processes चे supervision अधिक सुरक्षित होते. Filesystem-level T10 protection information देखील समाविष्ट करण्यात आली आहे. मात्र virtual disk आवश्यक integrity metadata क्वचितच उपलब्ध करून देते.

Kernel upgrade केल्याने माझा VPS बिघडेल का?

सामान्य अपयश boot वेळी होतात. पूर्ण /boot मुळे installation दरम्यान update-initramfs हे No space left on device सह fail होते. त्यामुळे package अर्धवट configured राहते. जुने kernels sudo apt autoremove --purge वापरून काढून टाका आणि त्यानंतर reinstall करा. जुन्या kernel विरुद्ध build केलेले out-of-tree modules load होणे थांबवतात. त्यामुळे DKMS द्वारे व्यवस्थापित होणाऱ्या प्रत्येक गोष्टीचा rebuild करावा लागतो. Rebuild अयशस्वी झाल्यास runtime वेळी module missing होईपर्यंत ते सहसा दिसून येत नाही. तसेच reboot नंतर uname -r अजूनही जुनी version दाखवत असेल आणि dpkg -l नवीन image दाखवत असेल, तर installation मध्ये काही बिघडलेले नाही. Bootloader default बदललेला नाही.