מה חדש ב-Linux kernel 7.1 ואיך בודקים גרסה בשרת

מה חדש ב-Linux kernel 7.1

הגרסה Linux kernel 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" ו-"חדש בשרת שלך" מופרדים על ידי שנים, ולכן מדריך זה מכסה את שני הצדדים.

איזה Kernel מריץ ה-VPS שלך כרגע

uname -r
uname -srm
systemd-detect-virt

הפקודה uname -r מדפיסה את גרסת ה-Kernel הפעילה. ב-Ubuntu 24.04 הפלט נראה כך: 6.8.0-79-generic. החלק שלפני המקף הראשון הוא קו הפיתוח המקורי (upstream). כל מה שאחריו הוא מספר ה-build של ההפצה, והוא אינו עוקב אחר ה-upstream. ה-Kernel של Canonical, המצוין ב-6.8.0-79, כולל אלפי תיקונים שבוצעו להם backport מגרסאות Kernel מאוחרות יותר, ולכן הוא אינו הקוד ש-Linus תייג כ-6.8 במרץ 2024. זו הסיבה שהטענה "ה-Kernel שלי ישן" אינה מעידה על המצב כפי שהיא נשמעת. התכונות אכן ישנות, אך תיקוני האבטחה בדרך כלל אינם כאלה.

הפקודה systemd-detect-virt מציגה אם באפשרותך לשנות את ה-Kernel כלל. היא מדפיסה kvm במכונה וירטואלית מלאה, שבה אתה מאתחל את קובץ ה-Kernel שלך ושדרוג הוא שדרוג אמיתי. היא מדפיסה lxc או openvz בווירטואליזציה מבוססת מכולות (containers), שבה ה-Kernel של המארח משותף. בתוכנית מבוססת מכולות, uname -r מציג את ה-Kernel של ספק השירות; התקנת חבילת Kernel לא תשנה דבר שניתן לאתחל, ואף תכונה בגרסה זו לא תהיה זמינה עבורך עד שהספק יאתחל את המארח לגרסת Kernel חדשה יותר. בצע בדיקה זו לפני שאתה מתכנן עבודה כלשהי על ה-Kernel.

[
  {
    "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 גרסאות מאחור. ה-Kernel המוגדר כברירת מחדל (GA) ב-Ubuntu 24.04 נמצא 13 גרסאות מאחור, בעוד ש-Debian 13 ו-RHEL 10 נמצאות 9 גרסאות מאחור על קו ה-longterm של 6.12. ספירת גרסאות היא מדד גס, כיוון שהיא מתעלמת מכל ה-backports שההפצות מבצעות, אך היא מציגה את היקף הפער. אם אתה שוקל איזו מהן להריץ, הפשרה בין גרסאות 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 רק כאשר ההתקן רושם תמיכה ב-integrity. שגיאה זו היא התשובה התקינה במקרה זה, ולא תקלה. אם ברצונכם לדעת מהו הדיסק שלכם באמת לפני שתמשיכו לקרוא על תכונות אחסון, בדיקה האם דיסק ה-VPS הוא אכן NVMe היא הצעד הראשון, ו-הפער בין NVMe ל-SATA SSD ב-VPS מסביר מדוע התשובה משנה את התוצאות שלכם.

מערכת Btrfs קיבלה תיקונים להגברת ה-copy-on-write תחת עומס זיכרון, לצד שינוי המאיץ את ניקוי ה-extent הראשון בטווח נתון, מה שהוביל לשיפור של 10% בתפוקה בעומסי עבודה לדוגמה. פעולת ה-shutdown שלה אינה מסומנת עוד כניסיונית. XFS משפרת את ה-zero range flushing ואת החיפוש דרך iomap, ומוסיפה מצביע כתיבה לגיאומטריית קבוצות בזמן אמת, מה שמהווה תשתית להתקנים מבוססי אזורים (zoned devices). מערכת NTFS עברה שכתוב מלא בגרסה זו, עם תמיכה מלאה בכתיבה והמרה ל-iomap, דבר בעל חשיבות אם תצטרכו לעגן (mount) קובץ image של דיסק ממכונת Windows על השרת שלכם.

פריטי אחסון קטנים שכדאי להכיר: ublk, מנהל ההתקן (driver) של הבלוקים במרחב המשתמש, קיבל תמיכה ב-zero-copy I/O; ה-io_uring קיבל פקודות SCSI passthrough; התמיכה בכוננים מוצפנים עצמית מסוג SED-OPAL קיבלה את הפקודה STACK_RESET ומצב משתמש יחיד מורחב; קיים מנהל התקן תו חדש מסוג fs-dax עבור התקני גישה ישירה; וה-VFS הרחיב את inode->i_ino מ-unsigned long ל-u64, מה שמסיר את תקרת מספרי ה-inode בגרסאות 32-bit. בצד מערכות הקבצים ברשת, שרת ה-NFS בתוך ה-kernel יכול כעת לחתום על ה-file handles שלו דרך אפשרות ה-mount‏ sign_fh, ולקוח ה-CIFS למד את O_TMPFILE.

רישות: הקצאת תורים (queue leasing), והתועלת למכולות

השינוי המרכזי ברישות הוא הקצאת תורים ברמת החומרה. כעת, התקן רשת וירטואלי (virtual netdev) יכול לשכור תור המקושר לתור פיזי בהתקן רשת פיזי, ולשמש עבורו כ־proxy. המטרה היא תמיכה במכולות. עד כה, מכולה שביקשה להשתמש ב-AF_XDP (סוג socket המעביר חבילות גולמיות למרחב המשתמש ללא העתקה דרך מחסנית הרשת) נדרשה לקבל גישה כמעט מלאה להתקן כולו. באמצעות תור מושכר, המכולה מקבלת תור חומרה יחיד, מריצה AF_XDP וספקי זיכרון במהירות טבעית, בעוד המארח שומר על שאר ה-NIC. יכולת זו מתווספת לתמיכה ב-AF_XDP בנתיב ה-zero-copy של io_uring.

בצד הסטנדרטי, sockets ב-sockfs מקבלים כעת user.* extended attributes. בעבר, socket מסוג AF_UNIX מבוסס נתיב ירש תמיכה ב-xattr ממערכת הקבצים שמתחתיו, אך socket שחי ב-sockfs בלבד לא נהנה מכך. כעת, תהליך יכול לתייג socket, ותוכנית eBPF יכולה לבצע סינון על בסיס תגית זו.

בוצעו שתי הסרות. UDP-Lite הוסר עקב חוסר שימוש. לא ניתן עוד לבנות את IPv6 כמודול הניתן לטעינה: אם נדרש IPv6, הוא חייב להיות מקומפל בתוך הליבה. השינוי השני אינו מורגש באף הפצת ליבה, שכן הפצות השרתים הנפוצות כבר כוללות IPv6 מקומפל מראש.

ניהול זיכרון: טבלת ה-swap הושלמה

השינוי המבני ב-swap הגיע לשלב השלישי, ושלב זה מסיר את מפת ה-swap הסטטית. כעת, מניית ה-swap נמצאת ישירות בתוך טבלת ה-swap. החיסכון המדווח עומד על כ-30% ממטא-נתוני ה-swap הסטטיים; זהו זיכרון שה-kernel מחזיק ביחס לגודל התקן ה-swap שלכם, ללא קשר לשאלה אם מתבצע בו שימוש בפועל. במונחים מוחלטים מדובר בכמות קטנה עבור קובץ swap קטן, אך היא גדלה ככל שמגדירים יותר swap.

אלגוריתם MGLRU (קיצור של multi-generational least recently used, אלגוריתם פינוי הדפים החדש יותר) יכול כעת לבדוק את דגל ה-young בדפים בקבוצות (batches), במקום דף אחד בכל פעם. הנתון שפורסם לצד השינוי מצביע על שיפור של יותר מ-60% בשרת Arm64 בעל 32 ליבות. עיבוד בקבוצות משתלם ביותר כאשר העלות לכל דף היא הגבוהה ביותר, וזו הסיבה שהמספר הזה הגיע ממכונת Arm גדולה. אם אתם מריצים שרת VPS מבוסס Arm במקום x86, זהו השינוי בגרסה 7.1 שסביר ביותר שתראו במדידות שלכם, אם כי לא באותו קנה מידה על שתיים או ארבע ליבות.

כמו כן: הועברו העברות מחוץ ל-cgroups בזיכרון גווע, khugepaged מבצע סריקות עם פחות צריכת CPU, ו-maple tree עבר refactor נרחב סביב הטיפול בצמתים (nodes) גדולים. אף אחד מאלה אינם דברים שאתם מגדירים. אלו דברים שתבחינו בהם כזמן מערכת (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 קיבל יכולת הגירת תורמים (donor migration) לצורך האצת בעלים של מנעול מרוחק, EEVDF קיבל תיקונים סביב השהיה שלילית (negative lag), וליבת הטיימרים ברזולוציה גבוהה נכתבה מחדש באופן משמעותי. אלו שינויים באיכות השיהוי ששום קובץ תצורה אינו חושף.

בקרות תהליכים ומכולות חדשות ב-clone3()

שלושה דגלים נוספו ל-clone3(), וכל אחד מהם סוגר פער שמנהלי תהליכים (supervisors) נאלצו לעקוף באופן ידני במשך שנים. הדגל CLONE_AUTOREAP גורם לתהליך הבן להתפנות מעצמו בעת יציאה, כך שהוא לעולם לא הופך ל-zombie הממתין להורה שאולי לעולם לא יקרא ל-wait(). הדגל CLONE_NNP מגדיר no_new_privs על התהליך הבן בעת יצירתו, מה שסוגר את חלון הזמן שבין ה-clone לבין הרגע שבו התהליך הבן מגדיר את הדגל עבור עצמו. הדגל CLONE_PIDFD_AUTOKILL קושר את משך החיים של התהליך הבן ל-pidfd שמוחזר להורה: סגירת ה-pidfd גורמת להריגת התהליך הבן, כך שמנהל תהליכים שקורס אינו מותיר אחריו תהליכים יתומים.

מרחבי שמות של מערכות קבצים (mount namespaces) זכו לטיפול דומה. הדגל CLONE_EMPTY_MNTNS עבור clone3() והדגל UNSHARE_EMPTY_MNTNS עבור unshare() יוצרים מרחב שמות של mount ריק, במקום העתק מלא של ה-mounts של ההורה שסביבת הריצה (runtime) נדרשת בדרך כלל לבצע להם unmount. הדגל FSMOUNT_NAMESPACE מאפשר ל-fsmount() להציב מערכת קבצים ישירות בתוך מרחב שמות חדש. סביבות ריצה של מכולות הרכיבו זאת באופן ידני במשך עשור, לכן ביצוע הפעולה בקריאה אחת אומר שסביבת הריצה אינה מתחילה עוד ממרחב שמות מלא ב-mounts של המארח.

בצד הווירטואליזציה, guest_memfd תומך כעת ב-userfaultfd, כך ש-hypervisor יכול לטפל בשגיאות דפי זיכרון (page faults) של האורח ממרחב המשתמש. KVM מאובטח ב-Arm קיבל תמיכה בזיכרון אנונימי, תכונה שהמיזוג עצמו מתאר ככזו שאינה מוכנה עדיין לייצור (production).

מתי הליבה 7.1 תגיע לשרת שלך

ל-Fedora היא כבר הגיעה. מאגר העדכונים של Fedora 44 עבר לסדרת 7.1 במהלך יולי ואוגוסט 2026, כיוון ש-Fedora מבצעת rebase לליבה שלה על בסיס גרסאות יציבות חדשות במהלך מחזור החיים של הפצה. Arch ו-openSUSE Tumbleweed מחזיקות בה מאותה סיבה. אלו מכונות לבדיקות, לא מכונות להרצת שירותים.

כל השאר ממתינים, וההמתנה היא מכוונת. Debian 13 שוחררה עם 6.12 ותישאר איתו לאורך כל חיי ההפצה, כאשר תיקונים מועברים אליו ב-backport. RHEL 10 שוחררה עם 6.12.0 ונוקטת בגישה דומה. Ubuntu 26.04 LTS שוחררה עם 7.0 באפריל 2026. ל-Ubuntu 24.04 LTS יש מחסנית HWE (Hardware Enablement), שמושכת ליבה חדשה יותר מהפצות Ubuntu מאוחרות יותר אל תוך ה-LTS; מחסנית זו נמצאת בגרסה 6.17 נכון ל-point release של 24.04.4, והיא מתוכננת לעבור ל-7.0 ב-24.04.5 ב-27 באוגוסט 2026.

כאן טמון החלק שאנשים טועים בו. מחסנית HWE קופצת לכל ליבה שבה מחזיקה גרסת ה-interim החדשה ביותר, ולכן היא יכולה לדלג על גרסת upstream שלמה. 7.0 נמצאת בתוך Ubuntu LTS. ייתכן ש-7.1 לעולם לא תהיה בסיס של גרסת LTS, כיוון שהפצת ה-interim שאחריה תכיל גרסה מאוחרת יותר. מה שמגיע ל-LTS שלך מ-7.1 הוא התיקונים, שעוברים 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 בסביבת Production

לא, והסיבה לכך אינה זהירות לשם הזהירות בלבד. ליבת (kernel) המופצת על ידי מפיצת הלינוקס היא חלק מחוזה תמיכה. Canonical, Red Hat, SUSE ו-Debian מבצעות backport לתיקוני אבטחה לתוך גרסת הליבה הקפואה שלהן, ובודקות אותן מול רכיבי ה-userspace שהן מספקות. ליבה ראשית (mainline) ממקור צד-שלישי או הידור ידני מספקת לכם תכונות חדשות, אך מבטלת את עבודת התחזוקה הזו, שכן איש אינו מבצע backport לתיקונים עבור גרסה שבניתם בעצמכם. אתם הופכים למתחזקים של הליבה.

קיימים חריגים אמיתיים אך מצומצמים: חומרה שהליבה הישנה אינה מסוגלת להפעיל, או שיפור ביצועים שמדדתם בעומס העבודה שלכם ושאתם מעוניינים בו מספיק כדי לשאת בתוצאות. בשרת VPS, המקרה הראשון כמעט לעולם אינו רלוונטי, כיוון שהחומרה שאתם רואים היא וירטואלית. לכל שאר המקרים, שמרו על ליבת ההפצה מעודכנת ובצעו reboot כאשר המערכת דורשת זאת. אם שדרוג הפצה כבר נמצא ברשימת המשימות שלכם, מעבר מ-Ubuntu 24.04 ל-26.04 יעביר אתכם מגרסה 6.8 ל-7.0 בצעד אחד, קפיצה גדולה יותר מכל חבילת ליבה בודדת שתתקינו.

FAQ

כיצד אוכל לבדוק איזה kernel של Linux מריץ ה-VPS שלי?

הריצו את uname -r. הפקודה תדפיס פלט הדומה ל-6.8.0-79-generic. המספר לפני המקף הראשון מייצג את גרסת ה-upstream שעליה מבוססת ההפצה שלכם, וכל מה שאחריו הוא מספר ה-build של ההפצה, הכולל תיקונים שבוצעו ב-backport. לאחר מכן הריצו את systemd-detect-virt. אם הפלט הוא lxc או openvz, אתם נמצאים בסביבת וירטואליזציה מבוססת מכולות (container), אתם חולקים את ה-kernel של המארח, ולא ניתן לשנות אותו. אם הפלט הוא kvm, אתם מאתחלים את ה-kernel שלכם בעצמכם, ועדכונים הם באחריותכם.

האם Linux 7.1 הוא kernel עם תמיכה לטווח ארוך (LTS)?

לא. נכון ל-11 באוגוסט 2026, גרסאות ה-longterm המפורטות ב-kernel.org הן 6.18, 6.12, 6.6, 6.1, 5.15 ו-5.10, ו-7.1 אינה נמנית עמן. זוהי גרסה יציבה רגילה (stable release), ומסלול ה-stable שלה ננטש זמן קצר לאחר הופעת גרסת ה-mainline הבאה. אם אתם מחפשים kernel עם שנים של תיקונים מאחוריו ושנים של תמיכה לפניו, זהו בדיוק ה-kernel שמסופק כברירת מחדל על ידי ההפצה שלכם.

מתי Ubuntu או Debian יפיצו את kernel 7.1?

ככל הנראה לעולם לא כברירת מחדל. Debian 13 נשארת על 6.12 לאורך כל מחזור החיים של הגרסה, ו-RHEL 10 נשארת על 6.12.0. הגרסה Ubuntu 26.04 LTS הופצה עם 7.0, וערכת ה-hardware enablement של Ubuntu קופצת לכל kernel שגרסת ה-interim החדשה ביותר נושאת, כך שהיא יכולה לדלג על גרסת upstream שלמה. הגרסה Ubuntu 24.04 LTS צפויה להעביר את ה-HWE kernel שלה ל-7.0 עם שחרור נקודה 24.04.5 ב-27 באוגוסט 2026. התיקונים מ-7.1 יגיעו אליכם כ-backports לתוך גרסה ישנה יותר. התכונות החדשות בדרך כלל לא יגיעו.

מה ב-Linux 7.1 באמת משנה בשרת וירטואלי פרטי (VPS)?

ארבעה פריטים. Hardware queue leasing מאפשר למכולה להשתמש ב-queue אחד של כרטיס רשת פיזי עבור AF_XDP במהירות טבעית. השלב השלישי של ה-swap rework מסיר את ה-swap map הסטטי ומפחית את המטא-דאטה שה-kernel מחזיק עבור התקן ה-swap שלכם ב-30% לפי הדיווחים. MGLRU יכול לבדוק דגלי page young בקבוצות, עם שיפור ביצועים משמעותי שנמדד בשרתי Arm מרובי ליבות. בנוסף, clone3() קיבל את CLONE_AUTOREAP, CLONE_NNP ו-CLONE_PIDFD_AUTOKILL, שהופכים את הפיקוח על תהליכי בן (child processes) לבטוח יותר. תמיכה ב-T10 protection information ברמת מערכת הקבצים נוספה גם היא, אך כונן וירטואלי לעיתים רחוקות חושף את מטא-דאטה השלמות הנדרש לכך.

האם שדרוג ה-kernel ישבור את ה-VPS שלי?

כשלים נפוצים מתרחשים בזמן האתחול. פקודת /boot מלאה גורמת ל-update-initramfs להיכשל עם No space left on device במהלך ההתקנה, מה שמותיר את החבילה במצב מוגדר למחצה: נקו kernels ישנים עם sudo apt autoremove --purge, ולאחר מכן בצעו התקנה מחדש. מודולים חיצוניים (out-of-tree) שנבנו עבור ה-kernel הישן יפסיקו להיטען, לכן כל מה שמנוהל על ידי DKMS חייב לעבור בנייה מחדש, ובנייה מחדש שנכשלה לא תדווח על כך עד שהמודול יחסר בזמן הריצה. ואם uname -r עדיין מדווח על הגרסה הישנה לאחר אתחול, בעוד ש-dpkg -l מציג את ה-image החדש, ההתקנה לא נכשלה: פשוט הגדרת ה-bootloader לא עודכנה.