Що нового в Linux kernel 7.1 для серверів

Що нового в ядрі Linux 7.1

Ядро Linux 7.1 випущено 14 June 2026, через дев’ять тижнів після 7.0. Для орендаря VPS (virtual private server) важливі зміни належать до чотирьох сфер: сховища та файлові системи, мережа, керування пам’яттю, а також керування процесами й контейнерами. Решта випуску переважно стосується графічного середовища та графіки, які headless-сервер не завантажує.

Спочатку потрібно отримати іншу відповідь. Найімовірніше, на вашому сервері не працює 7.1, і ще довго не працюватиме. kernel.org не вказує 7.1 як longterm-випуск. Станом на 11 August 2026 гілки longterm — це 6.18, 6.12, 6.6, 6.1, 5.15 і 5.10, а всі основні серверні дистрибутиви базуються на одній із них або на гілці, яку вони підтримують самостійно. «Нове в ядрі» та «нове на вашому сервері» розділяють роки, тому цей посібник охоплює обидві частини.

Яке ядро зараз запущене на вашому VPS

uname -r
uname -srm
systemd-detect-virt

uname -r виводить версію запущеного ядра. В Ubuntu 24.04 вона має вигляд 6.8.0-79-generic. Частина до першого дефіса — це основна upstream-гілка. Усе після неї — власний номер збірки дистрибутива, який взагалі не відстежує upstream. Ядро Canonical 6.8.0-79 містить тисячі виправлень, перенесених із новіших ядер, тому це не той код, якому 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), яка відстає від upstream на 1 випусків. Найстаріша платформа, яка все ще підтримується, відстає на 26 випусків. Стандартне GA-ядро Ubuntu 24.04 відстає на 13 випуски, а Debian 13 і RHEL 10 відстають на 9 випуски, використовуючи довгострокову гілку 6.12. Підрахунок випусків є приблизним показником, оскільки не враховує всі виправлення, які дистрибутиви переносять із новіших версій. Проте він показує масштаб розриву. Якщо ви обираєте, який із цих варіантів використовувати, саме компроміс між LTS і проміжним випуском на сервері визначає це рішення.

Сховища та файлові системи у 7.1

У 7.1 додано можливість генерувати й перевіряти T10 PI (protection information) усередині файлової системи, а не лише на рівні блоків, а також гнучку підтримку вирівнювання T10. T10 PI — це додаткові байти, приєднані до кожного блоку. Вони містять контрольну суму й тег, який визначає, до якого блоку належать дані. Завдяки цьому помилково спрямований або неповний запис виявляється, а не повертається як коректні дані. Для користувача VPS проблема полягає в апаратному забезпеченні. Метадані цілісності має надавати пристрій, а віртуальний диск зазвичай їх не надає.

ls /sys/block/vda/integrity/

На більшості дисків VPS це повертає No such file or directory, оскільки рівень блоків створює каталог integrity лише тоді, коли пристрій реєструє підтримку цілісності. У цьому випадку така помилка є штатною відповіддю, а не несправністю. Якщо перед подальшим читанням про можливості сховища потрібно з’ясувати, який саме диск використовується, спочатку перевірте, чи є диск VPS справді NVMe, а різниця між NVMe та SATA SSD на VPS пояснює, чому це впливає на ваші показники.

Btrfs отримує виправлення для зменшення write amplification під час дефіциту пам’яті, а також зміну, яка пришвидшує очищення першого extent у відстежуваному діапазоні. Для тестового навантаження, зазначеного в описі merge, повідомляється про приріст пропускної здатності на 10%. Операцію завершення роботи більше не позначено як експериментальну. XFS покращує скидання нульового діапазону та пошук через iomap, а також додає write pointer до геометрії real-time group. Це підготовка до роботи із zoned-пристроями. NTFS у цьому випуску повністю переписано. Додано повну підтримку запису та перехід на iomap. Це важливо, якщо ви монтуєте на сервері образ диска з Windows-комп’ютера.

Інші важливі зміни у сховищах: ublk, драйвер блокових пристроїв у просторі користувача, отримав zero-copy I/O; io_uring отримав команди SCSI passthrough; підтримка SED-OPAL self-encrypting drive отримала команду STACK_RESET і розширений single user mode; додано новий символьний драйвер fs-dax для пристроїв прямого доступу; а VFS розширила inode->i_ino з unsigned long до u64, що усуває обмеження на номер inode у 32-бітних збірках. У мережевій файловій підсистемі вбудований NFS-сервер тепер може підписувати file handles через параметр монтування sign_fh, а клієнт CIFS отримав O_TMPFILE.

Мережа: оренда черг і можливості для контейнера

Головна зміна в мережевій підсистемі — оренда апаратних черг. Віртуальний netdev тепер може орендувати чергу, прив’язану до реальної черги фізичного netdev, і діяти як її проксі. Це призначено для контейнерів. Раніше контейнеру, якому був потрібен AF_XDP (address family express data path, тип сокетів, що передає необроблені пакети в простір користувача без копіювання через мережевий стек), доводилося надавати майже весь пристрій. З орендованою чергою контейнер отримує одну апаратну чергу, запускає AF_XDP і memory providers на нативній швидкості, а хост зберігає решту NIC. Ця можливість з’являється разом із підтримкою AF_XDP у zero-copy path для io_uring.

У звичайній частині sockfs сокети тепер приймають user.* extended attributes. Сокет AF_UNIX, створений за шляхом, уже успадковував підтримку xattr від файлової системи, у якій він розміщений, але сокет, що існує лише в sockfs, такої підтримки не мав. Тепер процес може додати до сокета мітку, а програма eBPF може фільтрувати сокети за цією міткою.

Два вилучення. UDP-Lite видалено, оскільки ним ніхто не користувався. IPv6 більше не можна збирати як loadable module: якщо потрібен IPv6, його компілюють у ядро. Другу зміну не видно в kernel збірках жодного дистрибутива, оскільки поширені серверні дистрибутиви вже компілюють IPv6 у ядро.

Керування пам’яттю: таблицю swap завершено

Перероблення swap переходить до третьої фази, яка усуває статичну карту swap. Тепер кількість swap безпосередньо зберігається в таблиці swap. Заявлена економія становить близько 30% статичних метаданих swap. Це пам’ять, яку kernel утримує пропорційно до розміру пристрою swap незалежно від того, чи використовуються swap-сторінки. У абсолютних значеннях це небагато для невеликого swap-файлу, але обсяг зростає разом із налаштованим swap.

MGLRU (multi-generational least recently used, новіший алгоритм reclaim сторінок) тепер може перевіряти прапорець young на сторінках пакетами, а не по одній сторінці. Згідно з опублікованими даними, на сервері Arm64 із 32 ядрами це дає приріст понад 60%. Пакетна обробка найбільше допомагає там, де вартість обробки окремої сторінки найвища. Саме тому це значення отримали на потужній Arm-машині. Якщо ви використовуєте Arm VPS замість x86 VPS, це зміна у 7.1, яка найімовірніше буде помітна у ваших власних вимірюваннях, хоча на двох або чотирьох ядрах результат не буде таким самим.

Також усунуто перенесення з memory cgroups, що завершуються, khugepaged виконує сканування з меншим навантаженням на CPU, а maple tree зазнало масштабного рефакторингу обробки великих вузлів. Нічого з цього не потрібно налаштовувати. Це зміни, які проявляються як дещо менший system time.

Планувальники: субпланувальники sched_ext і FRED увімкнено за замовчуванням

sched_ext — розширюваний клас планувальника, який дає змогу реалізувати планувальник CPU як програму BPF і завантажувати її під час роботи системи. Він з’явився у версії 6.12. У версії 7.1 додано базову структуру для субпланувальників. Завдяки цьому в майбутньому група керування зможе працювати під власним планувальником. Уважно прочитайте це речення. Реалізацію ще не завершено у версії 7.1. Зокрема, відсутній шлях постановки задач у чергу. Тому це основа для наступного випуску, а не функція, яку можна ввімкнути вже сьогодні.

Intel FRED (flexible return and event delivery) тепер увімкнено за замовчуванням на обладнанні, яке його підтримує. FRED замінює застарілий шлях доставки подій x86 на простіший. У ядрі він доступний із версії 6.9, але раніше його потрібно було вмикати за допомогою аргументу завантаження fred=on. Увімкнення FRED за замовчуванням означає, що підтримуване обладнання вже достатньо протестоване. Опубліковані вимірювання в діапазоні від 4% до 7% для робочих навантажень із великою кількістю операцій введення-виведення отримано під час тестування Phoronix на клієнтських процесорах. Тому не закладайте такі показники для сервера, доки не виміряєте власне робоче навантаження.

У механізмі proxy execution додано міграцію донора для підвищення пріоритету віддаленого власника блокування. Для EEVDF виправлено обробку від’ємного lag. Ядро високоточних таймерів також істотно переписано. Це зміни для якості затримок, які не налаштовуються через конфігураційний файл.

Нові засоби керування процесами та контейнерами в clone3()

До clone3() додали три прапорці. Кожен із них усуває обмеження, яке супервізорам роками доводилося обходити вручну. CLONE_AUTOREAP змушує дочірній процес самостійно завершити збирання свого стану після виходу, тому він не стає zombie-процесом, що очікує на батьківський процес, який може ніколи не викликати wait(). CLONE_NNP встановлює no_new_privs для дочірнього процесу під час його створення. Це усуває проміжок між викликом clone і встановленням прапорця самим дочірнім процесом. CLONE_PIDFD_AUTOKILL прив’язує час життя дочірнього процесу до pidfd, повернутого батьківському процесу: якщо закрити pidfd, дочірній процес буде завершено. Тому супервізор, який аварійно завершується, не залишає запущених orphan-процесів.

Таку саму обробку отримали mount namespace. CLONE_EMPTY_MNTNS для clone3() і UNSHARE_EMPTY_MNTNS для unshare() створюють mount namespace без жодних об’єктів усередині замість звичайної повної копії монтувань батьківського процесу, які runtime потім має демонтувати. FSMOUNT_NAMESPACE дає змогу fsmount() безпосередньо розмістити файлову систему в новому namespace. Container runtime вже десять років збирають цю схему вручну, тому один виклик дає змогу більше не починати роботу з namespace, заповненого монтуваннями host-системи.

У частині віртуалізації guest_memfd тепер підтримує userfaultfd, тому hypervisor може обробляти помилки сторінок guest із user space. Protected KVM на Arm отримав підтримку anonymous memory. Сам merge описує цю підтримку як не готову до production-використання.

Коли kernel 7.1 з’явиться на вашому сервері

Fedora вже має його. Репозиторій оновлень Fedora 44 перейшов на серію 7.1 упродовж липня та серпня 2026 року, оскільки Fedora переводить kernel на нові стабільні гілки в межах одного релізу. Arch і openSUSE Tumbleweed мають його з тієї самої причини. Це системи для тестування, а не для запуску сервісів.

Усі інші системи чекають, і це зроблено навмисно. Debian 13 вийшов із kernel 6.12 і залишається на 6.12 протягом усього життєвого циклу релізу, отримуючи виправлення, адаптовані та перенесені до цієї версії. RHEL 10 вийшов із версією 6.12.0 і працює так само. Ubuntu 26.04 LTS вийшов із версією 7.0 у квітні 2026 року. Ubuntu 24.04 LTS має hardware enablement stack, який переносить новіший kernel із пізніших релізів Ubuntu до LTS. Станом на випуск 24.04.4 цей stack працює на версії 6.17. Згідно з планом, у випуску 24.04.5 27 серпня 2026 року він перейде на 7.0.

Ось що часто розуміють неправильно. HWE stack переходить на kernel, який постачається в найновішому проміжному релізі, тому може повністю пропустити окрему upstream-гілку. Версія 7.0 входить до складу Ubuntu LTS. Версія 7.1 може ніколи не стати базовою версією LTS, оскільки наступний проміжний реліз використовуватиме новішу гілку. Із 7.1 до вашої LTS потрапляють виправлення, перенесені до тієї гілки, яку ви використовуєте. Більшість функцій залишається в upstream.

Якщо на стабільному сервері потрібен новіший 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 містить нову, пакет встановлено, але типовий запис bootloader не змінився: перевірте записи меню GRUB. Наявність /var/run/reboot-required означає, що пакет оновив kernel, але після цього систему ще не перезавантажували. Це найпоширеніша причина, через яку на пропатченому сервері все ще виконується вразливий код.

Чи варто переходити на 7.1 на production VPS

Ні. І причина не лише в обережності заради обережності. Ядро дистрибутива є частиною угоди про підтримку. Canonical, Red Hat, SUSE і Debian переносять виправлення безпеки у свої стабільні гілки та тестують їх із userspace, який постачається разом із ядром. Mainline kernel зі стороннього архіву або ядро, зібране вручну, надає нові функції, але позбавляє вас цієї роботи, оскільки ніхто не переносить виправлення у вашу збірку. Ви стаєте відповідальним за супровід ядра.

Винятки існують, але вони вузькі: старе ядро не підтримує потрібне обладнання або ви виміряли зміну продуктивності на власному навантаженні й настільки прагнете її отримати, що готові самостійно відповідати за наслідки. На VPS перший випадок майже ніколи не виникає, оскільки доступне вам обладнання є віртуальним. В усіх інших випадках підтримуйте ядро дистрибутива в актуальному стані та перезавантажуйте систему, коли цього вимагає оновлення. Якщо оновлення дистрибутива вже є у вашому плані, перехід з Ubuntu 24.04 на 26.04 переведе вас з 6.8 на 7.0 за один крок. Це більший перехід, ніж може надати будь-який окремий пакет ядра.

FAQ

Як перевірити, яке ядро Linux працює на моєму VPS?

Виконайте uname -r. Команда виведе приблизно 6.8.0-79-generic. Число перед першим дефісом — це версія upstream, на якій базується збірка вашого дистрибутива. Усе після нього — власний номер збірки дистрибутива, що містить backport-виправлення. Потім виконайте systemd-detect-virt. Якщо команда виведе lxc або openvz, ви використовуєте контейнерну віртуалізацію, спільно використовуєте ядро хоста й не можете його змінити. Якщо команда виведе kvm, ви завантажуєте власний образ ядра, тому самі відповідаєте за його оновлення.

Чи є Linux 7.1 ядром із довгостроковою підтримкою?

Ні. Станом на 11 August 2026 на kernel.org перелічені такі longterm-гілки: 6.18, 6.12, 6.6, 6.1, 5.15 і 5.10. Версії 7.1 серед них немає. Це звичайний стабільний реліз, а його stable-гілку припиняють підтримувати невдовзі після появи наступного mainline-релізу. Якщо вам потрібне ядро з багаторічними виправленнями в минулому та багаторічною підтримкою в майбутньому, саме таким уже є ядро вашого дистрибутива.

Коли Ubuntu або Debian випустять kernel 7.1?

Ймовірно, ніколи не використовуватимуть його за замовчуванням. Debian 13 залишається на 6.12 протягом усього життєвого циклу релізу, а RHEL 10 — на 6.12.0. Ubuntu 26.04 LTS поставляється з 7.0, а стек Ubuntu hardware enablement переходить на версію ядра, яку містить найновіший interim-реліз. Тому він може повністю пропустити upstream-гілку. Ubuntu 24.04 LTS має перейти на kernel 7.0 у складі HWE з point-релізом 24.04.5, запланованим на 27 August 2026. Виправлення з 7.1 надходитимуть до вас як backport у старішу гілку. Нові функції зазвичай не надходитимуть.

Які зміни в Linux 7.1 справді важливі для virtual private server?

Чотири зміни. Hardware queue leasing дає змогу контейнеру використовувати одну реальну чергу NIC для AF_XDP на нативній швидкості. Третя фаза переробки swap прибирає статичну карту swap і, за опублікованими даними, на 30% зменшує обсяг метаданих, які ядро зберігає для swap-пристрою. MGLRU може пакетно перевіряти прапорці page young; найбільший опублікований приріст зафіксовано на Arm-сервері з великою кількістю ядер. А clone3() отримав CLONE_AUTOREAP, CLONE_NNP і CLONE_PIDFD_AUTOKILL, які підвищують безпеку нагляду за дочірніми процесами. Підтримку T10 protection information на рівні файлової системи також додано, але віртуальний диск рідко надає потрібні метадані цілісності.

Чи зламає оновлення ядра мій VPS?

Типові проблеми виникають під час завантаження. Якщо /boot заповнений, update-initramfs завершується з No space left on device під час встановлення, і пакет залишається частково налаштованим: видаліть старі ядра за допомогою sudo apt autoremove --purge, а потім повторіть встановлення. Модулі, зібрані поза деревом ядра для старої версії, перестають завантажуватися. Тому все, чим керує DKMS, потрібно зібрати повторно. Невдала повторна збірка може залишитися непоміченою, доки модуль не знадобиться під час роботи. Якщо після перезавантаження uname -r усе ще показує стару версію, а dpkg -l містить новий образ, проблема не у встановленні: завантажувач не змінив kernel за замовчуванням.