Linux kernel 7.1: Nini kipya kwa seva za VPS?

Ni nini kipya katika Linux kernel 7.1

Linux kernel 7.1 ilitolewa tarehe 14 Juni 2026, wiki tisa baada ya 7.0. Kwa mtumiaji wa VPS (virtual private server), mabadiliko muhimu yapo katika maeneo manne: hifadhi na mifumo ya faili (filesystems), mitandao, usimamizi wa kumbukumbu (memory management), na udhibiti wa michakato (process) na container. Sehemu nyingine ya toleo hili inahusu zaidi desktop na michoro (graphics) ambayo seva isiyo na kiolesura (headless server) haipakii kamwe.

Kuna jibu la pili unalohitaji kwanza. 7.1 kwa hakika haitumiki kwenye seva yako, na haitatumika kwa muda mrefu. kernel.org haiorodheshi 7.1 kama toleo la muda mrefu (longterm release). Kufikia tarehe 11 Agosti 2026, matoleo ya muda mrefu ni 6.18, 6.12, 6.6, 6.1, 5.15 na 5.10, na kila usambazaji wa seva (server distribution) kuu hujengwa juu ya mojawapo ya hayo au juu ya toleo linalojisimamia lenyewe. "Kipya katika kernel" na "kipya kwenye seva yako" vinatofautiana kwa miaka mingi, kwa hivyo mwongozo huu unashughulikia pande zote mbili.

Ni kernel ipi inayotumika kwenye VPS yako sasa hivi

uname -r
uname -srm
systemd-detect-virt

uname -r huchapisha toleo la kernel linaloendelea. Kwenye Ubuntu 24.04 linaonekana kama 6.8.0-79-generic. Sehemu iliyo kabla ya mstari wa kwanza ni mstari wa upstream. Kila kitu baada ya hapo ni namba ya build ya usambazaji wako, na haifuatilii upstream hata kidogo. 6.8.0-79 ya Canonical hubeba maelfu ya marekebisho yaliyorejeshwa nyuma (backported) kutoka kwa kernel za baadaye, kwa hivyo si msimbo uleule ambao Linus aliutambulisha kama 6.8 mnamo Machi 2024. Hii ndiyo sababu kusema "kernel yangu ni ya zamani" hakuna uzito mkubwa kama inavyosikika. Vipengele ni vya zamani. Marekebisho ya kiusalama kwa kawaida si ya zamani.

systemd-detect-virt hukuambia kama unaweza kubadilisha kernel hata kidogo. Huchapisha kvm kwenye mashine kamili ya mtandaoni (full virtual machine), ambapo unawasha picha yako ya kernel na uboreshaji ni uboreshaji wa kweli. Huchapisha lxc au openvz kwenye uboreshaji wa kontena (container virtualisation), ambapo kernel ya mwenyeji (host) inashirikiwa. Kwenye mpango wa kontena, uname -r huonyesha kernel ya mtoa huduma, kusakinisha kifurushi cha kernel hakubadilishi chochote unachoweza kuwasha, na hakuna kipengele katika toleo hili kinachopatikana kwako hadi mtoa huduma atakapowasha upya mwenyeji kwenye kernel mpya zaidi. Fanya ukaguzi huu kabla ya kupanga kazi yoyote ya 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"
  }
]

Hizo ni 6 majukwaa, na hakuna hata moja inayowasha 7.1. Mpya zaidi ni Ubuntu 26.04 LTS (7.0), ambayo iko nyuma kwa 1 toleo la upstream. Ya zamani zaidi ambayo bado inasaidiwa iko nyuma kwa 26 matoleo. Kernel ya kawaida ya GA ya Ubuntu 24.04 iko nyuma kwa 13 matoleo, na Debian 13 pamoja na RHEL 10 ziko nyuma kwa 9 kwenye mstari wa 6.12 wa muda mrefu (longterm). Kuhesabu matoleo ni kipimo cha kukadiria, kwa sababu hupuuza kila kitu ambacho usambazaji hurejesha nyuma (backport), lakini inaonyesha ukubwa wa pengo hilo. Ikiwa unapima ni ipi kati ya hizi ya kutumia, biashara kati ya LTS na toleo la muda kwenye seva ndiyo uamuzi uliopo chini ya namba hizi.

Hifadhi na mifumo ya faili katika 7.1

7.1 inaongeza uwezo wa kuzalisha na kuthibitisha T10 PI (taarifa za ulinzi) ndani ya mfumo wa faili badala ya kwenye block layer pekee, pamoja na usaidizi rahisi wa T10 alignment. T10 PI ni baiti za ziada zinazoambatishwa kwenye kila block, zikihifadhi checksum pamoja na tag inayotambulisha block ambayo data inamilikiwa nayo, ili uandishi uliopotoka au uliokatika ugundulike badala ya kurudishwa kama data sahihi. Changamoto kwa mtumiaji wa VPS ni maunzi. Metadata ya uadilifu lazima ionyeshwe na kifaa, na diski ya mtandaoni kwa kawaida haionyeshi metadata hiyo.

ls /sys/block/vda/integrity/

Kwenye diski nyingi za VPS, hilo hurejesha No such file or directory, kwa sababu block layer hutengeneza saraka ya integrity tu wakati kifaa kinaposajili usaidizi wa uadilifu. Hitilafu hiyo ni jibu la kawaida hapa, si tatizo. Ikiwa unataka kujua diski yako ni ya aina gani kabla ya kusoma zaidi kuhusu vipengele vya hifadhi, kuangalia kama diski ya VPS ni NVMe kweli ndilo jambo la kwanza, na tofauti kati ya NVMe na SATA SSD kwenye VPS inaeleza kwa nini jibu hilo hubadilisha namba zako.

Btrfs inapata marekebisho ya copy-on-write amplification chini ya shinikizo la kumbukumbu, pamoja na mabadiliko yanayoharakisha ufutaji wa extent ya kwanza katika safu inayofuatiliwa, jambo lililoripotiwa kuongeza throughput kwa 10% kwenye workload ya sampuli iliyotajwa kwenye merge. Operesheni yake ya kuzima (shutdown) haijawekwa tena kama ya majaribio (experimental). XFS inaboresha zero range flushing na lookup kupitia iomap, na inaongeza write pointer kwenye jiometri ya real-time group, ambayo ni msingi wa vifaa vya zoned. NTFS imeandikwa upya kabisa katika toleo hili, ikiwa na usaidizi kamili wa uandishi na ubadilishaji wa iomap, jambo ambalo ni muhimu ikiwa utawahi ku-mount disk image kutoka kwa mashine ya Windows kwenye seva yako.

Mambo madogo ya hifadhi yanayofaa kujulikana: ublk, dereva wa block wa user-space, imepata zero-copy I/O; io_uring imepata amri za SCSI passthrough; usaidizi wa SED-OPAL self-encrypting drive umepata amri ya STACK_RESET na hali ya single user iliyopanuliwa; kuna dereva mpya wa fs-dax character kwa ajili ya vifaa vya direct-access; na VFS imepanua inode->i_ino kutoka unsigned long hadi u64, jambo ambalo linaondoa ukomo wa namba za inode kwenye build za 32-bit. Kwa upande wa mfumo wa faili wa mtandao, seva ya NFS iliyo ndani ya kernel sasa inaweza kusaini file handles zake kupitia chaguo la mount la sign_fh, na mteja wa CIFS amejifunza O_TMPFILE.

Networking: kukodisha queue, na faida yake kwa container

Mabadiliko makuu ya networking ni kukodisha queue za maunzi (hardware queue leasing). Sasa virtual netdev inaweza kukodisha queue iliyounganishwa na queue halisi kwenye physical netdev, na kufanya kazi kama proxy yake. Lengo la hili ni kwa ajili ya containers. Hadi sasa, container iliyotaka kutumia AF_XDP (address family express data path, aina ya socket inayopeleka pakiti ghafi kwenye user space bila kuzinakili kupitia network stack) ililazimika kupewa karibu kifaa kizima. Kwa queue iliyokodishwa, inapata queue moja ya maunzi, inaendesha AF_XDP na memory providers kwa kasi ya asili, huku host ikibaki na sehemu nyingine ya NIC. Hii inakuja sambamba na usaidizi wa AF_XDP katika njia ya zero-copy ya io_uring.

Kwa upande wa kawaida, sockets katika sockfs sasa zinakubali user.* extended attributes. AF_UNIX socket inayotegemea njia (path-based) ilikuwa tayari inarithi usaidizi wa xattr kutoka kwenye filesystem iliyo chini yake, lakini socket iliyopo kwenye sockfs pekee haikuwa na uwezo huo. Sasa mchakato unaweza kuweka lebo kwenye socket, na programu ya eBPF inaweza kuchuja kulingana na lebo hiyo.

Kuna vitu viwili vilivyoondolewa. UDP-Lite imeondolewa, kwa sababu haikupata watumiaji. IPv6 haiwezi tena kujengwa kama loadable module: ukitaka IPv6, lazima iwe compiled ndani ya kernel. Jambo la pili halionekani kwenye kernel yoyote ya usambazaji (distribution kernel), kwa sababu usambazaji wa kawaida wa seva tayari unajenga IPv6 ndani yake.

Usimamizi wa kumbukumbu: jedwali la swap limekamilika

Marekebisho ya swap yamefika awamu ya tatu, na awamu hii inaondoa ramani tuli ya swap (static swap map). Hesabu ya swap sasa inakaa moja kwa moja kwenye jedwali la swap. Akiba inayoripotiwa ni takriban 30% ya metadata tuli ya swap, ambayo ni kumbukumbu inayoshikiliwa na kernel kulingana na ukubwa wa kifaa chako cha swap, bila kujali kama kuna kitu kimehifadhiwa humo au la. Kwa ujumla, kiasi hiki ni kidogo kwenye faili ndogo ya swap, na hukua kulingana na swap unayosanidi.

MGLRU (multi-generational least recently used, algorithm mpya zaidi ya kurejesha kurasa za kumbukumbu) sasa inaweza kukagua alama ya "young" kwenye kurasa kwa makundi badala ya ukurasa mmoja kwa wakati mmoja. Takwimu zilizochapishwa pamoja na mabadiliko haya zinaonyesha uboreshaji wa zaidi ya 60% kwenye seva ya Arm64 yenye cores 32. Ufanyaji kazi kwa makundi (batching) huleta faida kubwa zaidi pale ambapo gharama ya kila ukurasa ni ya juu, ndiyo maana namba hiyo ilitoka kwenye mashine kubwa ya Arm. Ikiwa unaendesha VPS ya Arm badala ya x86, hili ndilo mabadiliko ya toleo la 7.1 yanayoweza kuonekana zaidi katika vipimo vyako, ingawa si kwa kiwango hicho kwenye cores mbili au nne.

Pia hapa: uhamishaji kutoka kwa cgroups za kumbukumbu zinazokufa (dying memory cgroups) umeondolewa, khugepaged inafanya skani kwa kutumia CPU kidogo, na maple tree imefanyiwa marekebisho makubwa kuhusu ushughulikiaji wa node zake kubwa. Hakuna kati ya haya unayoweza kusanidi. Ni mambo utakayoyagundua kama kupungua kidogo kwa muda wa mfumo (system time).

Schedulers: sub-schedulers za sched_ext, na FRED ikiwa imewashwa kwa chaguo-msingi

sched_ext, darasa la scheduler linaloweza kupanuliwa ambalo hukuruhusu kuandika CPU scheduler kama programu ya BPF na kuipakia wakati wa runtime, ilianza kupatikana katika 6.12. Toleo la 7.1 linaongeza muundo mkuu wa sub-schedulers, ili control group iweze hatimaye kuendeshwa chini ya scheduler yake yenyewe. Soma sentensi hiyo kwa makini. Utekelezaji wake haujakamilika katika 7.1, na hasa njia ya enqueue haipo, kwa hivyo huu ni msingi wa toleo la baadaye badala ya kitu unachoweza kuwasha leo.

Intel FRED (flexible return and event delivery) sasa imewashwa kwa chaguo-msingi kwenye maunzi yanayoiunga mkono. FRED inachukua nafasi ya njia ya zamani ya x86 ya utoaji wa matukio (event delivery) na njia safi zaidi, na imekuwa kwenye kernel tangu 6.9 ikiwa nyuma ya hoja ya boot ya fred=on. Kuifanya iwe imewashwa kwa chaguo-msingi ni ishara kwamba maunzi yanayouzwa yamefanyiwa majaribio ya kutosha. Vipimo vilivyochapishwa hadi sasa, katika kiwango cha 4% hadi 7% kwenye workloads nzito za I/O, vinatokana na majaribio ya Phoronix kwenye silicon ya mteja, kwa hivyo usitegemee matokeo hayo kwenye seva hadi utakapopima workload yako mwenyewe.

Proxy execution imepata uhamiaji wa donor kwa ajili ya kuongeza nguvu kwa mmiliki wa lock ya mbali, EEVDF imepata marekebisho kuhusu negative lag, na msingi wa high-resolution timer umeandikwa upya kwa kiasi kikubwa. Haya ni mabadiliko ya ubora wa latency ambayo hakuna faili ya usanidi inayoweza kuyaonyesha.

Vidhibiti vipya vya mchakato na kontena katika clone3()

Bendera tatu zimeongezwa kwenye clone3(), na kila moja inaziba pengo ambalo wasimamizi wamekuwa wakilifanyia kazi kwa mikono kwa miaka mingi. CLONE_AUTOREAP humfanya mtoto ajivune mwenyewe anapotoka, hivyo hawi kamwe zombie anayesubiri mzazi ambaye huenda asipige simu ya wait(). CLONE_NNP huweka no_new_privs kwa mtoto wakati wa uumbaji, jambo linaloziba mwanya kati ya clone na mtoto anapojiwekea bendera hiyo yeye mwenyewe. CLONE_PIDFD_AUTOKILL huunganisha muda wa kuishi wa mtoto na pidfd inayorejeshwa kwa mzazi: funga pidfd na mtoto atauawa, hivyo msimamizi anayekufa hawezi kuacha mayatima wakiendelea kufanya kazi.

Namespace za mount zilipata matibabu hayohayo. CLONE_EMPTY_MNTNS kwa ajili ya clone3() na UNSHARE_EMPTY_MNTNS kwa ajili ya unshare() huunda namespace ya mount isiyo na kitu ndani yake, badala ya nakala kamili ya kawaida ya mount za mzazi ambazo runtime inabidi iziondoe (unmount). FSMOUNT_NAMESPACE inaruhusu fsmount() kuweka mfumo wa faili moja kwa moja kwenye namespace mpya. Runtime za kontena zimekuwa zikikusanya hili kwa mikono kwa muongo mmoja, kwa hivyo kulifanya katika wito mmoja inamaanisha runtime haianzi tena kutoka kwenye namespace iliyojaa mount za mwenyeji (host).

Kwa upande wa uboreshaji wa virtualisation, guest_memfd sasa inasaidia userfaultfd, ili hypervisor iweze kushughulikia makosa ya ukurasa wa mgeni (guest page faults) kutoka nafasi ya mtumiaji (user space). KVM iliyolindwa kwenye Arm imepata usaidizi wa kumbukumbu isiyojulikana (anonymous memory), ambayo muunganisho wenyewe unaelezea kama hauko tayari kwa uzalishaji.

Kernel 7.1 inafika lini kwenye seva yako

Fedora tayari inayo. Hifadhi ya sasisho ya Fedora 44 ilihamia kwenye mfululizo wa 7.1 wakati wa Julai na Agosti 2026, kwa sababu Fedora hufanya rebase ya kernel yake kwenye laini mpya thabiti ndani ya toleo moja. Arch na openSUSE Tumbleweed wanayo kwa sababu hiyo hiyo. Hizo ni mashine za kufanyia majaribio, si mashine za kuendeshea huduma zako.

Mifumo mingine yote inasubiri, na kusubiri huko ni kwa makusudi. Debian 13 ilitoka ikiwa na 6.12 na inabaki kwenye 6.12 kwa muda wote wa maisha ya toleo hilo, huku marekebisho yakiletwa (backported) ndani yake. RHEL 10 ilitoka na 6.12.0 na inafanya vivyo hivyo. Ubuntu 26.04 LTS ilitoka na 7.0 mwezi Aprili 2026. Ubuntu 24.04 LTS ina hardware enablement stack, ambayo huvuta kernel mpya zaidi kutoka matoleo ya baadaye ya Ubuntu kuingia kwenye LTS, na stack hiyo iko kwenye 6.17 kufikia toleo la 24.04.4, na imepangwa kuhamia 7.0 na 24.04.5 tarehe 27 Agosti 2026.

Hapa ndipo watu wanapokosea. HWE stack hurukia kernel yoyote inayobebwa na toleo jipya zaidi la muda (interim release), hivyo inaweza kuruka laini ya upstream kabisa. 7.0 iko kwenye Ubuntu LTS. 7.1 inaweza isiwahi kuwa msingi wa toleo lolote, kwa sababu toleo la muda linalofuata litabeba laini ya baadaye. Kinachofika kwenye LTS yako kutoka 7.1 ni marekebisho, yaliyorejeshwa (backported) kwenye laini uliyopo. Vipengele vingi hubaki nyuma.

Ikiwa unataka kernel mpya zaidi kwenye seva thabiti, njia zinazoungwa mkono ni chache.

# 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

Baada ya reboot, thibitisha kile ulichokiendesha:

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

uname -r sasa inapaswa kuonyesha laini mpya, na dpkg -l inaonyesha kila kernel image iliyosakinishwa. Ikiwa uname -r inaonyesha toleo la zamani wakati dpkg -l inaorodhesha toleo jipya, kifurushi kimesakinishwa lakini bootloader default haijabadilika: angalia entries za menyu ya GRUB. /var/run/reboot-required kuwepo inamaanisha kifurushi kimeboresha kernel na hakuna reboot iliyofanyika tangu wakati huo, ambayo ndiyo sababu ya kawaida zaidi inayofanya seva iliyofanyiwa patch bado iwe inaendesha code yenye hatari.

Je, unapaswa kutumia 7.1 kwenye VPS ya uzalishaji

Hapana, na sababu si tahadhari tu kwa ajili ya usalama. Kernel ya usambazaji (distribution kernel) ni mkataba wa usaidizi. Canonical, Red Hat, SUSE na Debian kila moja hufanya backport ya marekebisho ya usalama kwenye toleo lao lililogandishwa na kuyafanyia majaribio dhidi ya userspace wanayosafirisha nayo. Kernel ya mainline kutoka kwenye archive ya mtu wa tatu au iliyojengwa kwa mkono inakupa vipengele vipya lakini inaondoa kazi hiyo ya usaidizi, kwa sababu hakuna anayefanya backport ya marekebisho kwenye build yako. Unakuwa msimamizi wa kernel yako mwenyewe.

Isipokuwa ni pale ambapo kuna sababu za kweli lakini finyu: maunzi (hardware) ambayo kernel ya zamani haiwezi kuyaendesha, au mabadiliko ya utendaji kazi ambayo umeyapima kwenye workload yako na unayataka sana kiasi cha kukubali matokeo yake. Kwenye VPS, sababu ya kwanza karibu haitokei kamwe, kwa sababu maunzi unayoona ni ya mtandaoni (virtual). Kwa mambo mengine yote, iweke kernel ya usambazaji ikiwa ya kisasa na uwashe upya seva (reboot) pale inapoagiza. Ikiwa uboreshaji wa usambazaji (distribution upgrade) tayari uko kwenye orodha yako, kuhama kutoka Ubuntu 24.04 kwenda 26.04 kutakupeleka kutoka 6.8 hadi 7.0 kwa hatua moja, ambayo ni hatua kubwa zaidi kuliko ile utakayopata kutoka kwenye kifurushi chochote cha kernel pekee.

FAQ

Ninawezaje kuangalia kernel ya Linux ambayo VPS yangu inatumia?

Tekeleza uname -r. Itachapisha kitu kama 6.8.0-79-generic. Namba iliyo kabla ya mstari wa kwanza ni toleo la upstream ambalo distribution yako inajengea, na kila kitu baada ya hapo ni namba ya build ya distribution yenyewe, ambayo ina marekebisho yaliyorejeshwa kutoka matoleo mapya (backported fixes). Kisha tekeleza systemd-detect-virt. Iikichapisha lxc au openvz, unatumia container virtualization, unashiriki kernel ya host, na huwezi kuibadilisha. Iikichapisha kvm, unawasha (boot) image yako ya kernel na ni jukumu lako kufanya upgrades.

Je, Linux 7.1 ni kernel ya longterm support?

Hapana. Kufikia 11 August 2026, matoleo ya longterm yaliyoorodheshwa kwenye kernel.org ni 6.18, 6.12, 6.6, 6.1, 5.15 na 5.10, na 7.1 haimo. Hili ni toleo la kawaida la stable, na mstari wake wa stable huachwa muda mfupi baada ya toleo lijalo la mainline kutoka. Ikiwa unataka kernel yenye miaka ya marekebisho nyuma yake na miaka ya marekebisho mbele yake, hiyo ndiyo kernel ambayo distribution yako tayari inayo.

Ubuntu au Debian itatoa kernel 7.1 lini?

Pengine haitatokea kama chaguo-msingi. Debian 13 itabaki kwenye 6.12 kwa muda wote wa maisha ya toleo hilo, na RHEL 10 itabaki kwenye 6.12.0. Ubuntu 26.04 LTS ilitoa 7.0, na hardware enablement stack ya Ubuntu hurukia kernel yoyote inayokuja na toleo jipya la muda (interim release), hivyo inaweza kuruka mstari wa upstream kabisa. Ubuntu 24.04 LTS imepangwa kuhamisha HWE kernel yake kwenda 7.0 na toleo la 24.04.5 mnamo 27 August 2026. Marekebisho kutoka 7.1 yatakufikia kama backports kwenye mstari wa zamani. Vipengele vipya mara nyingi havitakuwepo.

Ni nini katika Linux 7.1 ambacho ni muhimu kwenye virtual private server?

Vitu vinne. Hardware queue leasing inaruhusu container kutumia queue moja halisi ya NIC kwa ajili ya AF_XDP kwa kasi ya asili. Awamu ya tatu ya swap rework inaondoa static swap map na kupunguza metadata ambayo kernel inashikilia kwa ajili ya swap device yako kwa 30% iliyoripotiwa. MGLRU inaweza kuangalia page young flags kwa makundi, huku faida kubwa zaidi ikionekana kwenye seva za Arm zenye core nyingi. Na clone3() imepata CLONE_AUTOREAP, CLONE_NNP na CLONE_PIDFD_AUTOKILL, ambavyo hufanya usimamizi wa child processes kuwa salama zaidi. Filesystem-level T10 protection information pia imeingizwa, lakini virtual disk mara chache hufichua metadata ya uadilifu (integrity metadata) inayohitajika.

Je, kuboresha kernel yangu kutaharibu VPS yangu?

Hitilafu za kawaida hutokea wakati wa boot. /boot kamili husababisha update-initramfs kufeli na No space left on device wakati wa usakinishaji, na kuacha kifurushi kikiwa kimesanidiwa nusu: safisha kernels za zamani kwa sudo apt autoremove --purge, kisha usakinishe upya. Out-of-tree modules zilizojengwa kwa kutumia kernel ya zamani huacha kufanya kazi, kwa hivyo chochote kinachosimamiwa na DKMS lazima kijengwe upya, na ujenzi usiofanikiwa huwa kimya hadi pale module itakapokosekana wakati wa runtime. Na kama uname -r bado inaripoti toleo la zamani baada ya reboot wakati dpkg -l inaonyesha image mpya, hakuna kilichoharibika kwenye usakinishaji: bootloader default haijabadilika.