Ситуация знакомая: ноутбук или сервер на стабильном дистрибутиве двухлетней давности, всё хорошо, но новый Wi-Fi 6 модуль не виден, звук на свежем кодеке молчит, а GPU драйвер требует ядра поновее. Полный апгрейд дистрибутива ради одного драйвера избыточен и рискован. Выход давно отработан: mainline kernel из ванильных сборок ставится рядом со старым, и система получает поддержку нового железа без перетряхивания всего остального. Разбираем практику: где взять ядро под свой дистрибутив, порядок установки, откат и риски, о которых нужно знать заранее.
Mainline, stable и ванильное ядро, что вообще ставится
В терминологии стоит сориентироваться. Mainline это дерево Линуса с самым свежим релизом: новые драйверы появляются тут первыми, но стабилизацией занимается мало. Stable ветки (6.6, 6.12 и так далее) получают долгосрочные исправления, и ядро LTS - оптимальная точка для свежего железа. Дистрибутивное ядро это тот же upstream, но с патчами, конфигурацией и интеграцией под конкретный дистрибутив. Когда мы говорим об установке свежего ядра на старый дистрибутив, обычно имеется в виду LTS из ванильных сборок, потому что дистрибутивная сборка тянет за собой слишком много зависимостей.
Сборки под Ubuntu поставляются проектом kernel.ubuntu.com в комплекте готовых deb-пакетов, загружаемых руками или через утилиты вроде mainline (установка пакетом из PPA или deb). Для Debian берутся сборки из backports: ветка bookworm-backports регулярно содержит ядро поновее, и это официальный полуофициальный путь. На Fedora свежие ядра тоже доступны из официальных репозиториев или через COPR, но Fedora и так идёт впереди - чаще вопрос встаёт о RHEL-подобных системах, где пакеты ядер строго консервативны и приходится строить через ELRepo (репозиторий kernel-lt и kernel-ml решает эту задачу много лет).
Рабочая процедура для Ubuntu и Debian
Под Ubuntu процедура стала почти казённой. Устанавливается утилита mainline: add-apt-repository ppa:cappelikan/ppa, apt install mainline, а дальше mainline --install-latest ставит самое свежее стабильное ядро с загрузкой исходников и сборкой в один клик. Альтернативно ручной путь: скачивание нужных deb-пакетов linux-image, linux-modules и linux-headers из c каталога в конкретной версии и установка dpkg -i *.deb. После установки update-grub проходит автоматически, и новая запись появляется в меню загрузчика.
Для Debian open way это backports: в sources.list добавляется строка с bookworm-backports, и прямое указание apt install -t bookworm-backports linux-image-amd64 приносит более свежее ядро с дистрибутивной конфигурацией. Это чуть консервативнее ванили, но зато обновления приезжают через apt, а DKMS-модули собираются прозрачнее, потому что headers того же происхождения.
Проверка после установки проста: перезагрузка, в меню GRUB выбрана новая версия, uname -r показывает новое ядро, журнал journalctl -k без красных ошибок о прошивках. Если сеть живёт, графика встала и suspend/resume не обиделся - ядро принято. Если что-то сломалось, возвращаемся к предыдущему ядру через меню GRUB, и только потом решаем, что делать дальше. Поэтому перед апгрейдом полезно скопировать номер текущей версии ядра куда-нибудь видно на бумажках: uname -r до перезагрузки, и меню Advanced options in GRUB его покажет.
Нюансы для RHEL-подобных и вечных споров о secure boot
Для RHEL и его клонов путь проложен ELRepo: rpm --import ключа, установка репозитория, dnf --enablerepo=elrepo-kernel install kernel-ml. Ядро kernel-ml регулярно выходит в свежих ветках, а kernel-lt специализируется на последнем LTS. После установки надо выставить default через grubby --set-default или grub2-set-default, потому что RHEL-подобные не всегда перещёлкивают сами.
Отдельная тема - Secure Boot. Ванильные сборки не подписаны ключом производителя вашего ноутбука, и с включённым Secure Boot такое ядро не загрузится. Выхода два: отключить Secure Boot в прошивке, что является стандартным решением для энтузиастов, или подписать собранное ядро своим MOK-ключом через enroll в прошивку, что чуть длиннее в первый раз, но потом работает безупречно. В корпоративной среде с обязательным Secure Boot выбирайте второй вариант и документируйте процедуру, потому что после апдейта прошивок ключи иногда теряются.
DKMS, драйверы и откат, что проверить до перезагрузки
Сторонний драйвер это то место, где свежее ядро может сломаться несовместимостью модуля. DKMS пересобирает модули под новые ядра автоматически при установке, но есть условия: должны стоять заголовки linux-headers из той же сборки, а код модуля должен компилироваться с новым API ядра - на совсем свежих релизах старые проприетарные драйверы временно отстают. Классика года - драйвер Realtek 8821ce, который отстаёт от API и требует пропатченной версии из GitHub. Поэтому последовательность мудрая: сначала проверяется совместимость DKMS (dkms status), потом перезагрузка.
Откат подготавливается заранее: предыдущее рабочее ядро не удаляется, GRUB-запись остаётся, и в /etc/default/grub выставляете сохранение выбора: GRUB_DEFAULT=saved и GRUB_SAVEDEFAULT=true плюс update-grub - после этого система помнит загруженное ядро, и при неудаче одна неудачная попытка не превращается в невозможность загрузиться. На сервере с KVM или IPMI это и лишнее: консоль всё равно в порядке, но дома на ноутбуке эта строчка окажется тем самым предохранителем, который не дал потратить воскресенье на восстановление.
Когда ядро обновлять не стоит
И завершим признанием: иногда делать ничего не надо. Если железо работает, и свежие функции не нужны - старое дистрибутивное ядро с долгой поддержкой безопаснее, потому что у него есть патчи и люди, которые ими занимаются. Mainline годится для решения конкретной задачи (Wi-Fi не работал - заработал), а не для спорта. Заведите полуформально правило в личном runbook: обновление ядра случается по причине, а не по расписанию; причина записывается, откат тестируется на пустом месте. Такая дисциплина сохраняет вашу систему в равновесии между новизной и порядком, что и есть суть зрелого отношения к ядру на старом дистрибутиве.
Типовые задачи, которые решаются свежим ядром
Чтобы решение об обновлении было осознанным, коротко перечислим, что реально чинится с upgrade ядра. Wi-Fi: свежие модули семейства mt7921e и mtk на ноутбучных чипах получали драйверы и стабильность в поздних ветках, и на ядрах 4.x некоторые карточки просто не имели модуля. Звук: свежие кодеки Realtek и обходы обладателей HDMI завозятся регулярно, и ноутбуки с кодеком ALC-something свежим обретают звук без правок конфигов. Графика: драйверы amdgpu и i915 обновляются постоянно, и ноутбуки с новыми iGPU или встроенными APU видят заметные изменения между версиями ядра.
Другая частая причина - файловые системы и производительность: улучшения в ext4, Btrfs, io_uring и сетевом стеке приходят с ядрами. Похоже и с железом массовым: новые модели тачпадов I2C, сенсоров освещённости и кнопок-раскладушек ноутбуков внезапно оживают. Наконец, безопасность: последние смягчения уязвимостей CPU тоже приезжают в ядре - впрочем, стабильные ветки старых дистрибутивов обычно подтягивают их назад, и это скорее довод дожидаться backports, чем ставить ваниль на прод.
Проверка совместимости до перезагрузки, рабочий миниатюрный скрипт
Полезно написать один небольшой скрипт с ключевыми проверками и хранить его рядом с процедурой обновления. Проверяется свободное место в /boot (ядра с initramfs занимают сотни мегабайт, и старые разделы на 512 МБ переполняются мгновенно); проверяется установка headers через dpkg -l linux-headers-$(uname -r) для DKMS; проверяется DKMS-совместимость модулей командой dkms status, где каждый модуль должен быть либо установлен, либо хотя бы успешно собран под новое ядро; проверяется запись GRUB_DEFAULT=saved в конфиге. Пять команд, выполняемых перед ребутом, экономят вечер возни с аварийной консолью.
Инвентаризацию завершит бэкап: перед любым ядерным манёвром снимается снимок раздела или хотя бы список установленных пакетов и пользовательских конфигов. Если обновление вылилось в незагружаемую систему, вы всегда сможете откатиться на старое ядро и сделать вид, что ничего не было - и в этом сила штатного механизма выбора GRUB, который до сих пор самый недооценённый настольный инструмент.
Особенные случаи, systemd-boot, zfs и проприетарный драйвер видео
Три частых подводных камня заслуживают отдельной оговорки. На системах с systemd-boot новое ядро регистрируется в ESP иначе, чем с GRUB: kernel-install сам раскладывает файлы, но запись fallback иногда требуется руками - проверяйте после установки, что обе записи видны в меню прошивки. С системами на ZFS помните, что модуль zfs должен пересобраться под новое ядро через DKMS пакета zfs-dkms, и при капризной сборке система может остаться без корня: на таких системах порядок давно канонизирован - сначала собирается и тестируется модуль, потом настраивается загрузка, а последним действием является обновление initramfs и перезагрузка.
Проприетарный драйвер NVIDIA на mainline-ядрах это классическая трёхдневная история: драйвер выходит с поддержкой свежего API с задержкой, и импульсивный апгрейд ведёт к чёрному экрану на старте графики. Выход простой: перед обновлением ядра проверьте поддержку в примечаниях к выпуску драйвера и подождите, если номер новее поддержанного. Консерваторы для ядер и графики уживаются лучше, чем первопроходцы, и это правило не имеет срока давности.
Итог, когда обновление ядра становится рутиной
Обновление ядра на старом дистрибутиве больше не должно быть событием. С выверенной последовательностью - проверки, дистрибутивный backports или честная ваниль, DKMS наготове, сохранённый откат - процедура занимает двадцать минут и сокращает список "нас потом поддержат" до нуля. Главная дисциплина тут в том, чтобы обновляться по причине и всегда иметь путь обратно; при этих двух условиях даже консервативный дистрибутив легко несёт на себе современное железо, и техника в вашем распоряжении проживает дольше жизни своих коробок.
Отвечая на животрепещущее, mainline для сервера или нет
На сервере правила строже. Mainline kernel на проде это экзотика, потому что отсутствие дистрибутивной поддержки безопасности перекрывает фанатские выгоды драйверов. Рабочий паттерн таков: сначала backports или LTS-репозиторий вендора, затем ELRepo в случае RHEL и только последним шагом - ваниль, и то если задача действительно уникальная (новая сетевая карта, новый стек accelerators). Для боевых систем ещё более ценно тестирование на стейдже: ядро выкатывается на копию нагрузки, и только после недели чистой статистики решение переезжает в продакшен.
Домашняя лаборатория, рабочая станция и личный ноутбук - совсем другое дело: там свежая mainline-ветка уже была на десятках тысяч машин до вас, и истории поломок процента ничтожно малы. Именно в этом пропорция смысла: регулярные обновления для домашней техники и осторожные LTS-пути для серверов, по которым ходят клиенты, деньги и чужая репутация.
Памятные отметки для будущего месяца
Заведите привычку раз в месяц глянуть, какие LTS-версии сейчас на ходу: kernel.org публикует таблицу поддерживаемых веток с датами конца жизни, и заблаговременное знание о EOL вашей ветки позволяет спланировать апгрейд без авралов. Заодно стоит взглянуть на отношение модуля вашего устройства к новым версиям: популярные DKMS-проекты публикуют таблицы совместимости, и хорошая привычка держать их в закладках у тех, чьё железо зависит от сторонней сборки.
Такой подход делает обновление ядра обычным делом, а не подвигом, и именно это отличает зрелую эксплуатацию от вечного аврала: вы правите ядро потому, что задача требует, а не потому, что вышла новость.