Вышло ядро Linux 6.0 RC5. Что нового?

Linux 6.0 RC5 — пятый кандидат в релизы в цикле 6.0. Если первые RC посвящены поиску грубых ошибок после merge window, то середина цикла — время, когда ядро уже загружается на большинстве машин, но отдельные подсистемы ещё преподносят сюрпризы. Для тестировщика это удобный момент: код достаточно зрелый, чтобы проверять реальные сценарии, и ещё есть время, чтобы исправления попали в финальный релиз.

Разберём, чем RC5 отличается от RC1, какие проверки имеют смысл и как сообщить о проблеме так, чтобы её действительно исправили.

Где находится RC5 в цикле

После закрытия окна слияния Линус Торвальдс выпускает RC1, затем примерно раз в неделю — следующие кандидаты. К пятому выпуску проходит около шести недель стабилизации. Мейнтейнеры подсистем присылают только исправления, новые функции не принимаются.

Именно поэтому RC5 обычно стабильнее ранних сборок: крупные регрессии уже найдены, а оставшиеся проблемы чаще касаются конкретного оборудования или редких конфигураций. Но это не значит, что RC5 безопасно ставить на рабочий ноутбук — обновлений безопасности для промежуточных сборок нет.

Что обычно меняется между RC4 и RC5

В этот период правят драйверы (графика, сеть, хранилища), файловые системы и подсистему памяти. Часто появляются исправления для новых платформ: ARM-платы, ноутбуки с свежими чипсетами, устройства с USB4 и Thunderbolt. Для владельца такого железа RC5 может впервые заработать там, где стабильное ядро дистрибутива ещё не видит устройство.

Отдельный пласт — исправления регрессий. Если что-то работало в 5.19 и перестало в 6.0-rc1, к RC5 это обычно уже нашли и починили. Проверить историю можно в списке рассылки LKML или в git-логе по подсистеме.

Кому имеет смысл тестировать

• владельцам нового оборудования, которое плохо работает на текущем ядре;
• разработчикам драйверов и мейнтейнерам подсистем;
• тестировщикам, которые ведут список проверок и умеют собирать логи;
• энтузиастам с отдельной машиной или виртуальной средой.

Если компьютер один и на нём работа, ставьте стабильное ядро. RC-сборки не получают патчей безопасности, а откат требует подготовки.

Как установить без риска

Самый безопасный путь — виртуальная машина. Но она не покажет работу Wi-Fi, GPU, сна и док-станции. Для проверки оборудования нужен отдельный диск или машина, которую не жалко перезагрузить.

uname -r
ls /boot/vmlinuz-*
sudo update-grub

В Ubuntu удобны mainline-пакеты, в Fedora — Rawhide или Copr, в Arch — linux-mainline из AUR. В Debian есть экспериментальный репозиторий. Устанавливайте готовые пакеты, если не хотите разбираться с конфигурацией ядра.

sudo dpkg -i linux-image-*.deb linux-headers-*.deb
sudo update-grub
sudo reboot
uname -r

После перезагрузки сразу проверьте журнал: ошибки драйверов часто видны в первых секундах загрузки.

journalctl -k -b | grep -iE "error|fail|firmware" | head -30
dmesg --level=err,warn | head -30

Сборка из git

Если нужен конкретный коммит или вы хотите проверить патч, собирайте из исходников. Начните с конфигурации текущего ядра, чтобы не потерять драйверы.

cp /boot/config-$(uname -r) .config
make olddefconfig
make -j$(nproc)
sudo make modules_install
sudo make install

Сборка занимает от десятков минут до нескольких часов. Не отключайте драйвер хранилища или сети: после перезагрузки система может не подняться.

grep -E "CONFIG_(EXT4|BTRFS|NVME|E1000|IWLMVM)=" .config

Что проверять в первую очередь

1. Загрузку, выключение и перезагрузку.
2. Сон и гибернацию.
3. Wi-Fi, Ethernet, Bluetooth.
4. Графику, несколько мониторов, масштабирование.
5. Звук, микрофон, наушники.
6. NVMe/SATA, SMART, температуру.
7. Контейнеры и виртуальные машины.

lspci -nnk | grep -A3 -iE "vga|network|storage"
lsusb
sudo smartctl -a /dev/nvme0 | grep -iE "temperature|percentage"

Как оформить отчёт о регрессии

Отчёт должен позволять воспроизвести проблему без вашей машины. Укажите версию ядра, оборудование, шаги, ожидаемое и фактическое поведение. Приложите логи, но не весь dmesg — только релевантный фрагмент.

lspci -nnk > lspci.txt
lsusb > lsusb.txt
journalctl -k -b > kernel.log
cat /proc/version > version.txt

Проверьте, не воспроизводится ли проблема на предыдущем стабильном ядре. Если да, это не регрессия, а известная проблема. Если нет — вы нашли то, что важно исправить до релиза.

Стоит ли ждать финальный релиз

Для рабочей машины — да. Финальный 6.0 выйдет после RC7 или RC8, а дистрибутивы добавят его позже. Если конкретное исправление нужно уже сейчас, можно поставить RC5, но держите старое ядро в загрузчике и план отката.

Для серверов RC-ядра не подходят: нет гарантий безопасности, а поведение драйверов может меняться между кандидатами. Тестируйте на отдельном узле и переносите изменения после стабилизации.

Что делать, если тестовое ядро не загружается

Самая частая причина — отсутствие драйвера хранилища или неправильный initramfs. Если система зависает на раннем этапе, выберите предыдущее ядро в GRUB и загрузитесь в рабочую систему. Затем проверьте, что образ initramfs создан для новой версии.

ls /boot/initrd.img-*
sudo update-initramfs -u -k $(ls /boot/vmlinuz-* | tail -1 | sed 's|.*vmlinuz-||')

Для диагностики добавьте параметры загрузки nomodeset или systemd.unit=rescue.target. Это помогает отделить проблему драйвера GPU от проблемы ядра.

# в меню GRUB нажмите e и добавьте в строку linux:
# nomodeset

Если проблема повторяется только с вашим оборудованием, сохраните логи и опишите её в отчёте. Именно такие случаи помогают мейнтейнерам исправить регрессию до финального релиза.

Как организовать регулярное тестирование

Заведите простой чек-лист и прогоняйте его на каждом RC. Записывайте результат в таблицу: версия ядра, дата, что проверяли, что сломалось. Через несколько циклов станет видно, какие подсистемы нестабильны именно у вас.

#!/bin/sh
echo "kernel: $(uname -r)"
for f in /sys/devices/system/cpu/vulnerabilities/*; do
  printf "%s: " "$(basename "$f")"; cat "$f"
done
systemctl --failed --no-legend | wc -l

Такой скрипт занимает минуту и даёт воспроизводимую картину. Для парка машин его можно запускать по SSH и собирать отчёт централизованно.

Итог

Linux 6.0 RC5 — середина цикла стабилизации. Тестируйте на отдельном оборудовании, проверяйте конкретные сценарии, сохраняйте старое ядро и отправляйте подробные отчёты. Для повседневной работы дождитесь финального релиза или обновления дистрибутива.