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

Linux kernel 7.1 میں کیا نیا ہے

Linux kernel 7.1، 7.0 کے نو ہفتے بعد، 14 June 2026 کو جاری ہوا۔ VPS (virtual private server) tenant کے لیے اہم تبدیلیاں چار شعبوں میں ہیں: 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 ہیں، اور ہر 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 shared ہوتا ہے۔ 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 میں موجود سب سے پرانا platform 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 اضافی bytes پر مشتمل ہوتا ہے جو ہر block کے ساتھ منسلک ہوتے ہیں۔ ان میں checksum اور ایک tag ہوتا ہے جو بتاتا ہے کہ data کس block سے تعلق رکھتا ہے۔ اس طرح misdirected یا torn write کو اچھے data کے طور پر واپس کرنے کے بجائے پکڑ لیا جاتا ہے۔ VPS tenant کے لیے اصل مسئلہ hardware ہے۔ Device کو integrity metadata 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 معمول کا جواب ہے، خرابی نہیں۔ اگر آپ 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 کی حد ختم ہو جاتی ہے۔ 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 ملتی ہے۔ وہ AF_XDP اور memory providers کو native speed پر چلاتا ہے، جبکہ host کے پاس NIC کی باقی queues رہتی ہیں۔ یہ تبدیلی io_uring کے zero-copy path میں AF_XDP support کے ساتھ شامل کی گئی ہے۔

عام استعمال کے معاملے میں sockfs کے sockets اب user.* extended attributes قبول کرتے ہیں۔ path-based AF_UNIX socket کو پہلے ہی اپنے underlying filesystem سے xattr support ملتی تھی، لیکن صرف sockfs میں موجود socket کے پاس یہ support نہیں تھی۔ اب کوئی process socket کو label کر سکتا ہے، اور eBPF program اس label کی بنیاد پر filter کر سکتا ہے۔

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

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

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

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

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

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

sched_ext ایک قابل توسیع scheduler class ہے، جو آپ کو BPF program کے طور پر CPU scheduler لکھنے اور اسے runtime پر load کرنے دیتی ہے۔ یہ 6.12 میں شامل ہوئی تھی۔ 7.1 میں sub-schedulers کے لیے بنیادی 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 کے پیچھے disabled تھا۔ اسے بطور ڈیفالٹ enabled کرنا اس بات کی علامت ہے کہ مارکیٹ میں دستیاب hardware پر کافی testing ہو چکی ہے۔ اب تک شائع شدہ measurements میں I/O-heavy workloads پر 4% سے 7% تک بہتری دیکھی گئی ہے۔ یہ نتائج client silicon پر Phoronix کی testing سے حاصل ہوئے ہیں۔ اس لیے server کے لیے اتنی بہتری کا budget اس وقت تک نہ بنائیں جب تک اپنے workload کی پیمائش نہ کر لیں۔

Proxy execution میں remote lock owner کو boost کرنے کے لیے donor migration شامل کی گئی ہے۔ EEVDF میں negative lag سے متعلق fixes کی گئی ہیں، اور high-resolution timer core کو بڑی حد تک دوبارہ لکھا گیا ہے۔ یہ latency اور quality سے متعلق تبدیلیاں ہیں۔ ان میں سے کسی کو بھی configuration file کے ذریعے expose نہیں کیا گیا۔

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

clone3() میں تین flags شامل کیے گئے ہیں، اور ہر flag اس خلا کو ختم کرتا ہے جس کے لیے supervisors برسوں سے دستی workaround استعمال کرتے رہے ہیں۔ CLONE_AUTOREAP child کو exit کے وقت خود reaping کرنے پر مجبور کرتا ہے۔ اس طرح وہ ایسے 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 کے ختم ہونے پر orphan processes چلتے نہیں رہتے۔

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 ایسے namespace سے شروع نہیں ہوتا جس میں host کے تمام mounts موجود ہوں۔

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

Kernel 7.1 آپ کے سرور تک کب پہنچتا ہے

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

باقی تمام distributions انتظار کرتی ہیں، اور یہ انتظار منصوبہ بندی کے مطابق ہوتا ہے۔ Debian 13، 6.12 کے ساتھ جاری ہوا اور release کی پوری مدت میں 6.12 پر رہتا ہے؛ اس میں fixes backport کی جاتی ہیں۔ RHEL 10، 6.12.0 کے ساتھ جاری ہوا اور یہی طریقہ اختیار کرتا ہے۔ Ubuntu 26.04 LTS، اپریل 2026 میں 7.0 کے ساتھ جاری ہوا۔ Ubuntu 24.04 LTS میں hardware enablement stack موجود ہے، جو بعد کی Ubuntu releases سے نیا kernel لے کر LTS میں شامل کرتا ہے۔ 24.04.4 point release کے مطابق یہ stack 6.17 پر ہے، اور 27 August 2026 کو جاری ہونے والے 24.04.5 کے ساتھ 7.0 پر منتقل ہونے والا ہے۔ Point release، Ubuntu کا نیا version نہیں ہوتا۔ یہ وہی 24.04 ہوتا ہے جس میں اس وقت تک کی تمام updates کو نئی install media میں شامل کر دیا جاتا ہے۔ اس لیے پہلے سے patch کیے گئے 24.04 server پر 24.04.5 کی تبدیلی HWE kernel line ہے، اور اس کے علاوہ بہت کم تبدیلی ہوتی ہے۔

یہ وہ نکتہ ہے جسے لوگ اکثر غلط سمجھتے ہیں۔ HWE stack، تازہ ترین interim release میں شامل kernel پر منتقل ہو جاتا ہے، اس لیے یہ 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 images دکھائی دیتی ہیں۔ اگر 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 چلا رہے ہونے کی یہ سب سے عام وجہ ہے۔

کیا 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 کی 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 کی فراہم کردہ تبدیلی سے بڑا upgrade ہے۔

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 چلائیں۔ اگر output lxc یا openvz ہو تو آپ container virtualisation استعمال کر رہے ہیں، آپ host کا kernel share کرتے ہیں، اور اسے تبدیل نہیں کر سکتے۔ اگر output kvm ہو تو آپ اپنی kernel image boot کرتے ہیں اور upgrades آپ کو خود کرنے ہوں گے۔

کیا Linux 7.1 long-term support kernel ہے؟

نہیں۔ 11 August 2026 تک kernel.org پر درج long-term 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 نئے interim release میں شامل kernel پر منتقل ہوتا ہے، اس لیے یہ کسی upstream line کو مکمل طور پر skip کر سکتا ہے۔ 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 کا تیسرا phase static swap map ختم کرتا ہے اور kernel کی جانب سے swap device کے لیے رکھی جانے والی metadata میں رپورٹ شدہ 30% کمی کرتا ہے۔ MGLRU page young flags کو batches میں check کر سکتا ہے، جس کا سب سے بڑا شائع شدہ فائدہ 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 رہ جاتا ہے: sudo apt autoremove --purge سے پرانے kernels صاف کریں، پھر package reinstall کریں۔ پرانے kernel کے خلاف build کیے گئے out-of-tree modules load ہونا بند کر دیتے ہیں، اس لیے DKMS کے زیر انتظام ہر چیز کو دوبارہ build کرنا ہوگا، اور failed rebuild اس وقت تک خاموش رہتا ہے جب تک runtime پر module missing نہ ہو۔ اگر reboot کے بعد بھی uname -r پرانا version دکھائے، جبکہ dpkg -l نئی image کی فہرست دے، تو install میں کچھ خراب نہیں ہوا: bootloader default تبدیل نہیں ہوا۔