ما الجديد في Linux kernel 7.1 للخوادم؟

ما الجديد في Linux kernel 7.1

صدر Linux kernel 7.1 في 14 June 2026، بعد تسعة أسابيع من الإصدار 7.0. بالنسبة إلى مستأجر VPS (خادم افتراضي خاص)، تتركز التغييرات المهمة في أربعة مجالات: التخزين وأنظمة الملفات، والشبكات، وإدارة الذاكرة، والتحكم في العمليات والحاويات. أما بقية الإصدار فتتعلق في معظمها بعمل سطح المكتب والرسوميات، وهي مكونات لا يحمّلها خادم يعمل دون واجهة رسومية.

هناك إجابة ثانية يجب أن تعرفها أولاً. من شبه المؤكد أن 7.1 لا يعمل على خادمك، ولن يعمل عليه لفترة طويلة. لا يدرج kernel.org الإصدار 7.1 ضمن إصدارات الدعم طويل الأمد. في 11 August 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. أما كل ما يأتي بعدها فهو رقم البناء الخاص بتوزيعتك، ولا يتتبع upstream إطلاقاً. تتضمن 6.8.0-79 من Canonical آلاف الإصلاحات المنقولة من نوى أحدث، لذلك فهي ليست الشيفرة التي وضع Linus لها الوسم 6.8 في مارس 2024. لهذا فإن قولك «نواتي قديمة» لا يعبّر عن الأمر كما يبدو. الميزات قديمة. أما إصلاحات الأمان فعادةً ليست كذلك.

يخبرك systemd-detect-virt بما إذا كان بإمكانك تغيير النواة أساساً. يطبع 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 بمقدار 9 إصدارات ضمن خط 6.12 طويل الدعم. يُعدّ عدّ الإصدارات مقياساً تقريبياً، لأنه يتجاهل كل ما تنقله التوزيعات من إصلاحات، لكنه يوضح شكل الفجوة. إذا كنت توازن بين هذه الخيارات لتحديد ما ستشغّله، فإن المفاضلة بين إصدار LTS والإصدار المرحلي على الخادم هي القرار الكامن وراء هذه الأرقام.

التخزين وأنظمة الملفات في 7.1

يضيف الإصدار 7.1 إمكانية إنشاء معلومات T10 PI (معلومات الحماية) والتحقق منها داخل نظام الملفات بدلاً من اقتصار ذلك على طبقة الكتل، إلى جانب دعم مرن لمحاذاة T10. تتكون T10 PI من بايتات إضافية مرفقة بكل كتلة، وتحتوي على مجموع تحقق ووسم يحدد الكتلة التي تنتمي إليها البيانات، وبذلك يجري اكتشاف الكتابة الموجّهة خطأً أو الكتابة غير المكتملة بدلاً من إعادتها على أنها بيانات سليمة. لكن العائق أمام مستخدم VPS هو العتاد. يجب أن تكشف وحدة التخزين عن بيانات التعريف الخاصة بالسلامة، بينما لا يكشف القرص الافتراضي ذلك عادةً.

ls /sys/block/vda/integrity/

في معظم أقراص VPS، يعيد ذلك No such file or directory، لأن طبقة الكتل لا تنشئ الدليل integrity إلا عندما يسجّل الجهاز دعمه للسلامة. هذا الخطأ هو النتيجة الطبيعية في هذه الحالة، وليس عطلاً. إذا أردت معرفة طبيعة قرصك فعلياً قبل التعمق في ميزات التخزين، فابدأ بـالتحقق مما إذا كان قرص VPS يستخدم NVMe فعلاً، ويوضح الفرق بين NVMe وقرص SATA SSD على VPS سبب تغيّر الأرقام الناتجة.

يحصل Btrfs على إصلاحات لتضخيم النسخ عند الكتابة تحت ضغط الذاكرة، إلى جانب تغيير يسرّع مسح الامتداد الأول في نطاق تتم متابعته. وقد أُبلغ عن زيادة في الإنتاجية بنسبة 10% في حمل العمل النموذجي الذي يذكره الدمج. ولم تعد عملية إيقاف التشغيل فيه موسومة بأنها تجريبية. يحسّن XFS تفريغ نطاقات التصفير والبحث عبر iomap، ويضيف مؤشراً للكتابة إلى هندسة مجموعات الوقت الفعلي، وهو ما يمهّد لدعم الأجهزة المقسّمة إلى مناطق. أما NTFS فأُعيدت كتابته بالكامل في هذا الإصدار، مع دعم كامل للكتابة وتحويل إلى iomap. وهذا مهم إذا احتجت يوماً إلى تركيب صورة قرص من جهاز Windows على خادمك.

ومن عناصر التخزين الأصغر التي تستحق المعرفة: حصل ublk، وهو مشغّل الكتل في مساحة المستخدم، على إدخال وإخراج من دون نسخ؛ وحصل io_uring على أوامر تمرير SCSI؛ وأضاف دعم الأقراص ذاتية التشفير SED-OPAL الأمر STACK_RESET ووضع المستخدم الواحد الموسّع؛ وأضيف مشغّل محارف جديد fs-dax للأجهزة ذات الوصول المباشر؛ ووسّعت VFS inode->i_ino من unsigned long إلى u64، ما يزيل الحد الأقصى لرقم inode في عمليات البناء على أنظمة 32-bit. وعلى مستوى أنظمة الملفات الشبكية، يستطيع خادم NFS داخل النواة الآن توقيع مقابض ملفاته عبر خيار التركيب sign_fh، كما تعلّم عميل CIFS O_TMPFILE.

الشبكات: تأجير قوائم الانتظار، وما يتيحه ذلك للحاوية

يتمثل التغيير الرئيسي في الشبكات في تأجير قوائم الانتظار العتادية. يمكن لـnetdev افتراضي الآن استئجار قائمة انتظار مرتبطة بقائمة انتظار فعلية في netdev فعلي، والعمل كوكيل لها. والهدف من ذلك هو دعم الحاويات. في السابق، كانت الحاوية التي تريد استخدام AF_XDP (وهو مسار بيانات سريع لعائلة العناوين، ونوع من المقابس يسلّم الحزم الخام إلى مساحة المستخدم من دون نسخها عبر مكدس الشبكة) تحتاج إلى الحصول على ما يقارب الجهاز بأكمله. أما مع قائمة انتظار مستأجرة، فتحصل الحاوية على قائمة انتظار عتادية واحدة، وتشغّل AF_XDP وموفّري الذاكرة بالسرعة الأصلية، بينما يحتفظ المضيف بباقي NIC. يأتي ذلك إلى جانب دعم AF_XDP في مسار النسخ الصفري ضمن io_uring.

في الجانب الاعتيادي، تقبل المقابس الموجودة في sockfs الآن السمات الموسعة user.*. كان مقبس AF_UNIX القائم على المسار يرث دعم xattr من نظام الملفات الموجود تحته، أما المقبس الموجود في sockfs فقط فلم يكن يملك هذا الدعم. يمكن للعملية الآن وضع تسمية على مقبس، ويمكن لبرنامج eBPF التصفية وفقاً لهذه التسمية.

إزالتان. أُزيل UDP-Lite بعد عدم العثور على مستخدمين له. لم يعد بالإمكان بناء IPv6 كوحدة قابلة للتحميل؛ فإذا أردت IPv6، فيجب تضمينه أثناء الترجمة. لا يظهر أثر الإزالة الثانية في نواة أي توزيعة، لأن توزيعات الخوادم الشائعة تبني IPv6 مضمّناً بالفعل.

إدارة الذاكرة: اكتمل جدول swap

تصل إعادة تصميم swap إلى مرحلتها الثالثة. تزيل هذه المرحلة خريطة swap الثابتة. أصبح عدد swap موجوداً مباشرةً في جدول swap. يبلغ الوفر المعلن نحو 30% من البيانات الوصفية الثابتة لـswap. وهذه ذاكرة يحتفظ بها kernel بما يتناسب مع حجم جهاز swap لديك، سواء استُخدمت مساحة swap أم لا. ويكون هذا الوفر صغيراً بالقيمة المطلقة في ملف swap صغير، ويزداد مع حجم swap الذي تهيّئه.

يمكن لـMGLRU (خوارزمية استرداد الصفحات الأحدث متعددة الأجيال) الآن فحص العلامة young في الصفحات على دفعات بدلاً من فحص صفحة واحدة في كل مرة. أظهر الرقم المنشور مع هذا التغيير تحسناً يتجاوز 60% على خادم Arm64 ذي 32 نواة. تكون المعالجة على دفعات أكثر فائدة عندما تكون تكلفة كل صفحة أعلى. لذلك جاء هذا الرقم من جهاز Arm كبير. إذا كنت تشغّل VPS على Arm بدلاً من x86، فهذا هو التغيير في 7.1 الأكثر احتمالاً للظهور في قياساتك، وإن لم يكن بهذا الحجم على جهاز يضم نواتين أو أربع نوى.

يتضمن هذا الإصدار أيضاً إيقاف عمليات النقل خارج مجموعات الذاكرة المحتضرة، وتقليل استهلاك CPU أثناء عمليات فحص khugepaged، وإعادة هيكلة كبيرة في maple tree لمعالجة العقد الكبيرة. لا تحتاج إلى تهيئة أي من هذه التغييرات. وستلاحظ أثرها على شكل انخفاض طفيف في وقت النظام.

المجدولات: المجدولات الفرعية لـsched_ext، وFRED مفعّل افتراضياً

وصل sched_ext، وهي فئة المجدول القابلة للتوسعة التي تتيح لك كتابة مجدول CPU باعتباره برنامج BPF وتحميله أثناء التشغيل، في الإصدار 6.12. يضيف الإصدار 7.1 البنية الأساسية للمجدولات الفرعية، بحيث يمكن لمجموعة تحكم أن تعمل لاحقاً باستخدام مجدول خاص بها. اقرأ هذه الجملة بعناية. لم يكتمل التنفيذ في الإصدار 7.1، وخصوصاً أن مسار enqueue مفقود، لذلك تمثل هذه التغييرات أساساً لإصدار لاحق، وليست ميزة يمكنك تفعيلها اليوم.

أصبح Intel FRED (الإرجاع المرن وتسليم الأحداث) مفعّلاً افتراضياً على الأجهزة التي تدعمه. يستبدل FRED مسار تسليم الأحداث القديم في x86 بمسار أبسط، وهو موجود في النواة منذ الإصدار 6.9 خلف وسيطة الإقلاع fred=on. ويعني تفعيله افتراضياً أن العتاد المطروح في الأسواق خضع لاختبارات كافية. أما القياسات المنشورة حتى الآن، والتي تتراوح بين 4% و7% في أحمال العمل الكثيفة باستخدام I/O، فتستند إلى اختبارات Phoronix على عتاد مخصص للأجهزة العميلة. لذلك لا تفترض تحقيق هذه النسبة على خادم قبل قياس حمل العمل لديك.

حصل التنفيذ بالوكالة على ترحيل المتبرع لتعزيز مالك قفل بعيد، وحصل EEVDF على إصلاحات مرتبطة بالتأخر السلبي، كما أُعيدت كتابة جوهر المؤقت عالي الدقة بدرجة كبيرة. هذه تغييرات تحسّن زمن الاستجابة، ولا تكشفها أي ملفات إعداد.

ضوابط جديدة للعمليات والحاويات في clone3()

أُضيفت ثلاث رايات إلى clone3()، وتعالج كل واحدة منها ثغرة ظل المشرفون يتجاوزونها يدوياً لسنوات. تجعل CLONE_AUTOREAP الابن يعيد جمع نفسه عند الخروج، لذلك لا يتحول إلى عملية زومبي تنتظر أباً قد لا يستدعي wait() مطلقاً. تضبط CLONE_NNP قيمة no_new_privs للابن وقت إنشائه، ما يغلق الفترة الفاصلة بين الاستنساخ وضبط الابن للراية بنفسه. تربط CLONE_PIDFD_AUTOKILL مدة حياة الابن بملف pidfd الذي أُعيد إلى الأب: عند إغلاق pidfd يُقتل الابن، ولذلك لا يستطيع المشرف الذي يتوقف عن العمل ترك عمليات يتيمة قيد التشغيل.

حصلت مساحات أسماء نقاط التحميل على المعالجة نفسها. تنشئ CLONE_EMPTY_MNTNS لـ clone3() وUNSHARE_EMPTY_MNTNS لـ unshare() مساحة أسماء لنقاط التحميل لا تحتوي على شيء، بدلاً من النسخ الكامل المعتاد لنقاط تحميل الأب، الذي يتعين على بيئة التشغيل بعد ذلك إلغاء تحميله. تتيح FSMOUNT_NAMESPACE لـ fsmount() وضع نظام ملفات مباشرةً داخل مساحة أسماء جديدة. ظلت بيئات تشغيل الحاويات تنفذ ذلك يدوياً طوال عقد، ولذلك فإن تنفيذه في استدعاء واحد يعني أن بيئة التشغيل لا تبدأ بعد الآن من مساحة أسماء ممتلئة بنقاط تحميل المضيف.

على جانب المحاكاة الافتراضية، يدعم guest_memfd الآن userfaultfd، لذلك يستطيع برنامج مراقب للآلة الافتراضية معالجة أخطاء صفحات الضيف من مساحة المستخدم. حصل KVM المحمي على Arm على دعم للذاكرة المجهولة، ويصف الدمج نفسه هذا الدعم بأنه غير جاهز للاستخدام الإنتاجي.

متى يصل kernel 7.1 إلى خادمك

يتوفر kernel 7.1 في Fedora بالفعل. انتقل مستودع تحديث Fedora 44 إلى سلسلة 7.1 خلال يوليو وأغسطس 2026، لأن Fedora تعيد بناء kernel على سلاسل مستقرة جديدة ضمن دورة الإصدار. ويتوفر أيضاً في Arch وopenSUSE Tumbleweed للسبب نفسه. هذه أنظمة مناسبة للاختبار، وليست لتشغيل خدماتك عليها.

أما بقية الأنظمة فتنتظر، وهذا الانتظار مقصود. صدر Debian 13 مع 6.12، ويبقى على 6.12 طوال فترة الإصدار، مع إدراج الإصلاحات فيه عبر backport. وصدر RHEL 10 مع 6.12.0 ويتبع النهج نفسه. صدر Ubuntu 26.04 LTS مع 7.0 في أبريل 2026. ويحتوي Ubuntu 24.04 LTS على hardware enablement stack، الذي يجلب kernel أحدث من إصدارات Ubuntu اللاحقة إلى إصدار LTS. ويستخدم هذا stack الإصدار 6.17 اعتباراً من الإصدار النقطي 24.04.4، ومن المقرر أن ينتقل إلى 7.0 مع 24.04.5 في 27 أغسطس 2026.

إليك النقطة التي يخطئ فيها كثيرون. ينتقل HWE stack إلى kernel الذي يحمله أحدث إصدار مؤقت، ولذلك قد يتجاوز سلسلة upstream كاملة. يوجد 7.0 في إصدار Ubuntu LTS. وقد لا يصبح 7.1 أساساً لأي إصدار LTS، لأن الإصدار المؤقت الذي يليه سيحمل سلسلة أحدث. وما يصل إلى إصدار LTS من 7.1 هو الإصلاحات التي تُدرج عبر backport في السلسلة المستخدمة لديك. أما الميزات فتبقى في الغالب خارجها.

إذا كنت تريد kernel أحدث على خادم مستقر، فالمسارات المدعومة محدودة.

# 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 الذي أقلعت به فعلياً:

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

يُفترض أن يعرض uname -r السلسلة الجديدة الآن، بينما يعرض dpkg -l جميع صور kernel التي لا تزال مثبتة. إذا عرض uname -r الإصدار القديم، في حين يسرد dpkg -l الإصدار الجديد، فهذا يعني أن الحزمة ثُبّتت، لكن الإعداد الافتراضي لمحمل الإقلاع لم يتغير؛ راجع إدخالات قائمة GRUB. يعني وجود /var/run/reboot-required أن حزمة حدّثت kernel ولم تُجرَ إعادة تشغيل منذ ذلك الحين، وهذا هو السبب الأكثر شيوعاً لاستمرار خادم مُرقّع في تنفيذ الشفرة المعرضة للثغرة.

هل ينبغي أن تسعى إلى الإصدار 7.1 على VPS مخصص للإنتاج

لا. والسبب ليس الحذر لمجرد الحذر. نواة التوزيعة هي عقد دعم. تعمل Canonical وRed Hat وSUSE وDebian على إدماج إصلاحات الأمان في خط الإصدارات الثابت الخاص بها، واختبارها مع برامج userspace التي تشحنها معه. تمنحك نواة mainline من أرشيف تابع لجهة خارجية أو نواة تبنيها يدوياً الميزات، لكنها تزيل عنك هذا العمل، لأن لا أحد يدمج الإصلاحات في بنيتك. وبذلك تصبح أنت المسؤول عن صيانة النواة.

الاستثناءات موجودة فعلاً، لكنها محدودة: عتاد لا تستطيع النواة الأقدم تشغيله، أو تغيير في الأداء قسته على عبء العمل الخاص بك وتريده بشدة تكفي لتحمل تبعاته. على VPS، ينطبق الاستثناء الأول تقريباً أبداً، لأن العتاد الذي تراه افتراضي. وفي جميع الحالات الأخرى، أبقِ نواة التوزيعة محدثة وأعد التشغيل عندما تطلب ذلك. إذا كانت ترقية التوزيعة مدرجة بالفعل في خطتك، فإن الانتقال من Ubuntu 24.04 إلى 26.04 ينقلك من 6.8 إلى 7.0 في خطوة واحدة، وهو انتقال أكبر من أي حزمة نواة منفردة يمكن أن توفرها لك.

FAQ

كيف أتحقق من نواة Linux التي يشغّلها VPS لدي؟

نفّذ uname -r. سيطبع شيئاً مثل 6.8.0-79-generic. الرقم الذي يسبق الشرطة الأولى هو سلسلة النواة الأصلية التي يبني توزيعك عليها، وكل ما يأتي بعدها هو رقم البناء الخاص بالتوزيع، ويتضمن إصلاحات منقولة إلى إصدارات أقدم. ثم نفّذ systemd-detect-virt. إذا طبع lxc أو openvz، فأنت تستخدم المحاكاة الافتراضية عبر الحاويات، وتشترك في نواة المضيف، ولا يمكنك تغييرها. وإذا طبع kvm، فأنت تقلع من صورة نواة خاصة بك، وتتولى أنت إجراء ترقياتها.

هل Linux 7.1 نواة ذات دعم طويل الأمد؟

لا. اعتباراً من 11 August 2026، سلاسل الدعم طويل الأمد المدرجة على kernel.org هي 6.18 و6.12 و6.6 و6.1 و5.15 و5.10، ولا تُعد 7.1 من بينها. هذا إصدار مستقر عادي، وتنتهي صيانة سلسلته المستقرة بعد وقت قصير من ظهور الإصدار الرئيسي التالي. إذا كنت تريد نواة تتوفر لها إصلاحات لسنوات مضت ولسنوات قادمة، فهذا هو حال نواة توزيعك الحالية.

متى ستُصدر Ubuntu أو Debian النواة 7.1؟

على الأرجح لن تُصدرها كنواة افتراضية. سيبقى Debian 13 على 6.12 طوال دورة الإصدار، وسيبقى RHEL 10 على 6.12.0. أصدرت Ubuntu 26.04 LTS النواة 7.0، وتنتقل حزمة تمكين العتاد في Ubuntu إلى النواة التي يحملها أحدث إصدار مرحلي، ولذلك قد تتجاوز سلسلة أصلية كاملة. ومن المقرر أن تنقل Ubuntu 24.04 LTS نواة HWE إلى 7.0 مع الإصدار النقطي 24.04.5 في 27 August 2026. ستصل إصلاحات 7.1 إليك على شكل backports إلى سلسلة أقدم. أما الميزات فعادةً لن تصل.

ما الذي يهم فعلياً في Linux 7.1 على خادم خاص افتراضي؟

هناك أربعة عناصر. يتيح تأجير قوائم انتظار العتاد للحاوية استخدام قائمة انتظار واحدة فعلية من بطاقة الشبكة NIC مع AF_XDP بالسرعة الأصلية. وتزيل المرحلة الثالثة من إعادة تصميم swap خريطة swap الثابتة، وتقلل البيانات الوصفية التي تحتفظ بها النواة لجهاز swap بنسبة معلنة تبلغ 30%. ويمكن لـMGLRU التحقق من أعلام حداثة الصفحات على دفعات، مع تحقيق أكبر مكسب منشور على خادم Arm متعدد الأنوية. كما حصل clone3() على CLONE_AUTOREAP وCLONE_NNP وCLONE_PIDFD_AUTOKILL، ما يجعل الإشراف على العمليات الابنة أكثر أماناً. ووصلت أيضاً معلومات الحماية T10 على مستوى نظام الملفات، لكن القرص الافتراضي نادراً ما يتيح بيانات التكامل اللازمة لها.

هل ستؤدي ترقية النواة إلى تعطيل VPS لدي؟

تحدث حالات الفشل الشائعة أثناء الإقلاع. يؤدي امتلاء /boot إلى فشل update-initramfs مع No space left on device أثناء التثبيت، فتظل الحزمة مهيّأة جزئياً: احذف النوى القديمة باستخدام sudo apt autoremove --purge، ثم أعد التثبيت. وتتوقف الوحدات الخارجية التي بُنيت للنواة القديمة عن التحميل، لذلك يجب إعادة بناء كل ما يديره DKMS، وقد يظل فشل إعادة البناء صامتاً إلى أن تصبح الوحدة مفقودة أثناء التشغيل. وإذا ظل uname -r يعرض الإصدار القديم بعد إعادة التشغيل بينما يسرد dpkg -l الصورة الجديدة، فلم يحدث خلل في التثبيت: لم يتغير الإعداد الافتراضي لمحمل الإقلاع.