Linux 6.18 випущено 30 листопада 2025 року й включено kernel.org до переліку longterm-гілок із прогнозованою підтримкою до грудня 2028 року. Позначка LTS означає довше отримання виправлень у цій гілці, але не гарантує сумісності з пакетами конкретного дистрибутива.
Longterm визначає супровід гілки ядра
Мейнтейнери переносять до 6.18 важливі виправлення з новіших ядер. Строк може уточнюватися, а дистрибутив здатен підтримувати власну збірку за іншим календарем. Орієнтуватися слід на обидва джерела.
Версія kernel.org не дорівнює пакету дистрибутива
Ubuntu, Debian, Fedora та корпоративні системи додають конфігурацію, патчі, модулі й політику Secure Boot. Самостійна заміна ядра може позбавити користувача перевірених модулів або підтримки постачальника.
Зовнішні модулі є головним ризиком
DKMS-драйвери GPU, мережевих адаптерів, файлових систем і засобів безпеки треба зібрати на тестовій машині. Успішна компіляція ще не доводить коректну роботу після suspend, навантаження чи оновлення firmware.
Нові драйвери не виправляють стару прошивку
Підтримка пристрою залежить від ядра, linux-firmware, UEFI та microcode. Оновлюйте компоненти узгоджено й зберігайте попередній завантажувальний запис, щоб мати шлях повернення.
Контейнери використовують ядро хоста
Оновлення впливає на cgroups, namespaces, eBPF, мережеві фільтри та runtime всіх контейнерів вузла. Перед rollout потрібні тести Kubernetes або Docker-навантаження, а не лише запуск порожнього контейнера.
Чекліст перевірки
- уточніть політику дистрибутива;
- перевірте Secure Boot;
- зіберіть DKMS-модулі;
- протестуйте мережу й сховища;
- запустіть production-подібне навантаження;
- залиште старе ядро в boot menu;
- підготуйте консольний доступ.
LTS зменшує зміни, але не операційний ризик
Стаття TechPulse про Kubernetes 1.35 показує залежність оркестратора від вузла, а огляд основ Docker пояснює спільне ядро контейнерів.
Політика дистрибутива важливіша за номер upstream
Постачальник дистрибутива backport-ить виправлення, підтримує конфігурацію та перевіряє взаємодію з userspace. Самостійна заміна на kernel.org може позбавити систему цієї матриці й підтримки. Спочатку з’ясуйте, чи пропонує дистрибутив 6.18 як штатний або hardware enablement kernel і який строк супроводу має конкретний пакет.
Порівнюйте changelog пакета та потрібні виправлення, а не лише рядок версії. Старіший номер може вже містити критичний backport.
Зовнішні модулі потрібно зібрати до перезавантаження
DKMS, драйвер GPU, storage, мережевий модуль і security agent можуть не підтримувати новий API ядра. У тестовому середовищі зберіть їх, перевірте підпис для Secure Boot і переконайтеся, що initramfs містить потрібний драйвер. Помилка на цьому етапі може зробити вузол недоступним після reboot.
Зберігайте попереднє ядро в boot menu й перевірте віддалений доступ до консолі. Відкат, який потребує фізичної присутності, не є достатнім для віддаленого кластера.
Контейнерний хост потребує тесту workloads і runtime
Усі контейнери ділять ядро хоста, тому зміна впливає на seccomp, cgroups, eBPF, storage і network stack. Запустіть репрезентативні pods, перевірте CNI, CSI, service mesh та observability agents. Особливу увагу приділіть eBPF-інструментам; приклад breaking changes наведено в матеріалі про Falco 0.44.
Під навантаженням відстежуйте kernel warnings, dropped packets, I/O latency, memory pressure і час старту контейнерів. Функціональний smoke test не знаходить регресію продуктивності.
Розгортання має бути хвильовим і вимірюваним
Почніть із canary-вузлів, які можна швидко вивести з балансування. Залиште їх під типовим навантаженням, порівняйте з контрольною групою й лише потім збільшуйте частку. Зафіксуйте пороги автоматичної зупинки: crash, зростання latency, помилки драйвера або деградація мережі.
Після завершення не видаляйте старе ядро одразу. Дочекайтеся стабільного періоду, оновіть runbook і перевірте, що система моніторингу правильно визначає нову версію на всіх вузлах.
Перед rollout потрібен формальний preflight
Перевірка повинна підтвердити доступне місце в /boot, успішне створення initramfs, наявність нового kernel і старого fallback, підпис модулів, працездатність консолі та свіжий backup. Для кластера додайте можливість drain, достатній резерв capacity і заборону одночасного оновлення вузлів однієї зони.
Після reboot автоматично звіряйте версію ядра, стан storage, network, time sync, container runtime та security agents. Вузол не повертається в балансування лише тому, що відповідає на ping. Зберігайте результати preflight і postflight у системі змін, щоб інцидент можна було пов’язати з конкретним rollout.
Для desktop і серверів створіть різні кільця розгортання та критерії зупинки. Робоча станція частіше залежить від графіки, сну й периферії, сервер — від storage, network і agent. Одна успішна група не доводить готовність іншої, навіть якщо пакет ядра має той самий номер.
Завершіть роботу оновленням capacity plan: LTS не звільняє від майбутніх security patches, reboot і перевірок сторонніх модулів. Визначте регулярне maintenance window та максимальний строк розгортання критичного виправлення. Для runtime security використовуйте висновки з Falco 0.44, а для container orchestration — перевірки Kubernetes і containerd. Версія ядра має бути видимою в інвентарі та incident timeline.
Першоджерело: перелік longterm-релізів Linux на kernel.org.
Коментарі
Щоб залишити коментар, увійдіть через Google.