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 obejmują cztery obszary: pamięć masową i systemy plików, sieć, zarządzanie pamięcią oraz kontrolę procesów i kontenerów. Pozostała część wydania dotyczy głównie środowisk graficznych i obsługi kart graficznych, które nie są ładowane na serwerach typu headless.

Istnieje druga kwestia, którą należy wyjaśnić w pierwszej kolejności. 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 wymienia 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 popularna 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 ten przewodnik omawia oba te aspekty.

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

uname -r
uname -srm
systemd-detect-virt

Polecenie 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 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” jest mniej istotne, niż mogłoby się wydawać. Funkcje są stare, ale poprawki bezpieczeństwa zazwyczaj nie.

Polecenie systemd-detect-virt informuje, czy w ogóle można zmienić jądro systemu. Wyświetla kvm w przypadku pełnej maszyny wirtualnej, gdzie uruchamiany jest własny obraz jądra, a aktualizacja jest rzeczywistą zmianą wersji. Wyświetla lxc lub openvz w przypadku wirtualizacji kontenerowej, gdzie jądro hosta jest współdzielone. W planie kontenerowym uname -r pokazuje jądro dostawcy; instalacja pakietu jądra nie zmienia niczego, co można uruchomić, a żadna funkcja z nowej wersji 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 wersją 7.1. 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 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óry system wybrać, kompromis między wydaniami LTS a wydaniami tymczasowymi na serwerze jest decyzją leżącą u podstaw tych liczb.

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, czego wirtualne dyski zazwyczaj nie robią.

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 zgłasza 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 faktycznie jest Twój dysk, najpierw wykonaj sprawdzenie, czy dysk VPS jest rzeczywiście NVMe, a następnie zapoznaj się z różnicami między NVMe a SATA SSD na VPS, aby zrozumieć, dlaczego odpowiedź ta wpływa na wyniki wydajności.

Btrfs otrzymał poprawki dotyczące amplifikacji copy-on-write w warunkach dużego obciążenia pamięci oraz zmianę przyspieszającą czyszczenie pierwszego zakresu (extent) w śledzonym obszarze, co według raportów zwiększa przepustowość o 10% w przykładowym obciążeniu. Operacja zamykania systemu (shutdown) 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ł całkowicie przepisany, z pełną obsługą zapisu i konwersją na iomap, co jest istotne w przypadku montowania obrazów dysków z maszyn z systemem 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; dodano 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 znosi limit numerów inode w kompilacjach 32-bitowych. W obszarze sieciowych systemów plików, wbudowany w jądro serwer NFS 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 jej korzyści dla kontenerów

Główną zmianą w warstwie sieciowej jest dzierżawa kolejek sprzętowych (hardware queue leasing). Wirtualne urządzenie sieciowe (netdev) może teraz wydzierżawić kolejkę powiązaną z rzeczywistą kolejką na fizycznym urządzeniu sieciowym i działać jako jej pośrednik. Rozwiązanie to jest przeznaczone dla kontenerów. 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 kontrolę nad resztą karty sieciowej (NIC). 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, na którym się znajdowały, jednak gniazda istniejące wyłącznie w sockfs go nie posiadały. Obecnie 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ż kompilowany jako ładowalny moduł: jeśli obsługa IPv6 jest wymagana, musi zostać wkompilowana na stałe. Druga zmiana jest niewidoczna w przypadku jąder dystrybucyjnych, ponieważ popularne dystrybucje serwerowe już teraz kompilują IPv6 bezpośrednio w jądrze.

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

Przebudowa mechanizmu swap osiągnęła trzecią fazę, która usuwa statyczną mapę swap. Licznik swap znajduje się teraz bezpośrednio w tablicy swap. Deklarowana oszczędność wynosi około 30% statycznych metadanych swap; jest to pamięć, którą jądro utrzymuje proporcjonalnie do rozmiaru urządzenia swap, niezależnie od tego, czy jakiekolwiek dane są w nim przechowywane. 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ę przekraczającą 60% na 32-rdzeniowym serwerze Arm64. Przetwarzanie wsadowe przynosi największe korzyści tam, gdzie koszt operacji na pojedynczej stronie jest najwyższy, dlatego wynik ten pochodzi z dużej maszyny 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 zauważalna w Twoich własnych pomiarach, choć nie w takiej skali na systemach z dwoma lub czterema rdzeniami.

Ponadto: usunięto transfery z wygasających grup pamięci (memory cgroups), skanowanie khugepaged zużywa mniej zasobów CPU, a struktura maple tree przeszła gruntowną refaktoryzację w zakresie obsługi dużych węzłów. Żaden z tych elementów nie wymaga konfiguracji. Są to zmiany odczuwalne jako nieznacznie mniejsze zużycie czasu systemowego (system time).

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

Mechanizm sched_ext, czyli rozszerzalna klasa planera umożliwiająca napisanie planera CPU jako programu BPF i załadowanie go w czasie wykonywania, pojawił się w wersji 6.12. Wersja 7.1 wprowadza podstawową strukturę dla podplanerów, dzięki czemu grupa kontrolna (control group) będzie mogła docelowo działać pod kontrolą własnego planera. Należy zwrócić uwagę na treść tego zdania. Implementacja w wersji 7.1 nie jest ukończona, w szczególności brakuje ścieżki kolejkowania (enqueue path), zatem jest to fundament pod przyszłe wydania, a nie funkcja gotowa do natychmiastowego użycia.

Mechanizm 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ą implementacją, obecną w jądrze od wersji 6.9 za argumentem startowym fred=on. Ustawienie go jako domyślnego oznacza, że sprzęt dostępny na rynku został wystarczająco przetestowany. Dotychczasowe pomiary, wskazujące na wzrost wydajności od 4% do 7% w obciążeniach intensywnie korzystających z operacji wejścia/wyjścia, pochodzą z testów Phoronix przeprowadzonych na procesorach klienckich. Nie należy zakładać takich zysków w środowisku serwerowym przed przeprowadzeniem pomiarów własnego obciążenia.

W mechanizmie proxy execution dodano migrację dawcy (donor migration) w celu przyspieszenia zdalnego właściciela blokady, w algorytmie EEVDF wprowadzono poprawki dotyczące ujemnego opóźnienia (negative lag), a rdzeń timerów wysokiej rozdzielczości został znacząco przebudowany. 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 (supervisors) musieli dotychczas obchodzić ręcznie. Flaga 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 mógłby nigdy nie wywołać wait(). Flaga CLONE_NNP ustawia no_new_privs dla procesu potomnego w momencie jego tworzenia, co zamyka lukę czasową między wywołaniem clone a samodzielnym ustawieniem tej flagi przez proces. Flaga 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 po sobie osieroconych procesów.

Podobne zmiany wprowadzono w przestrzeniach nazw montowania (mount namespaces). Flagi 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 (runtime) 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 realizowały to ręcznie przez dekadę, więc wykonanie tej operacji w jednym wywołaniu oznacza, że runtime nie musi już startować w środowisku pełnym montowań hosta.

W obszarze wirtualizacji, guest_memfd wspiera teraz userfaultfd, co pozwala hiperwizorowi na obsługę błędów stron (page faults) gościa z poziomu przestrzeni użytkownika. Mechanizm Protected KVM na architekturze Arm zyskał wsparcie dla pamięci anonimowej, co w samym opisie scalenia (merge) określono jako rozwiązanie niegotowe do zastosowań produkcyjnych.

Kiedy jądro 7.1 trafi na Twój serwer

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

Cała reszta czeka, a oczekiwanie jest zamierzone. Debian 13 został wydany z wersją 6.12 i pozostanie przy niej przez cały okres wsparcia 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 korzysta ze stosu HWE (Hardware Enablement), który pobiera nowsze jądro z późniejszych wydań Ubuntu do wersji LTS. Stos ten znajduje się na wersji 6.17 od czasu wydania punktowego 24.04.4, a przejście na 7.0 zaplanowano na 27 sierpnia 2026 roku wraz z wydaniem 24.04.5. Wydanie punktowe nie jest nową wersją Ubuntu, a jedynie tym samym systemem 24.04 z uwzględnionymi wszystkimi dotychczasowymi aktualizacjami w świeżym nośniku instalacyjnym, więc co 24.04.5 zmienia na już aktualizowanym serwerze ogranicza się głównie do linii jądra HWE i niewiele więcej.

Oto kwestia, w której często popełniane są błędy. Stos HWE przeskakuje na jądro używane 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. To, co trafia do LTS z wersji 7.1, to poprawki przeniesione (backported) do linii, z której korzystasz. Nowe funkcje zazwyczaj pozostają w nowszych wydaniach.

Jeśli wymagasz nowszego jądra 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 jądra. 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. Jeśli /var/run/reboot-required istnieje, oznacza to, że pakiet zaktualizował jądro, ale od tego czasu nie wykonano restartu, co jest najczęstszą przyczyną, dla której załatany serwer nadal wykonuje podatny na ataki kod.

Czy należy wdrażać wersję 7.1 na produkcyjnym VPS

Nie, a powodem nie jest nadmierna ostrożność. Jądro dostarczane przez dystrybucję jest objęte wsparciem technicznym. Canonical, Red Hat, SUSE oraz Debian backportują poprawki bezpieczeństwa do swoich zamrożonych wersji i testują je w połączeniu z dostarczanym środowiskiem użytkownika. Jądro typu mainline z zewnętrznego repozytorium lub kompilowane samodzielnie zapewnia nowe funkcje, ale odbiera to wsparcie, ponieważ nikt nie backportuje poprawek do własnej kompilacji. Użytkownik staje się wówczas opiekunem własnego jądra.

Wyjątki istnieją, ale 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 zaakceptować wynikające z niej konsekwencje. 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ż na liście zadań, 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 poprawki typu backport. Następnie uruchom systemd-detect-virt. Jeśli polecenie zwróci lxc lub openvz, oznacza to wirtualizację kontenerową, współdzielenie jądra z hostem i brak możliwości jego zmiany. Jeśli zwróci kvm, system uruchamia własny obraz jądra i użytkownik samodzielnie zarządza jego aktualizacjami.

Czy Linux 7.1 to jądro o długoterminowym 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; wersja 7.1 nie znajduje się na tej liście. Jest to standardowe wydanie stabilne, którego wsparcie kończy się krótko po pojawieniu się kolejnego wydania głównego. Jeśli wymagane jest jądro z wieloletnim wsparciem, należy korzystać z wersji dostarczanej przez dystrybucję.

Kiedy Ubuntu lub Debian udostępnią 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 zostało wydane z jądrem 7.0, a stos HWE (Hardware Enablement) w Ubuntu przechodzi na wersję jądra z najnowszego wydania tymczasowego, co pozwala na pominięcie niektórych linii rozwojowych. Przejście jądra HWE w Ubuntu 24.04 LTS na wersję 7.0 zaplanowano wraz z wydaniem punktowym 24.04.5 na 27 sierpnia 2026. Poprawki z wersji 7.1 trafią do starszych linii w formie backportów, jednak nowe funkcje zazwyczaj nie zostaną przeniesione.

Co w Linux 7.1 ma znaczenie dla wirtualnego serwera prywatnego?

Cztery elementy. Hardware queue leasing umożliwia kontenerowi wykorzystanie jednej rzeczywistej kolejki karty sieciowej 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 pozwala na sprawdzanie flag wieku stron w partiach, co przynosi największe zyski wydajnościowe na serwerach wielordzeniowych z architekturą 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 wirtualne dyski rzadko udostępniają niezbędne metadane integralności.

Czy aktualizacja jądra może uszkodzić mój VPS?

Typowe awarie występują podczas rozruchu. Pełna partycja /boot powoduje błąd update-initramfs z komunikatem No space left on device podczas instalacji, co pozostawia pakiet w stanie niepełnej konfiguracji: należy usunąć stare jądra za pomocą sudo apt autoremove --purge, a następnie przeprowadzić ponowną instalację. Moduły spoza głównego drzewa (out-of-tree), zbudowane dla starego jądra, przestają się ładować, więc każdy komponent zarządzany przez DKMS musi zostać przebudowany; błąd przebudowy jest często niezauważalny aż do momentu, gdy moduł nie zostanie załadowany w czasie pracy systemu. Jeśli uname -r nadal wskazuje starą wersję po restarcie, a dpkg -l wyświetla nowy obraz, instalacja przebiegła poprawnie, lecz domyślna konfiguracja bootloadera nie została zaktualizowana.