ویژگی‌های جدید هسته لینوکس 7.1 برای سرورها

تغییرات جدید در هسته لینوکس 7.1

هسته لینوکس 7.1 در تاریخ 14 ژوئن 2026، یعنی نه هفته پس از نسخه 7.0 منتشر شد. برای کاربر یک VPS (سرور مجازی)، تغییرات مهم در چهار حوزه دسته‌بندی می‌شوند: ذخیره‌سازی و سیستم‌های فایل، شبکه، مدیریت حافظه، و کنترل پردازش‌ها و کانتینرها. باقی تغییرات این نسخه عمدتاً مربوط به دسکتاپ و گرافیک است که یک سرور بدون رابط گرافیکی (headless) هرگز آن‌ها را بارگذاری نمی‌کند.

پاسخ دومی وجود دارد که باید ابتدا بدانید. نسخه 7.1 تقریباً به‌طور قطع روی سرور شما در حال اجرا نیست و تا مدت‌ها نیز نخواهد بود. وب‌سایت kernel.org نسخه 7.1 را به عنوان یک نسخه با پشتیبانی طولانی‌مدت (longterm) فهرست نکرده است. تا تاریخ 11 اوت 2026، شاخه‌های longterm شامل 6.18، 6.12، 6.6، 6.1، 5.15 و 5.10 هستند و تمام توزیع‌های اصلی سرور، بر پایه یکی از این نسخه‌ها یا نسخه‌ای که خودشان نگهداری می‌کنند، ساخته می‌شوند. مفاهیم «جدید در هسته» و «جدید روی سرور شما» با هم سال‌ها فاصله دارند، بنابراین این راهنما هر دو بخش را پوشش می‌دهد.

کدام هسته (kernel) هم‌اکنون روی VPS شما در حال اجراست

uname -r
uname -srm
systemd-detect-virt

دستور uname -r نسخهٔ هستهٔ در حال اجرا را چاپ می‌کند. در Ubuntu 24.04 خروجی چیزی شبیه به 6.8.0-79-generic است. بخشی که پیش از اولین خط تیره قرار دارد، نسخهٔ اصلی (upstream) است. هر آنچه پس از آن می‌آید، شمارهٔ ساخت اختصاصی توزیع شماست و هیچ ارتباطی با روند توسعهٔ اصلی ندارد. هستهٔ 6.8.0-79 در توزیع Canonical شامل هزاران اصلاحیه است که از نسخه‌های جدیدتر هسته به عقب بازگردانی (backport) شده‌اند؛ بنابراین این کد دقیقاً همان کدی نیست که Linus در مارس 2024 با برچسب 6.8 منتشر کرد. به همین دلیل است که عبارت «هستهٔ من قدیمی است» معنای کمتری نسبت به آنچه به نظر می‌رسد دارد. قابلیت‌ها قدیمی هستند، اما اصلاحیه‌های امنیتی معمولاً به‌روز هستند.

دستور systemd-detect-virt به شما می‌گوید که آیا اصلاً امکان تغییر هسته را دارید یا خیر. این دستور در یک ماشین مجازی کامل (Full VM) که در آن شما تصویر هستهٔ خود را بوت می‌کنید و ارتقا یک ارتقای واقعی محسوب می‌شود، مقدار kvm را چاپ می‌کند. در مجازی‌سازی کانتینری که هستهٔ میزبان به اشتراک گذاشته می‌شود، این دستور lxc یا openvz را نمایش می‌دهد. در پلن‌های کانتینری، uname -r هستهٔ ارائه‌دهندهٔ سرویس را نشان می‌دهد؛ نصب یک بستهٔ هسته در اینجا هیچ تغییری در آنچه بوت می‌کنید ایجاد نمی‌کند و هیچ قابلیتی از آن نسخه برای شما در دسترس نخواهد بود مگر اینکه ارائه‌دهنده، میزبان را با هسته‌ای جدیدتر ریبوت کند. پیش از برنامه‌ریزی برای هرگونه تغییر در هسته، این بررسی را انجام دهید.

[
  {
    "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 پلتفرم است و هیچ‌کدام از آن‌ها نسخهٔ 7.1 را بوت نمی‌کنند. جدیدترین آن‌ها Ubuntu 26.04 LTS (7.0) است که 1 نسخه از جریان اصلی عقب‌تر است. قدیمی‌ترین نسخه‌ای که همچنان پشتیبانی می‌شود، 26 نسخه عقب‌تر است. هستهٔ پیش‌فرض GA در Ubuntu 24.04 به میزان 13 نسخه عقب‌تر است و Debian 13 و RHEL 10 با تکیه بر شاخهٔ بلندمدت 6.12، به میزان 9 نسخه عقب‌تر قرار دارند. شمارش نسخه‌ها معیاری تقریبی است، زیرا تمام مواردی را که توزیع‌ها به عقب بازگردانی می‌کنند نادیده می‌گیرد، اما ابعاد این شکاف را نشان می‌دهد. اگر در حال سبک‌سنگین کردن انتخاب یکی از این موارد برای اجرا هستید، موازنه بین نسخه‌های LTS و نسخه‌های میان‌مدت در سرور تصمیمی است که زیربنای این اعداد قرار دارد.

ذخیره‌سازی و سیستم‌های فایل در 7.1

نسخه 7.1 قابلیت تولید و تایید T10 PI (اطلاعات حفاظتی) را در داخل سیستم فایل اضافه کرده است؛ پیش از این، این قابلیت تنها در لایه بلاک در دسترس بود. همچنین پشتیبانی انعطاف‌پذیر از تراز T10 نیز افزوده شده است. T10 PI شامل بایت‌های اضافی متصل به هر بلاک است که یک checksum و یک تگ برای شناسایی بلاک مربوطه را در خود نگه می‌دارد. به این ترتیب، اگر نوشتن داده به اشتباه انجام شود یا ناقص بماند، به جای بازگرداندن داده‌های نادرست به عنوان داده سالم، شناسایی می‌شود. نکته مهم برای کاربران VPS، سخت‌افزار است. متادیتای یکپارچگی باید توسط دستگاه ارائه شود، اما دیسک‌های مجازی معمولاً چنین قابلیتی ندارند.

ls /sys/block/vda/integrity/

در اکثر دیسک‌های VPS، این دستور مقدار No such file or directory را برمی‌گرداند، زیرا لایه بلاک تنها زمانی دایرکتوری integrity را ایجاد می‌کند که دستگاه از پشتیبانی یکپارچگی (integrity support) ثبت‌نام کرده باشد. این خطا در اینجا یک پاسخ عادی است و به معنای نقص فنی نیست. اگر پیش از مطالعه بیشتر درباره ویژگی‌های ذخیره‌سازی می‌خواهید بدانید دیسک شما واقعاً چیست، ابتدا بررسی اینکه آیا دیسک VPS واقعاً NVMe است را مطالعه کنید و شکاف بین NVMe و SATA SSD در VPS توضیح می‌دهد که چرا این پاسخ، اعداد و ارقام شما را تغییر می‌دهد.

در Btrfs، مشکل تقویت copy-on-write تحت فشار حافظه برطرف شده است و تغییری اعمال شده که پاک‌سازی اولین extent در یک محدوده ردیابی‌شده را سرعت می‌بخشد؛ این تغییر در نمونه کاری ذکر شده در merge، منجر به افزایش 10 درصدی throughput شده است. عملیات shutdown در این سیستم فایل دیگر به عنوان آزمایشی (experimental) علامت‌گذاری نمی‌شود. XFS عملیات zero range flushing و lookup را از طریق iomap بهبود داده و یک write pointer به هندسه گروه real-time اضافه کرده است که زیربنایی برای دستگاه‌های zoned محسوب می‌شود. NTFS در این نسخه کاملاً بازنویسی شده و دارای پشتیبانی کامل از نوشتن و تبدیل iomap است؛ این موضوع در صورتی که بخواهید یک image دیسک از ماشین ویندوزی را روی سرور خود mount کنید، اهمیت دارد.

موارد کوچک‌تر در حوزه ذخیره‌سازی که دانستن آن‌ها مفید است: ublk (درایور بلاک فضای کاربر) به قابلیت zero-copy I/O مجهز شد؛ io_uring دستورات SCSI passthrough را دریافت کرد؛ پشتیبانی از درایوهای خود-رمزنگار SED-OPAL دستور STACK_RESET و حالت single user گسترش‌یافته را اضافه کرد؛ یک درایور کاراکتری جدید fs-dax برای دستگاه‌های با دسترسی مستقیم (direct-access) ایجاد شد؛ و VFS مقدار inode->i_ino را از unsigned long به u64 افزایش داد که سقف شماره inode را در بیلد‌های 32 بیتی حذف می‌کند. در بخش سیستم‌های فایل شبکه‌ای، سرور NFS داخل هسته اکنون می‌تواند handleهای فایل خود را از طریق گزینه mount sign_fh امضا کند و کلاینت CIFS نیز قابلیت O_TMPFILE را فرا گرفته است.

شبکه: اجاره صف (queue leasing) و مزایای آن برای کانتینرها

تغییر اصلی در بخش شبکه، قابلیت اجاره صف سخت‌افزاری است. یک netdev مجازی اکنون می‌تواند صفی را اجاره کند که به یک صف واقعی روی یک netdev فیزیکی متصل است و به عنوان پروکسی برای آن عمل کند. هدف از این قابلیت، کانتینرها هستند. تا پیش از این، کانتینری که به AF_XDP (خانواده آدرس مسیر داده سریع، نوع سوکتی که بسته‌های خام را بدون کپی کردن در پشته شبکه به فضای کاربر تحویل می‌دهد) نیاز داشت، باید دسترسی تقریباً کاملی به کل دستگاه پیدا می‌کرد. با استفاده از صف اجاره‌ای، کانتینر یک صف سخت‌افزاری دریافت می‌کند، AF_XDP و ارائه‌دهندگان حافظه را با سرعت بومی اجرا می‌کند و میزبان نیز بقیه ظرفیت NIC را حفظ می‌کند. این قابلیت در کنار پشتیبانی AF_XDP در مسیر zero-copy مربوط به io_uring قرار می‌گیرد.

در بخش معمولی، سوکت‌ها در sockfs اکنون ویژگی‌های توسعه‌یافته user.* را می‌پذیرند. یک سوکت AF_UNIX مبتنی بر مسیر، پیش‌تر پشتیبانی xattr را از سیستم‌فایل زیرین خود به ارث می‌برد، اما سوکتی که فقط در sockfs وجود داشت، فاقد این قابلیت بود. اکنون یک پردازش می‌تواند به یک سوکت برچسب بزند و یک برنامه eBPF می‌تواند بر اساس آن برچسب، فیلترینگ انجام دهد.

دو مورد حذف شده‌اند. UDP-Lite به دلیل عدم وجود کاربر، حذف شده است. IPv6 دیگر نمی‌تواند به عنوان یک ماژول قابل بارگذاری (loadable module) ساخته شود: اگر به IPv6 نیاز دارید، باید آن را در هسته کامپایل کنید. مورد دوم در هیچ توزیع هسته‌ای قابل مشاهده نیست، زیرا توزیع‌های رایج سرور، IPv6 را از قبل در هسته کامپایل می‌کنند.

مدیریت حافظه: جدول swap تکمیل شد

بازنگری swap به فاز سوم خود رسیده است و این فاز، نقشه swap ایستا (static swap map) را حذف می‌کند. شمارنده swap اکنون مستقیماً در جدول swap قرار دارد. صرفه‌جویی گزارش‌شده حدود 30 درصد از متادیتای ایستا swap است؛ این حافظه‌ای است که هسته (kernel) متناسب با اندازه دستگاه swap شما اشغال می‌کند، صرف‌نظر از اینکه چیزی در آن swap شده باشد یا خیر. در مقادیر مطلق، این مقدار در فایل‌های swap کوچک ناچیز است و با افزایش حجم swap پیکربندی‌شده، بیشتر می‌شود.

الگوریتم MGLRU (الگوریتم بازپس‌گیری صفحه با نسل‌های چندگانه که الگوریتم جدیدتری است) اکنون می‌تواند پرچم young را در صفحات به‌صورت دسته‌ای (batch) بررسی کند، نه یک صفحه در هر لحظه. رقمی که همراه با این تغییر منتشر شده، نشان‌دهنده بیش از 60 درصد بهبود در یک سرور 32 هسته‌ای Arm64 است. دسته‌بندی (batching) بیشترین بازدهی را در جایی دارد که هزینه به ازای هر صفحه بالاترین حد است، به همین دلیل این عدد از یک ماشین بزرگ Arm به دست آمده است. اگر شما از یک VPS با معماری Arm به جای x86 استفاده می‌کنید، این تغییری در نسخه 7.1 است که بیشترین احتمال مشاهده در اندازه‌گیری‌های شخصی شما را دارد، هرچند این مقیاس در سیستم‌های دو یا چهار هسته‌ای به این اندازه نخواهد بود.

همچنین در این نسخه: انتقال از cgroupهای حافظه در حال حذف (dying) حذف شده است، اسکن‌های khugepaged با مصرف CPU کمتری انجام می‌شوند و maple tree بازسازی بزرگی در بخش مدیریت گره‌های بزرگ (big node) داشته است. هیچ‌کدام از این موارد توسط شما قابل پیکربندی نیستند. این‌ها تغییراتی هستند که تأثیر آن‌ها را به‌صورت کاهش جزئی در system time مشاهده خواهید کرد.

زمان‌بندها: زیر-زمان‌بندهای sched_ext و فعال‌سازی پیش‌فرض FRED

قابلیت sched_ext، کلاس زمان‌بند قابل‌توسعه‌ای که به شما اجازه می‌دهد یک زمان‌بند CPU را به صورت برنامه BPF بنویسید و در زمان اجرا بارگذاری کنید، در نسخه 6.12 معرفی شد. نسخه 7.1 ساختار اصلی برای زیر-زمان‌بندها را اضافه می‌کند تا یک گروه کنترلی (control group) در نهایت بتواند تحت زمان‌بند اختصاصی خود اجرا شود. این جمله را با دقت بخوانید. پیاده‌سازی این قابلیت در 7.1 کامل نیست و به‌ویژه مسیر enqueue در آن وجود ندارد؛ بنابراین این مورد فعلاً زیرساختی برای نسخه‌های آینده است و چیزی نیست که بتوانید همین امروز آن را فعال کنید.

قابلیت Intel FRED (تحویل منعطف بازگشت و رویداد) اکنون به‌طور پیش‌فرض روی سخت‌افزارهایی که از آن پشتیبانی می‌کنند، فعال است. FRED مسیر قدیمی تحویل رویداد x86 را با مسیری بهینه‌تر جایگزین می‌کند و از نسخه 6.9 با استفاده از آرگومان بوت fred=on در هسته وجود داشته است. فعال‌سازی پیش‌فرض آن نشان‌دهنده این است که سخت‌افزارهای موجود در بازار به اندازه کافی تست شده‌اند. اندازه‌گیری‌های منتشرشده تاکنون، که در محدوده 4% تا 7% برای بارهای کاری سنگین I/O هستند، حاصل تست‌های Phoronix روی تراشه‌های کلاینت است؛ بنابراین تا زمانی که بار کاری خود را اندازه‌گیری نکرده‌اید، روی بهبود عملکرد آن در سرور حساب نکنید.

اجرای پروکسی (Proxy execution) قابلیت مهاجرت اهداکننده (donor migration) را برای تقویت مالک قفل راه دور به دست آورده است، EEVDF اصلاحاتی در زمینه تأخیر منفی دریافت کرده و هسته زمان‌سنج با دقت بالا (high-resolution timer core) به‌طور اساسی بازنویسی شده است. این‌ها تغییراتی در کیفیت تأخیر هستند که هیچ فایل پیکربندی آن‌ها را در معرض دید قرار نمی‌دهد.

کنترل‌های جدید پردازش و کانتینر در clone3()

سه فلگ به clone3() اضافه شده است که هر کدام شکافی را که سرپرست‌ها (supervisors) سال‌ها به‌صورت دستی برای آن راهکار می‌ساختند، پر می‌کند. فلگ CLONE_AUTOREAP باعث می‌شود فرزند پس از خروج، خود را پاکسازی (reap) کند؛ بنابراین هرگز به یک زامبی تبدیل نمی‌شود که منتظر والدی باشد که ممکن است هرگز wait() را فراخوانی نکند. فلگ CLONE_NNP ویژگی no_new_privs را در زمان ایجاد روی فرزند تنظیم می‌کند که فاصلهٔ زمانی بین clone و تنظیم دستی این فلگ توسط خودِ فرزند را از بین می‌برد. فلگ CLONE_PIDFD_AUTOKILL طول عمر فرزند را به pidfd بازگردانده‌شده به والد گره می‌زند: با بستن pidfd، فرزند کشته می‌شود؛ بنابراین سرپرستی که از بین می‌رود، نمی‌تواند پردازش‌های یتیم (orphans) را در حال اجرا باقی بگذارد.

فضاهای نام mount نیز همین وضعیت را پیدا کرده‌اند. فلگ CLONE_EMPTY_MNTNS برای clone3() و فلگ UNSHARE_EMPTY_MNTNS برای unshare()، یک فضای نام mount خالی ایجاد می‌کنند، به‌جای آنکه مانند روال معمول، کپی کاملی از mountهای والد ایجاد شود که runtime مجبور باشد بعداً آن‌ها را unmount کند. فلگ FSMOUNT_NAMESPACE به fsmount() اجازه می‌دهد یک سیستم فایل را مستقیماً در یک فضای نام جدید قرار دهد. runtimeهای کانتینر یک دهه است که این کار را به‌صورت دستی انجام می‌دهند، بنابراین انجام آن در یک فراخوانی واحد به این معناست که runtime دیگر کار خود را از یک فضای نام پر از mountهای میزبان شروع نمی‌کند.

در بخش مجازی‌سازی، guest_memfd اکنون از userfaultfd پشتیبانی می‌کند، بنابراین یک hypervisor می‌تواند خطاهای صفحه (page faults) مهمان را از فضای کاربری مدیریت کند. KVM محافظت‌شده روی Arm از حافظهٔ ناشناس (anonymous memory) پشتیبانی می‌کند که در خودِ merge، هنوز برای محیط عملیاتی (production) آماده توصیف نشده است.

هسته 7.1 چه زمانی به سرور شما می‌رسد

Fedora هم‌اکنون آن را در اختیار دارد. مخزن به‌روزرسانی Fedora 44 در طول ماه‌های ژوئیه و اوت 2026 به سری 7.1 منتقل شد، زیرا Fedora هسته خود را در طول چرخه حیات هر نسخه، بر پایه خطوط پایدار جدید بازسازی می‌کند. 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 دارای یک پشته فعال‌سازی سخت‌افزار (HWE) است که هسته جدیدتر را از نسخه‌های بعدی Ubuntu به درون LTS می‌کشد؛ این پشته تا زمان انتشار نسخه نقطه‌ای 24.04.4 روی نسخه 6.17 قرار داشت و طبق برنامه قرار است در 27 اوت 2026 با انتشار 24.04.5 به نسخه 7.0 منتقل شود. یک نسخه نقطه‌ای (point release)، نسخه جدیدی از Ubuntu نیست، بلکه همان 24.04 است که تمام به‌روزرسانی‌های منتشر شده تا آن زمان در رسانه نصب جدید گنجانده شده‌اند، بنابراین آنچه 24.04.5 در سروری که قبلاً پچ کرده‌اید تغییر می‌دهد فقط خط هسته HWE است و تغییرات دیگری بسیار اندک هستند.

این بخشی است که افراد در آن دچار اشتباه می‌شوند. پشته HWE به هر هسته‌ای که جدیدترین نسخه میان‌دوره‌ای (interim release) حمل می‌کند می‌پرد، بنابراین ممکن است یک خط بالادستی (upstream) را کاملاً نادیده بگیرد. نسخه 7.0 در یک Ubuntu LTS موجود است. نسخه 7.1 ممکن است هرگز پایه یک نسخه LTS نباشد، زیرا نسخه میان‌دوره‌ای پس از آن، خط هسته جدیدتری را حمل خواهد کرد. آنچه از 7.1 به LTS شما می‌رسد، اصلاحاتی است که به خط هسته‌ای که روی آن هستید backport شده‌اند. ویژگی‌ها عمدتاً در همان نسخه قبلی باقی می‌مانند.

اگر واقعاً به هسته جدیدتر روی یک سرور پایدار نیاز دارید، مسیرهای پشتیبانی‌شده محدود هستند.

# 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 تمام ایمیج‌های هسته نصب‌شده را نمایش می‌دهد. اگر uname -r نسخه قدیمی را نشان می‌دهد در حالی که dpkg -l نسخه جدید را لیست می‌کند، یعنی بسته نصب شده اما پیش‌فرض بوت‌لودر تغییر نکرده است: ورودی‌های منوی GRUB را بررسی کنید. وجود /var/run/reboot-required به این معنی است که یک بسته، هسته را ارتقا داده اما از آن زمان سیستم راه‌اندازی مجدد نشده است؛ این رایج‌ترین دلیلی است که یک سرور پچ‌شده همچنان کد آسیب‌پذیر را اجرا می‌کند.

آیا باید نسخه 7.1 را روی یک VPS عملیاتی دنبال کرد؟

خیر، و دلیل آن صرفاً احتیاط نیست. هسته (kernel) توزیع‌شده، بخشی از یک قرارداد پشتیبانی است. شرکت‌هایی مانند Canonical، Red Hat، SUSE و Debian، اصلاحات امنیتی را به نسخه ثابت (frozen) خود backport می‌کنند و آن‌ها را با فضای کاربری (userspace) که همراه آن عرضه می‌کنند، تست می‌نمایند. استفاده از یک هسته mainline از مخازن شخص ثالث یا ساخت دستی آن، ویژگی‌های جدیدی به شما می‌دهد اما این پشتیبانی را از بین می‌برد، زیرا هیچ‌کس اصلاحات امنیتی را برای نسخه سفارشی شما backport نمی‌کند. در این حالت، شما خودتان مسئول نگهداری هسته می‌شوید.

استثنائات واقعی اما محدود هستند: سخت‌افزاری که هسته قدیمی‌تر قادر به شناسایی آن نیست، یا تغییر در عملکرد که آن را روی workload خود اندازه‌گیری کرده‌اید و آن‌قدر برایتان حیاتی است که عواقب آن را بپذیرید. در یک VPS، مورد اول تقریباً هرگز صدق نمی‌کند، زیرا سخت‌افزاری که با آن سروکار دارید مجازی است. برای سایر موارد، هسته توزیع‌شده را به‌روز نگه دارید و هر زمان که درخواست کرد، سیستم را reboot کنید. اگر ارتقای توزیع در لیست کارهای شما قرار دارد، مهاجرت از Ubuntu 24.04 به 26.04 شما را در یک مرحله از نسخه 6.8 به 7.0 می‌برد که جهش بزرگ‌تری نسبت به هر بسته هسته تکی است.

FAQ

چگونه بفهمم VPS من از چه نسخه هسته لینوکس استفاده می‌کند؟

دستور uname -r را اجرا کنید. این دستور خروجی مشابه 6.8.0-79-generic چاپ می‌کند. عددی که پیش از اولین خط تیره قرار دارد، نسخه اصلی (upstream) است که توزیع شما بر اساس آن ساخته شده و هر چه پس از آن می‌آید، شماره ساخت اختصاصی توزیع است که شامل وصله‌های امنیتی (backported fixes) می‌شود. سپس دستور systemd-detect-virt را اجرا کنید. اگر خروجی lxc یا openvz باشد، شما از مجازی‌سازی کانتینری استفاده می‌کنید، هسته میزبان (host) را به اشتراک می‌گذارید و امکان تغییر آن را ندارید. اگر خروجی kvm باشد، شما هسته اختصاصی خود را بوت می‌کنید و مسئولیت ارتقای آن با شماست.

آیا لینوکس 7.1 یک هسته با پشتیبانی طولانی‌مدت (LTS) است؟

خیر. تا تاریخ 11 August 2026، نسخه‌های با پشتیبانی طولانی‌مدت که در kernel.org فهرست شده‌اند عبارتند از 6.18، 6.12، 6.6، 6.1، 5.15 و 5.10، و 7.1 در میان آن‌ها نیست. این یک نسخه پایدار معمولی است و خط پشتیبانی آن بلافاصله پس از انتشار نسخه اصلی بعدی متوقف می‌شود. اگر به هسته‌ای نیاز دارید که سال‌ها وصله امنیتی دریافت کرده و در آینده نیز دریافت خواهد کرد، همان هسته‌ای که توزیع شما به‌صورت پیش‌فرض ارائه می‌دهد، مناسب‌ترین گزینه است.

اوبونتو یا دبیان چه زمانی هسته 7.1 را عرضه می‌کنند؟

احتمالاً هرگز به عنوان نسخه پیش‌فرض. دبیان 13 در طول چرخه عمر خود روی نسخه 6.12 باقی می‌ماند و RHEL 10 نیز از 6.12.0 استفاده می‌کند. اوبونتو 26.04 LTS با هسته 7.0 عرضه شد و پشته فعال‌سازی سخت‌افزار (HWE) اوبونتو به هر هسته‌ای که در جدیدترین نسخه میان‌دوره‌ای (interim release) باشد ارتقا می‌یابد، بنابراین ممکن است یک نسخه اصلی را کاملاً نادیده بگیرد. اوبونتو 24.04 LTS طبق برنامه قرار است هسته HWE خود را در نسخه 24.04.5 در تاریخ 27 August 2026 به 7.0 ارتقا دهد. وصله‌های نسخه 7.1 به صورت backport به نسخه‌های قدیمی‌تر اضافه می‌شوند، اما ویژگی‌های جدید معمولاً به آن‌ها اضافه نخواهند شد.

چه چیزی در لینوکس 7.1 برای یک سرور مجازی (VPS) اهمیت دارد؟

چهار مورد. قابلیت Hardware queue leasing به یک کانتینر اجازه می‌دهد از یک صف واقعی کارت شبکه (NIC) برای AF_XDP با سرعت بومی استفاده کند. فاز سوم بازنگری swap، نقشه swap ایستا را حذف کرده و متادیتای هسته برای دستگاه swap شما را تا 30 درصد کاهش می‌دهد. MGLRU اکنون می‌تواند پرچم‌های page young را به صورت دسته‌ای بررسی کند که بیشترین بهبود آن در سرورهای Arm با هسته‌های پردازشی زیاد گزارش شده است. همچنین clone3() قابلیت‌های CLONE_AUTOREAP، CLONE_NNP و CLONE_PIDFD_AUTOKILL را دریافت کرده که نظارت بر پردازش‌های فرزند (child processes) را ایمن‌تر می‌کند. قابلیت حفاظت T10 در سطح فایل‌سیستم نیز اضافه شده است، اما دیسک‌های مجازی به‌ندرت متادیتای یکپارچگی مورد نیاز برای آن را در اختیار سیستم قرار می‌دهند.

آیا ارتقای هسته باعث خرابی VPS من می‌شود؟

خرابی‌های رایج هنگام بوت رخ می‌دهند. پر شدن /boot باعث می‌شود update-initramfs در حین نصب با خطای No space left on device مواجه شود و بسته به صورت ناقص پیکربندی شود: هسته‌های قدیمی را با sudo apt autoremove --purge پاک‌سازی کرده و سپس دوباره نصب کنید. ماژول‌های خارج از درخت (out-of-tree) که برای هسته قدیمی کامپایل شده‌اند، دیگر بارگذاری نمی‌شوند؛ بنابراین هر چیزی که توسط DKMS مدیریت می‌شود باید دوباره کامپایل شود و شکست در کامپایل مجدد تا زمانی که ماژول در زمان اجرا (runtime) غایب نباشد، مشخص نمی‌شود. اگر پس از ریبوت، uname -r همچنان نسخه قدیمی را نشان می‌دهد در حالی که dpkg -l تصویر جدید را فهرست کرده است، نصب مشکلی نداشته، بلکه تنظیمات بوت‌لودر (bootloader) به‌روز نشده است.