تغییرات مهم هسته لینوکس 7.1 برای سرورها

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

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

پاسخ دومی وجود دارد که باید ابتدا بدانید. نسخه 7.1 تقریباً به طور قطع روی سرور شما اجرا نمی‌شود و تا مدت‌ها نیز نخواهد شد. وب‌سایت kernel.org نسخه 7.1 را به عنوان یک نسخه با پشتیبانی طولانی‌مدت (longterm) فهرست نکرده است. تا تاریخ 11 اوت 2026، نسخه‌های با پشتیبانی طولانی‌مدت عبارتند از 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 نسخه از خط اصلی (upstream) عقب‌تر است. قدیمی‌ترین نسخه‌ای که همچنان پشتیبانی می‌شود، 26 نسخه عقب‌تر است. هستهٔ پیش‌فرض GA در Ubuntu 24.04 به میزان 13 نسخه عقب‌تر است و Debian 13 و RHEL 10 با تکیه بر خط پشتیبانی طولانی‌مدت 6.12، به میزان 9 نسخه عقب‌تر قرار دارند. شمارش نسخه‌ها معیاری تقریبی است، زیرا تمام مواردی را که توزیع‌ها به عقب منتقل (backport) می‌کنند نادیده می‌گیرد، اما نمایی از این شکاف را نشان می‌دهد. اگر در حال سبک‌سنگین کردن برای انتخاب یکی از این موارد هستید، موازنه بین نسخه‌های LTS و نسخه‌های موقت در سرور تصمیمی است که در پسِ این اعداد نهفته است.

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

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

ls /sys/block/vda/integrity/

در اکثر دیسک‌های VPS، این دستور مقدار No such file or directory را برمی‌گرداند، زیرا لایه بلاک تنها زمانی دایرکتوری integrity را ایجاد می‌کند که دستگاه از پشتیبانی یکپارچگی ثبت‌نام کرده باشد. این خطا در اینجا یک پاسخ عادی است، نه یک نقص فنی. اگر پیش از مطالعه بیشتر درباره ویژگی‌های ذخیره‌سازی می‌خواهید بدانید دیسک شما واقعاً چیست، ابتدا بررسی اینکه آیا دیسک 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 درون هسته اکنون می‌تواند file handleهای خود را از طریق گزینه mount sign_fh امضا کند و کلاینت CIFS نیز قابلیت O_TMPFILE را فرا گرفته است.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

فضاهای نام mount (mount namespaces) نیز با همین رویکرد بهبود یافته‌اند. فلگ 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 44 در طول ژوئیه و اوت 2026 به سری 7.1 منتقل شد، زیرا فدورا کرنل خود را در طول چرخهٔ حیات یک نسخه، به خطوط پایدار جدید منتقل می‌کند. Arch و openSUSE Tumbleweed نیز به همین دلیل آن را دارند. این‌ها ماشین‌هایی برای تست هستند، نه ماشین‌هایی برای اجرای سرویس‌های شما.

سایر توزیع‌ها منتظر می‌مانند و این انتظار بر اساس طراحی است. Debian 13 با نسخه 6.12 عرضه شد و در طول عمر آن نسخه روی 6.12 باقی می‌ماند، با این تفاوت که اصلاحات (fix) به آن backport می‌شوند. RHEL 10 با نسخه 6.12.0 عرضه شد و همین رویه را دنبال می‌کند. Ubuntu 26.04 LTS در آوریل 2026 با نسخه 7.0 عرضه شد. Ubuntu 24.04 LTS دارای یک stack فعال‌سازی سخت‌افزار (HWE) است که کرنل جدیدتر را از نسخه‌های بعدی اوبونتو به LTS می‌آورد؛ این stack تا زمان انتشار point release نسخه 24.04.4 روی 6.17 بود و طبق برنامه قرار است در 27 اوت 2026 با انتشار 24.04.5 به 7.0 منتقل شود.

این بخشی است که افراد در آن دچار اشتباه می‌شوند. یک HWE stack به هر کرنلی که جدیدترین نسخه interim حمل می‌کند می‌پرد، بنابراین می‌تواند یک خط upstream را به‌طور کامل نادیده بگیرد. 7.0 در یک Ubuntu LTS وجود دارد. 7.1 ممکن است هرگز پایه یک نسخه LTS نباشد، زیرا نسخه interim پس از آن، خط جدیدتری را حمل خواهد کرد. آنچه از 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

پس از reboot، بررسی کنید که واقعاً با چه چیزی بالا آمده‌اید:

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

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

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

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

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

FAQ

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

دستور uname -r را اجرا کنید. این دستور خروجی مشابه 6.8.0-79-generic چاپ می‌کند. عدد قبل از اولین خط تیره، نسخه اصلی (upstream) است که توزیع شما بر پایه آن ساخته شده و هر آنچه بعد از آن می‌آید، شماره ساخت اختصاصی توزیع است که شامل اصلاحات backport شده می‌شود. سپس دستور systemd-detect-virt را اجرا کنید. اگر خروجی lxc یا openvz باشد، شما از مجازی‌سازی کانتینری استفاده می‌کنید، هسته میزبان را به اشتراک می‌گذارید و امکان تغییر آن را ندارید. اگر خروجی 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) اوبونتو به هر هسته‌ای که جدیدترین نسخه میان‌دوره‌ای ارائه دهد جهش می‌کند، بنابراین ممکن است یک نسخه اصلی upstream را به‌طور کامل نادیده بگیرد. اوبونتو 24.04 LTS طبق برنامه قرار است هسته HWE خود را در نسخه 24.04.5 در تاریخ 27 August 2026 به 7.0 ارتقا دهد. اصلاحات نسخه 7.1 به صورت backport به نسخه‌های قدیمی‌تر منتقل می‌شوند، اما قابلیت‌های جدید معمولاً اضافه نخواهند شد.

چه چیزی در لینوکس 7.1 واقعاً برای یک سرور مجازی اهمیت دارد؟

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

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

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