Linux kernel 7.1 میں servers کے لیے کیا نیا ہے؟

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 آپ کے server پر غالباً چل ہی نہیں رہا، اور طویل عرصے تک نہیں چلے گا۔ 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 ان میں سے کسی line یا اپنی maintain کردہ line پر build ہوتی ہے۔ "kernel میں نیا" اور "آپ کے server پر نیا" ہونے کے درمیان کئی سال کا فرق ہوتا ہے، اس لیے یہ guide دونوں پہلوؤں کا احاطہ کرتی ہے۔

آپ کا 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 کو بالکل track نہیں کرتا۔ Canonical کا 6.8.0-79 بعد کے kernels سے backport کیے گئے ہزاروں fixes رکھتا ہے، اس لیے یہ وہ code نہیں ہے جسے Linus نے March 2024 میں 6.8 کے طور پر tag کیا تھا۔ اسی وجہ سے "میرا kernel پرانا ہے" اتنی مکمل معلومات نہیں دیتا جتنا بظاہر لگتا ہے۔ Features پرانے ہیں۔ Security fixes عموماً پرانے نہیں ہوتے۔

systemd-detect-virt بتاتا ہے کہ آپ kernel تبدیل کر سکتے ہیں یا نہیں۔ مکمل virtual machine پر یہ kvm دکھاتا ہے، جہاں آپ اپنی kernel image boot کرتے ہیں اور upgrade واقعی upgrade ہوتا ہے۔ Container virtualisation پر یہ lxc یا openvz دکھاتا ہے، جہاں host kernel مشترک ہوتا ہے۔ Container plan پر uname -r provider کا kernel دکھاتا ہے، kernel package install کرنے سے boot کیے جانے والے kernel میں کوئی تبدیلی نہیں آتی، اور اس release کا کوئی feature آپ کے لیے اس وقت تک دستیاب نہیں ہوگا جب تک provider host کو نئے kernel پر reboot نہ کرے۔ Kernel سے متعلق کوئی بھی کام plan کرنے سے پہلے یہ check چلائیں۔

[
  {
    "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 releases پیچھے ہے۔ ابھی support میں موجود سب سے پرانا 26 releases پیچھے ہے۔ Ubuntu 24.04 کا default GA kernel 13 releases پیچھے ہے، جبکہ Debian 13 اور RHEL 10، 6.12 longterm line پر 9 releases پیچھے ہیں۔ Releases گننا ایک سرسری پیمانہ ہے، کیونکہ اس میں distributions کے backport کیے گئے تمام changes شامل نہیں ہوتے، لیکن اس سے فرق کی مجموعی صورت واضح ہو جاتی ہے۔ اگر آپ ان میں سے کسی platform کو چلانے کا فیصلہ کر رہے ہیں تو server پر LTS اور interim release کے درمیان trade-off ان اعداد کے پیچھے موجود اصل فیصلہ ہے۔

7.1 میں storage اور filesystems

7.1 میں صرف block layer کے بجائے filesystem کے اندر T10 PI (protection information) generate اور verify کرنے کی صلاحیت شامل کی گئی ہے۔ اس کے ساتھ flexible T10 alignment support بھی موجود ہے۔ T10 PI ہر block کے ساتھ منسلک اضافی bytes ہوتے ہیں۔ ان میں checksum اور ایک tag شامل ہوتا ہے، جو بتاتا ہے کہ data کس block سے تعلق رکھتا ہے۔ اس طرح misdirected یا torn write کو درست data کے طور پر واپس کرنے کے بجائے پکڑ لیا جاتا ہے۔ VPS tenant کے لیے اصل رکاوٹ hardware ہے۔ Integrity metadata کو device کی طرف سے expose کیا جانا ضروری ہے، جبکہ virtual disk عموماً یہ metadata expose نہیں کرتی۔

ls /sys/block/vda/integrity/

زیادہ تر VPS disks پر اس کا نتیجہ No such file or directory آتا ہے، کیونکہ block layer صرف اسی وقت integrity directory بناتی ہے جب device integrity support register کرے۔ یہاں یہ error معمول کا جواب ہے، fault نہیں۔ اگر storage features کے بارے میں مزید پڑھنے سے پہلے آپ جاننا چاہتے ہیں کہ آپ کی disk حقیقت میں کیا ہے، تو پہلے یہ جانچیں کہ VPS disk واقعی NVMe ہے یا نہیں، اور VPS پر NVMe اور SATA SSD کے درمیان فرق واضح کرتا ہے کہ اس سے آپ کے اعداد کیوں بدل جاتے ہیں۔

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 کی حد ختم ہو جاتی ہے۔ Network filesystem کے جانب، in-kernel NFS server اب sign_fh mount option کے ذریعے اپنے file handles sign کر سکتا ہے، اور CIFS client نے O_TMPFILE سیکھ لیا ہے۔

نیٹ ورکنگ: queue leasing، اور اس سے container کو ملنے والے فوائد

نیٹ ورکنگ میں بنیادی تبدیلی hardware queue leasing ہے۔ اب ایک virtual netdev ایسی queue lease کر سکتا ہے جو physical netdev کی حقیقی queue سے bound ہو، اور اس کے proxy کے طور پر کام کر سکتا ہے۔ اس کا مقصد containers ہیں۔ اب تک AF_XDP استعمال کرنے والے container کو تقریباً پورا device دینا پڑتا تھا۔ AF_XDP سے مراد address family express data path ہے۔ یہ ایسا socket type ہے جو raw packets کو network stack کے ذریعے copy کیے بغیر user space تک پہنچاتا ہے۔ leased queue کے ذریعے container کو ایک hardware queue ملتی ہے۔ وہ native speed پر AF_XDP اور memory providers چلا سکتا ہے، جبکہ host کو NIC کی باقی queues حاصل رہتی ہیں۔ یہ سہولت 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 کی بنیاد پر filter کر سکتا ہے۔

دو چیزیں ہٹا دی گئی ہیں۔ UDP-Lite ختم کر دیا گیا ہے کیونکہ اس کے کوئی users نہیں ملے۔ IPv6 کو اب loadable module کے طور پر build نہیں کیا جا سکتا۔ اگر IPv6 چاہیے تو اسے kernel میں compile کیا جاتا ہے۔ دوسری تبدیلی کسی بھی distribution kernel میں نظر نہیں آئے گی، کیونکہ عام server distributions پہلے ہی IPv6 کو kernel میں built-in رکھتی ہیں۔

میموری کا انتظام: swap table مکمل ہو گئی

swap میں کی گئی دوبارہ ساخت کا یہ تیسرا مرحلہ ہے، اور اس مرحلے میں static swap map ختم کر دیا گیا ہے۔ swap count اب براہ راست swap table میں موجود ہے۔ رپورٹ کی گئی بچت static swap metadata کے تقریباً 30% کے برابر ہے۔ یہ وہ میموری ہے جسے kernel آپ کے swap device کے حجم کے تناسب سے برقرار رکھتا ہے، چاہے کوئی چیز swap ہو یا نہ ہو۔ absolute terms میں چھوٹی swap file پر یہ مقدار کم ہوتی ہے، اور آپ جتنی swap configure کریں گے، یہ اتنی ہی بڑھے گی۔

MGLRU (multi-generational least recently used، یعنی نیا page reclaim algorithm) اب صفحات میں موجود young flag کو ایک وقت میں ایک صفحے کے بجائے batches میں چیک کر سکتا ہے۔ اس تبدیلی کے ساتھ شائع کی گئی کارکردگی میں Arm64 32-core server پر 60% سے زیادہ بہتری دکھائی گئی ہے۔ batching کا فائدہ وہاں زیادہ ہوتا ہے جہاں ہر page کی لاگت زیادہ ہو۔ اسی لیے یہ عدد ایک بڑی Arm machine سے حاصل ہوا۔ اگر آپ x86 کے بجائے Arm VPS استعمال کرتے ہیں تو یہ 7.1 کی وہ تبدیلی ہے جس کے آپ کی اپنی measurements میں ظاہر ہونے کا امکان سب سے زیادہ ہے، اگرچہ دو یا چار cores پر یہ بہتری اس پیمانے کی نہیں ہوگی۔

یہاں مزید یہ تبدیلیاں بھی شامل ہیں: ختم ہونے والے memory cgroups سے transfers اب نہیں ہوتے، khugepaged کم CPU کے ساتھ scans کرتا ہے، اور maple tree میں اس کے بڑے nodes کو handle کرنے کے طریقے کے گرد بڑی refactor کی گئی ہے۔ ان میں سے کسی کو configure نہیں کرنا پڑتا۔ آپ صرف system time میں معمولی کمی محسوس کریں گے۔

شیڈولرز: sched_ext ذیلی شیڈولرز، اور FRED بطور ڈیفالٹ فعال

sched_ext ایک قابل توسیع scheduler class ہے۔ یہ آپ کو BPF program کے طور پر CPU scheduler لکھنے اور اسے runtime پر load کرنے دیتی ہے۔ یہ سہولت 6.12 میں شامل ہوئی تھی۔ 7.1 میں ذیلی شیڈولرز کے لیے بنیادی structure شامل کیا گیا ہے، تاکہ مستقبل میں کوئی control group اپنا scheduler استعمال کر سکے۔ اس جملے کو غور سے پڑھیں۔ 7.1 میں implementation مکمل نہیں ہے، اور خاص طور پر enqueue path موجود نہیں۔ اس لیے یہ آئندہ release کے لیے بنیادی کام ہے، نہ کہ ایسی سہولت جسے آپ آج فعال کر سکیں۔

Intel FRED (flexible return and event delivery) اب ایسے hardware پر بطور ڈیفالٹ enabled ہے جو اسے support کرتا ہے۔ FRED پرانے x86 event delivery path کی جگہ زیادہ صاف path استعمال کرتا ہے۔ یہ 6.9 سے kernel میں موجود ہے، مگر اس سے پہلے fred=on boot argument کے ذریعے اسے فعال کرنا پڑتا تھا۔ اسے بطور ڈیفالٹ enabled کرنا اس بات کی علامت ہے کہ دستیاب hardware پر کافی testing ہو چکی ہے۔ اب تک شائع شدہ measurements، جو 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 اور quality سے متعلق تبدیلیاں ہیں جنہیں کوئی configuration file ظاہر نہیں کرتی۔

clone3() میں نئے process اور container controls

clone3() میں تین flags شامل کیے گئے ہیں، اور ہر flag اس خلا کو دور کرتا ہے جس کے لیے supervisors کئی سال سے دستی حل استعمال کرتے رہے ہیں۔ CLONE_AUTOREAP child کو exit کے وقت خود reap ہونے کا پابند کرتا ہے، اس لیے وہ ایسے parent کے انتظار میں zombie نہیں بنتا جو شاید کبھی wait() کو call نہ کرے۔ CLONE_NNP child کی تخلیق کے وقت ہی اس پر no_new_privs set کرتا ہے۔ اس سے clone اور child کے اپنے لیے یہ flag set کرنے کے درمیان موجود window ختم ہو جاتی ہے۔ CLONE_PIDFD_AUTOKILL child کی lifetime کو parent کو واپس ملنے والے pidfd سے وابستہ کرتا ہے: pidfd close کریں تو child kill ہو جاتا ہے۔ اس طرح supervisor کے ختم ہونے پر orphans چلتے نہیں رہتے۔

Mount namespaces کے ساتھ بھی یہی طریقہ اختیار کیا گیا ہے۔ CLONE_EMPTY_MNTNS، clone3() کے لیے، اور UNSHARE_EMPTY_MNTNS، unshare() کے لیے، ایسا mount namespace بناتے ہیں جس میں کچھ بھی موجود نہیں ہوتا۔ معمول کے طریقے میں parent کے mounts کی مکمل copy بنائی جاتی ہے، جسے runtime کو بعد میں unmount کرنا پڑتا ہے۔ FSMOUNT_NAMESPACE، fsmount() کو filesystem براہ راست نئے namespace میں رکھنے دیتا ہے۔ Container runtimes ایک دہائی سے یہ کام دستی طور پر کرتے آ رہے ہیں۔ اب یہ کام ایک call میں ہو جاتا ہے، اس لیے runtime کو host کے mounts سے بھرے ہوئے namespace سے آغاز نہیں کرنا پڑتا۔

Virtualisation کے معاملے میں guest_memfd اب userfaultfd کو support کرتا ہے، اس لیے hypervisor guest page faults کو user space سے handle کر سکتا ہے۔ Arm پر Protected KVM کو anonymous memory support بھی حاصل ہو گئی ہے۔ خود merge کی وضاحت کے مطابق یہ feature ابھی production کے لیے تیار نہیں ہے۔

آپ کے server تک kernel 7.1 کب پہنچے گا

Fedora میں یہ پہلے ہی موجود ہے۔ Fedora 44 کا update repository جولائی اور اگست 2026 کے دوران 7.1 series پر منتقل ہو گیا، کیونکہ Fedora ہر release کے اندر اپنے kernel کو نئی stable lines پر rebase کرتا ہے۔ Arch اور openSUSE Tumbleweed میں بھی اسی وجہ سے یہ موجود ہے۔ یہ ایسی machines ہیں جن پر testing کی جاتی ہے، services چلانے کے لیے نہیں۔

باقی سب انتظار کرتے ہیں، اور یہ انتظار منصوبہ بندی کے مطابق ہے۔ 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 موجود ہے، جو بعد کی Ubuntu releases سے نیا kernel لے کر LTS میں شامل کرتا ہے۔ 24.04.4 point release کے مطابق یہ stack 6.17 پر ہے، اور 27 August 2026 کو scheduled 24.04.5 کے ساتھ 7.0 پر منتقل ہونے والا ہے۔

یہ وہ حصہ ہے جس کے بارے میں لوگ غلط فہمی رکھتے ہیں۔ HWE stack اس kernel پر منتقل ہو جاتا ہے جو تازہ ترین interim release میں شامل ہو، اس لیے یہ upstream line کو مکمل طور پر چھوڑ سکتا ہے۔ 7.0 ایک Ubuntu LTS میں موجود ہے۔ 7.1 شاید کبھی کسی LTS کی base نہ بنے، کیونکہ اس کے بعد آنے والی interim release میں اس سے بھی نئی line شامل ہوگی۔ 7.1 سے آپ کے LTS تک fixes پہنچتی ہیں، جو آپ کے زیر استعمال line میں backport کی جاتی ہیں۔ Features زیادہ تر شامل نہیں کیے جاتے۔

اگر آپ 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

reboot کے بعد یہ چیک کریں کہ آپ نے حقیقت میں کون سا kernel boot کیا ہے:

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

uname -r میں اب نئی line دکھائی دینی چاہیے، جبکہ dpkg -l میں اب بھی installed ہر kernel image دکھائی جائے گی۔ اگر uname -r میں پرانا version دکھائی دے اور dpkg -l میں نیا version درج ہو، تو package install ہو چکا ہے لیکن bootloader کا default تبدیل نہیں ہوا۔ GRUB menu entries دیکھیں۔ /var/run/reboot-required کا موجود ہونا بتاتا ہے کہ package نے kernel upgrade کر دیا تھا اور اس کے بعد reboot نہیں ہوا۔ Patched server کے اب بھی vulnerable code چلا رہے ہونے کی یہ سب سے عام وجہ ہے۔

پیداواری VPS پر 7.1 حاصل کرنے کی کوشش کرنی چاہیے؟

نہیں، اور اس کی وجہ محض احتیاط نہیں ہے۔ distribution kernel دراصل support contract ہوتا ہے۔ Canonical، Red Hat، SUSE اور Debian اپنی frozen line میں security fixes کو backport کرتے ہیں اور انہیں اس userspace کے ساتھ test کرتے ہیں جو اسی کے ساتھ فراہم کیا جاتا ہے۔ کسی third-party archive کا mainline kernel یا خود build کیا ہوا kernel آپ کو نئی features تو دیتا ہے، لیکن یہ کام آپ سے لے لیتا ہے، کیونکہ آپ کی build میں fixes backport کرنے والا کوئی نہیں ہوتا۔ اس طرح kernel کی maintenance آپ کی ذمہ داری بن جاتی ہے۔

استثنا واقعی موجود ہیں، لیکن محدود ہیں: ایسا hardware جسے پرانا kernel چلا نہیں سکتا، یا performance میں ایسی تبدیلی جسے آپ نے اپنے workload پر ناپا ہو اور جس کے نتائج کی ذمہ داری قبول کرنے کے لیے کافی اہم سمجھتے ہوں۔ VPS پر پہلی صورت تقریباً کبھی لاگو نہیں ہوتی، کیونکہ آپ کو نظر آنے والا hardware virtual ہوتا ہے۔ باقی تمام صورتوں میں distribution kernel کو current رکھیں اور جب وہ 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 جیسا output دکھاتا ہے۔ پہلے dash سے پہلے والا نمبر وہ upstream line ہے جس پر آپ کی distribution build کرتی ہے، جبکہ اس کے بعد موجود تمام حصہ 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 ختم کر دی جاتی ہے۔ اگر آپ ایسا kernel چاہتے ہیں جس کے لیے کئی سال کی fixes پہلے سے دستیاب ہوں اور آئندہ بھی کئی سال تک fixes ملتی رہیں، تو آپ کی distribution کا kernel پہلے ہی یہی خصوصیت رکھتا ہے۔

Ubuntu یا Debian kernel 7.1 کب ship کریں گے؟

ممکن ہے کہ کبھی بھی default کے طور پر نہ کریں۔ Debian 13 release کی پوری مدت کے لیے 6.12 پر رہے گا، جبکہ RHEL 10، 6.12.0 پر رہے گا۔ Ubuntu 26.04 LTS نے 7.0 ship کیا، اور Ubuntu hardware enablement stack اس kernel پر منتقل ہو جاتا ہے جو تازہ ترین interim release میں شامل ہو۔ اس لیے یہ upstream line کو مکمل طور پر skip کر سکتا ہے۔ Ubuntu 24.04 LTS کے HWE kernel کو 24.04.5 point release کے ساتھ 27 August 2026 کو 7.0 پر منتقل کیا جانا مقرر ہے۔ 7.1 کی fixes آپ تک older line میں backports کے طور پر پہنچیں گی۔ عموماً features نہیں پہنچیں گے۔

Linux 7.1 میں ایسی کون سی چیزیں ہیں جو virtual private server پر واقعی اہم ہیں؟

چار چیزیں اہم ہیں۔ Hardware queue leasing سے container ایک حقیقی NIC queue کو native speed پر AF_XDP کے لیے استعمال کر سکتا ہے۔ Swap rework کا تیسرا phase static swap map ختم کرتا ہے اور swap device کے لیے kernel کے زیر انتظام metadata کو رپورٹ کردہ 30% تک کم کرتا ہے۔ MGLRU page young flags کو batches میں چیک کر سکتا ہے، اور اس کا سب سے بڑا شائع شدہ فائدہ many-core Arm server پر دیکھا گیا ہے۔ اس کے علاوہ clone3() میں CLONE_AUTOREAP، CLONE_NNP اور CLONE_PIDFD_AUTOKILL شامل کیے گئے ہیں، جو child processes کی نگرانی کو زیادہ محفوظ بناتے ہیں۔ Filesystem-level T10 protection information بھی شامل کی گئی ہے، لیکن virtual disk عموماً وہ integrity metadata فراہم نہیں کرتی جس کی اسے ضرورت ہوتی ہے۔

کیا kernel upgrade کرنے سے میرا VPS خراب ہو جائے گا؟

عام failures boot کے وقت پیش آتے ہیں۔ مکمل /boot install کے دوران update-initramfs کو No space left on device کے ساتھ fail کر دیتا ہے، جس سے package half configured رہ جاتا ہے۔ پرانے kernels کو sudo apt autoremove --purge سے صاف کریں، پھر package دوبارہ install کریں۔ پرانے kernel کے خلاف build کیے گئے out-of-tree modules load ہونا بند ہو جاتے ہیں۔ اس لیے DKMS کے زیر انتظام ہر چیز کو دوبارہ build کرنا ہوگا، اور failed rebuild اس وقت تک خاموش رہتا ہے جب تک runtime پر module missing نہ ہو۔ اگر reboot کے بعد uname -r اب بھی پرانا version دکھائے، جبکہ dpkg -l نئی image درج کرے، تو install میں کوئی خرابی نہیں ہوئی۔ Bootloader default تبدیل نہیں ہوا۔