Co nowego w jądrze Linux 7.1 dla serwerów

Co nowego w jądrze Linux 7.1

Jądro Linux 7.1 zostało wydane 14 czerwca 2026 roku, dziewięć tygodni po wersji 7.0. Dla użytkownika VPS (virtual private server) istotne zmiany dotyczą czterech obszarów: pamięci masowej i systemów plików, sieci, zarządzania pamięcią oraz kontroli procesów i kontenerów. Pozostała część wydania obejmuje głównie prace nad środowiskiem graficznym i obsługą kart graficznych, które nie są ładowane na serwerach typu headless.

Istnieje druga kwestia, którą należy wyjaśnić na wstępie. Wersja 7.1 niemal na pewno nie działa na Twoim serwerze i nie będzie działać przez długi czas. kernel.org nie oznacza wersji 7.1 jako wydania o długoterminowym wsparciu (longterm). Według stanu na 11 sierpnia 2026 roku linie longterm to 6.18, 6.12, 6.6, 6.1, 5.15 oraz 5.10, a każda główna dystrybucja serwerowa bazuje na jednej z nich lub na linii utrzymywanej samodzielnie. Pojęcia „nowości w jądrze” oraz „nowości na serwerze” dzielą lata, dlatego niniejszy przewodnik omawia oba te aspekty.

Które jądro systemu jest obecnie uruchomione na Twoim VPS

uname -r
uname -srm
systemd-detect-virt

uname -r wyświetla wersję uruchomionego jądra. W systemie Ubuntu 24.04 wynik wygląda jak 6.8.0-79-generic. Część przed pierwszym myślnikiem to linia rozwojowa upstream. Wszystko po nim to numer kompilacji danej dystrybucji, który nie odnosi się bezpośrednio do numeracji upstream. Jądro 6.8.0-79 od Canonical zawiera tysiące poprawek przeniesionych (backported) z nowszych wersji, więc nie jest to kod, który Linus oznaczył jako 6.8 w marcu 2024 roku. Dlatego stwierdzenie „moje jądro jest stare” ma mniejsze znaczenie, niż mogłoby się wydawać. Funkcje są stare, ale poprawki bezpieczeństwa zazwyczaj nie.

systemd-detect-virt informuje, czy w ogóle można zmienić jądro systemu. Polecenie zwraca kvm w przypadku pełnej maszyny wirtualnej, gdzie uruchamiasz własny obraz jądra, a aktualizacja jest rzeczywistą zmianą wersji. W przypadku wirtualizacji kontenerowej, gdzie jądro hosta jest współdzielone, polecenie zwraca lxc lub openvz. W planie kontenerowym uname -r pokazuje jądro dostawcy; instalacja pakietu jądra nie zmienia niczego, co można uruchomić, a żadna funkcja z nowszego wydania nie będzie dostępna, dopóki dostawca nie zrestartuje hosta na nowszym jądrze. Wykonaj to sprawdzenie przed planowaniem jakichkolwiek prac nad jądrem.

[
  {
    "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"
  }
]

To 6 platform, z których żadna nie uruchamia wersji 7.1. Najnowsza to Ubuntu 26.04 LTS (7.0), która jest o 1 wydanie upstream za wersją 7.1. Najstarsza wspierana wersja jest o 26 wydań za. Domyślne jądro GA w Ubuntu 24.04 znajduje się 13 wydań wstecz, a Debian 13 oraz RHEL 10 znajdują się 9 wydań wstecz na linii długoterminowego wsparcia (longterm) 6.12. Liczenie wydań jest przybliżoną miarą, ponieważ ignoruje wszystko, co dystrybucje przenoszą z nowszych wersji, ale pokazuje skalę różnicy. Jeśli rozważasz, którą z nich wybrać, decyzja opiera się na kompromisie między wydaniami LTS a wydaniami tymczasowymi na serwerze.

Pamięć masowa i systemy plików w 7.1

Wersja 7.1 wprowadza możliwość generowania i weryfikacji T10 PI (protection information) bezpośrednio w systemie plików, a nie tylko w warstwie blokowej, wraz z elastyczną obsługą wyrównania T10. T10 PI to dodatkowe bajty dołączane do każdego bloku, zawierające sumę kontrolną oraz znacznik identyfikujący przynależność bloku danych. Dzięki temu błędnie skierowany lub niekompletny zapis zostaje wykryty, zamiast zostać uznanym za poprawne dane. Ograniczeniem dla użytkownika VPS jest sprzęt. Metadane integralności muszą być udostępniane przez urządzenie, a wirtualny dysk zazwyczaj ich nie eksponuje.

ls /sys/block/vda/integrity/

Na większości dysków VPS zwraca to No such file or directory, ponieważ warstwa blokowa tworzy katalog integrity tylko wtedy, gdy urządzenie rejestruje obsługę integralności. Ten błąd jest w tym przypadku standardową odpowiedzią, a nie usterką. Jeśli przed dalszą lekturą o funkcjach pamięci masowej chcesz sprawdzić, czym w rzeczywistości jest Twój dysk, w pierwszej kolejności należy wykonać sprawdzenie, czy dysk VPS jest faktycznie NVMe, a artykuł różnica między NVMe a SSD SATA na VPS wyjaśnia, dlaczego odpowiedź na to pytanie zmienia uzyskiwane wyniki wydajności.

Btrfs otrzymał poprawki dotyczące amplifikacji copy-on-write w warunkach dużego obciążenia pamięci, a także zmianę przyspieszającą czyszczenie pierwszego zakresu (extent) w śledzonym obszarze, co według danych z procesu merge przekłada się na 10% wyższą przepustowość w przykładowych obciążeniach. Operacja zamykania systemu plików nie jest już oznaczona jako eksperymentalna. XFS usprawnia opróżnianie (flushing) zakresów zerowych oraz wyszukiwanie przez iomap, a także dodaje wskaźnik zapisu do geometrii grup czasu rzeczywistego, co stanowi fundament pod obsługę urządzeń strefowych (zoned devices). NTFS w tym wydaniu został napisany od nowa, z pełną obsługą zapisu i konwersją na iomap, co jest istotne w przypadku montowania obrazów dysków z maszyn Windows na serwerze.

Mniejsze zmiany w pamięci masowej, o których warto wiedzieć: ublk, sterownik blokowy działający w przestrzeni użytkownika, zyskał obsługę I/O typu zero-copy; io_uring zyskał polecenia SCSI passthrough; obsługa samoszyfrujących dysków SED-OPAL zyskała polecenie STACK_RESET oraz rozszerzony tryb pojedynczego użytkownika; wprowadzono nowy sterownik znakowy fs-dax dla urządzeń z bezpośrednim dostępem; a VFS rozszerzył inode->i_ino z unsigned long do u64, co usuwa limit numerów inode w kompilacjach 32-bitowych. W zakresie sieciowych systemów plików, serwer NFS działający w jądrze może teraz podpisywać uchwyty plików (file handles) za pomocą opcji montowania sign_fh, a klient CIFS zyskał obsługę O_TMPFILE.

Sieci: dzierżawa kolejek i korzyści dla kontenerów

Główną zmianą w warstwie sieciowej jest dzierżawa kolejek sprzętowych. Wirtualne urządzenie sieciowe (netdev) może teraz dzierżawić kolejkę przypisaną do fizycznej kolejki na fizycznym urządzeniu sieciowym i działać jako jej pośrednik. Celem tej zmiany są kontenery. Do tej pory kontener wymagający AF_XDP (address family express data path – typ gniazda przekazujący surowe pakiety do przestrzeni użytkownika bez kopiowania ich przez stos sieciowy) musiał otrzymać dostęp do niemal całego urządzenia. Dzięki dzierżawionej kolejce kontener otrzymuje jedną kolejkę sprzętową, obsługuje AF_XDP oraz dostawców pamięci z natywną prędkością, podczas gdy host zachowuje resztę zasobów karty sieciowej. Zmiana ta pojawia się obok wsparcia AF_XDP w ścieżce zero-copy mechanizmu io_uring.

W obszarze standardowych rozwiązań, gniazda w sockfs akceptują teraz user.* rozszerzone atrybuty (xattr). Gniazda AF_UNIX oparte na ścieżkach dziedziczyły wsparcie xattr z systemu plików, jednak gniazda istniejące wyłącznie w sockfs go nie posiadały. Teraz proces może nadać etykietę gniazdu, a program eBPF może filtrować ruch na podstawie tej etykiety.

Wprowadzono dwa usunięcia. Protokół UDP-Lite został usunięty ze względu na brak użytkowników. IPv6 nie może być już budowany jako ładowalny moduł: jeśli obsługa IPv6 jest wymagana, musi zostać skompilowana bezpośrednio w jądrze. Druga zmiana jest niewidoczna w przypadku standardowych jąder dystrybucyjnych, ponieważ popularne dystrybucje serwerowe już teraz kompilują IPv6 na stałe.

Zarządzanie pamięcią: tablica swap została ukończona

Prace nad przebudową mechanizmu swap weszły w trzecią fazę, która usuwa statyczną mapę swap. Licznik swap znajduje się teraz bezpośrednio w tablicy swap. Oszczędność pamięci wynosi około 30% metadanych statycznych swap; jest to pamięć, którą jądro utrzymuje proporcjonalnie do rozmiaru urządzenia swap, niezależnie od tego, czy cokolwiek jest do niego przenoszone. Wartość bezwzględna jest niewielka w przypadku małego pliku swap, ale rośnie wraz z rozmiarem skonfigurowanej przestrzeni wymiany.

MGLRU (multi-generational least recently used, nowszy algorytm odzyskiwania stron) może teraz sprawdzać flagę "young" dla stron w partiach, zamiast pojedynczo. Wynik opublikowany wraz z tą zmianą wskazuje na poprawę o ponad 60% na 32-rdzeniowym serwerze Arm64. Przetwarzanie wsadowe przynosi największe korzyści tam, gdzie koszt operacji na pojedynczej stronie jest najwyższy, dlatego taki wynik uzyskano na dużej maszynie Arm. Jeśli korzystasz z serwera VPS opartego na architekturze Arm zamiast x86, jest to zmiana w wersji 7.1, która najprawdopodobniej będzie widoczna w Twoich własnych pomiarach, choć nie w takiej skali na systemach dwu- lub czterordzeniowych.

Dodatkowo: usunięto transfery z wygasających cgroups pamięci, khugepaged skanuje przy mniejszym zużyciu CPU, a struktura maple tree przeszła gruntowną refaktoryzację w zakresie obsługi dużych węzłów. Żadna z tych rzeczy nie wymaga konfiguracji. Są to zmiany, które odczujesz jako nieznacznie mniejszy czas systemowy (system time).

Planery: podplanery sched_ext oraz domyślnie włączony FRED

sched_ext, rozszerzalna klasa planera pozwalająca na napisanie planera CPU jako programu BPF i załadowanie go w czasie wykonywania, pojawiła się w wersji 6.12. Wersja 7.1 dodaje podstawową strukturę dla podplanerów, dzięki czemu grupa kontrolna (control group) będzie mogła docelowo działać pod własnym planerem. Należy uważnie przeczytać to zdanie. Implementacja w 7.1 nie jest ukończona, w szczególności brakuje ścieżki kolejkowania (enqueue path), więc jest to fundament pod przyszłe wydanie, a nie funkcja gotowa do użycia dzisiaj.

Intel FRED (flexible return and event delivery) jest teraz domyślnie włączony na sprzęcie, który go obsługuje. FRED zastępuje starszą ścieżkę dostarczania zdarzeń x86 nowszą i bardziej przejrzystą, a w jądrze znajduje się od wersji 6.9 za argumentem startowym fred=on. Domyślne włączenie tej funkcji oznacza, że sprzęt dostępny na rynku został wystarczająco przetestowany. Opublikowane dotychczas pomiary, w zakresie od 4% do 7% przy obciążeniach intensywnie korzystających z operacji wejścia/wyjścia, pochodzą z testów Phoronix na procesorach klienckich, dlatego nie należy zakładać takich zysków na serwerze przed przeprowadzeniem pomiarów własnego obciążenia.

Mechanizm proxy execution zyskał migrację dawców (donor migration) w celu przyspieszenia zdalnego właściciela blokady, EEVDF otrzymał poprawki dotyczące ujemnego opóźnienia (negative lag), a rdzeń timerów wysokiej rozdzielczości został znacząco przepisany. Są to zmiany wpływające na jakość opóźnień, których nie można skonfigurować za pomocą żadnego pliku konfiguracyjnego.

Nowe mechanizmy kontroli procesów i kontenerów w clone3()

Do clone3() dodano trzy flagi, z których każda eliminuje lukę, którą zarządcy procesów obchodzili ręcznie przez lata. CLONE_AUTOREAP sprawia, że proces potomny automatycznie kończy swój żywot po wyjściu, dzięki czemu nigdy nie staje się procesem zombie oczekującym na rodzica, który może nigdy nie wywołać wait(). CLONE_NNP ustawia flagę no_new_privs dla procesu potomnego w momencie tworzenia, co zamyka lukę czasową między wywołaniem clone a samodzielnym ustawieniem tej flagi przez proces. CLONE_PIDFD_AUTOKILL wiąże czas życia procesu potomnego z deskryptorem pidfd zwróconym do rodzica: zamknięcie pidfd powoduje zabicie procesu potomnego, dzięki czemu zarządca, który uległ awarii, nie pozostawia działających osieroconych procesów.

Przestrzenie nazw montowania (mount namespaces) otrzymały podobne usprawnienia. CLONE_EMPTY_MNTNS dla clone3() oraz UNSHARE_EMPTY_MNTNS dla unshare() tworzą pustą przestrzeń nazw montowania, zamiast standardowej pełnej kopii montowań rodzica, którą środowisko uruchomieniowe musiało dotychczas ręcznie odmontowywać. FSMOUNT_NAMESPACE pozwala fsmount() na umieszczenie systemu plików bezpośrednio w nowej przestrzeni nazw. Środowiska uruchomieniowe kontenerów budowały to ręcznie przez dekadę, więc wykonanie tego w jednym wywołaniu oznacza, że środowisko nie startuje już z przestrzenią nazw pełną montowań hosta.

W obszarze wirtualizacji, guest_memfd obsługuje teraz userfaultfd, dzięki czemu hiperwizor może obsługiwać błędy stron pamięci gościa z poziomu przestrzeni użytkownika. Mechanizm Protected KVM na architekturze Arm zyskał obsługę pamięci anonimowej, co w samym opisie scalenia (merge) określono jako rozwiązanie niegotowe do zastosowań produkcyjnych.

Kiedy kernel 7.1 trafi na Twój serwer

Fedora już go posiada. Repozytorium aktualizacji Fedora 44 przeszło na serię 7.1 w lipcu i sierpniu 2026 roku, ponieważ Fedora przenosi swój kernel na nowe stabilne linie w ramach wydania. Arch oraz openSUSE Tumbleweed posiadają go z tego samego powodu. Są to maszyny przeznaczone do testów, a nie do uruchamiania usług produkcyjnych.

Wszystkie inne systemy czekają, a to oczekiwanie jest zamierzone. Debian 13 został wydany z wersją 6.12 i pozostaje przy niej przez cały cykl życia wydania, otrzymując jedynie backporty poprawek. RHEL 10 został wydany z wersją 6.12.0 i stosuje tę samą strategię. Ubuntu 26.04 LTS otrzymało wersję 7.0 w kwietniu 2026 roku. Ubuntu 24.04 LTS posiada stos HWE (hardware enablement stack), który pobiera nowszy kernel z późniejszych wydań Ubuntu do wersji LTS; stos ten bazuje na wersji 6.17 w wydaniu punktowym 24.04.4 i ma przejść na wersję 7.0 wraz z wydaniem 24.04.5 w dniu 27 sierpnia 2026 roku.

Oto kwestia, w której często popełniane są błędy. Stos HWE przeskakuje na kernel używany w najnowszym wydaniu tymczasowym, więc może całkowicie pominąć linię upstream. Wersja 7.0 znajduje się w Ubuntu LTS. Wersja 7.1 może nigdy nie stać się podstawą wydania LTS, ponieważ kolejne wydanie tymczasowe będzie korzystać z późniejszej linii. Do Twojego systemu LTS z wersji 7.1 trafiają jedynie poprawki, przenoszone (backportowane) do linii, na której aktualnie pracujesz. Nowe funkcje zazwyczaj pozostają niedostępne.

Jeśli wymagasz nowszego kernela na stabilnym serwerze, wspierane ścieżki są ograniczone.

# 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

Po restarcie sprawdź, która wersja została faktycznie uruchomiona:

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

uname -r powinno teraz wskazywać nową linię, a dpkg -l wyświetla wszystkie zainstalowane obrazy kernela. Jeśli uname -r pokazuje starą wersję, podczas gdy dpkg -l wymienia nową, oznacza to, że pakiet został zainstalowany, ale domyślne ustawienia bootloadera nie uległy zmianie: sprawdź wpisy w menu GRUB. Obecność /var/run/reboot-required oznacza, że pakiet zaktualizował kernel, ale od tego czasu nie wykonano restartu, co jest najczęstszą przyczyną sytuacji, w której załatany serwer nadal wykonuje podatny na ataki kod.

Czy należy dążyć do wersji 7.1 na produkcyjnym serwerze VPS

Nie, a powodem nie jest jedynie nadmierna ostrożność. Jądro dostarczane przez dystrybucję jest objęte wsparciem technicznym. Firmy takie jak Canonical, Red Hat, SUSE czy Debian przenoszą poprawki bezpieczeństwa (backport) do swoich zamrożonych wersji i testują je pod kątem zgodności z dostarczanym środowiskiem użytkownika. Jądro typu mainline z zewnętrznego repozytorium lub skompilowane samodzielnie zapewnia nowe funkcje, ale pozbawia użytkownika tego wsparcia, ponieważ nikt nie przenosi poprawek do takiej wersji. Użytkownik staje się wówczas samodzielnym opiekunem jądra.

Wyjątki istnieją, lecz są nieliczne: sprzęt, którego starsze jądro nie obsługuje, lub zmiana wydajności, która została zmierzona w konkretnym środowisku pracy i jest na tyle istotna, by uzasadniała przejęcie odpowiedzialności za ewentualne problemy. Na serwerze VPS pierwszy przypadek niemal nigdy nie występuje, ponieważ sprzęt jest wirtualny. W pozostałych sytuacjach należy utrzymywać jądro dystrybucyjne w aktualnym stanie i restartować system, gdy jest to wymagane. Jeśli aktualizacja dystrybucji znajduje się już w planach, przejście z Ubuntu 24.04 na 26.04 przenosi system z wersji 6.8 na 7.0 w jednym kroku, co stanowi większy przeskok niż jakakolwiek pojedyncza aktualizacja pakietu jądra.

FAQ

Jak sprawdzić, z jakiego jądra Linux korzysta mój VPS?

Uruchom uname -r. Wyświetli ono wynik w formacie podobnym do 6.8.0-79-generic. Liczba przed pierwszym myślnikiem oznacza linię rozwojową upstream, na której bazuje dystrybucja, a wszystko po nim to numer kompilacji dystrybucji, zawierający backporty poprawek. Następnie uruchom systemd-detect-virt. Jeśli polecenie zwróci lxc lub openvz, oznacza to wirtualizację kontenerową, współdzielenie jądra hosta i brak możliwości jego zmiany. Jeśli zwróci kvm, uruchamiasz własny obraz jądra i odpowiadasz za jego aktualizacje.

Czy Linux 7.1 to jądro o wydłużonym wsparciu (LTS)?

Nie. Według stanu na 11 sierpnia 2026 linie LTS wymienione na kernel.org to 6.18, 6.12, 6.6, 6.1, 5.15 oraz 5.10, a 7.1 nie znajduje się wśród nich. Jest to standardowe wydanie stabilne, którego linia wsparcia kończy się krótko po pojawieniu się kolejnego wydania mainline. Jeśli potrzebujesz jądra z wieloletnią historią poprawek i gwarancją wsparcia, jest nim właśnie jądro dostarczone przez Twoją dystrybucję.

Kiedy Ubuntu lub Debian wydadzą jądro 7.1?

Prawdopodobnie nigdy jako wydanie domyślne. Debian 13 pozostaje przy wersji 6.12 przez cały cykl życia wydania, podobnie jak RHEL 10 przy 6.12.0. Ubuntu 26.04 LTS dostarczono z jądrem 7.0, a stos HWE (Hardware Enablement) w Ubuntu przeskakuje na jądro z najnowszego wydania tymczasowego, więc może całkowicie pominąć daną linię upstream. Ubuntu 24.04 LTS ma zaplanowane przejście jądra HWE na wersję 7.0 wraz z wydaniem punktowym 24.04.5 w dniu 27 sierpnia 2026. Poprawki z wersji 7.1 trafią do systemu jako backporty do starszej linii. Nowe funkcje zazwyczaj nie zostaną przeniesione.

Co w Linux 7.1 ma znaczenie dla wirtualnego serwera prywatnego?

Cztery elementy. Hardware queue leasing pozwala kontenerowi na użycie jednej rzeczywistej kolejki NIC dla AF_XDP z natywną prędkością. Trzecia faza przebudowy mechanizmu swap usuwa statyczną mapę swap i redukuje metadane przechowywane przez jądro dla urządzenia swap o deklarowane 30%. MGLRU potrafi sprawdzać flagi wieku stron w partiach, z największym odnotowanym zyskiem na serwerach wielordzeniowych Arm. Ponadto clone3() zyskało CLONE_AUTOREAP, CLONE_NNP oraz CLONE_PIDFD_AUTOKILL, co zwiększa bezpieczeństwo nadzorowania procesów potomnych. Wprowadzono również obsługę informacji o ochronie T10 na poziomie systemu plików, jednak wirtualny dysk rzadko udostępnia niezbędne metadane integralności.

Czy aktualizacja jądra uszkodzi mój VPS?

Typowe awarie występują podczas rozruchu. Pełny /boot powoduje, że update-initramfs kończy się błędem No space left on device podczas instalacji, pozostawiając pakiet w stanie częściowej konfiguracji: usuń stare jądra za pomocą sudo apt autoremove --purge, a następnie zainstaluj ponownie. Moduły spoza drzewa jądra (out-of-tree), zbudowane dla starej wersji, przestają się ładować, więc każdy komponent zarządzany przez DKMS musi zostać przebudowany, a nieudana przebudowa pozostaje niezauważona do momentu, gdy moduł nie będzie dostępny w czasie wykonywania. Jeśli uname -r nadal raportuje starą wersję po restarcie, podczas gdy dpkg -l wymienia nowy obraz, instalacja przebiegła poprawnie: nie zaktualizowano domyślnego wpisu w programie rozruchowym.