Текст и данные · Инструкция
Как подключить кастомное ядро WSL 2 через .wslconfig
Как подключить кастомное ядро WSL 2 — это настройка глобального файла `.
Короткий ответ
Как указать custom kernel для WSL 2, проверить загрузку, понять разницу между .wslconfig и wsl.conf и безопасно откатиться.
Когда кастомное ядро действительно нужно
Стандартное ядро WSL подходит большинству пользователей и обновляется вместе с компонентами WSL. Кастомная сборка оправдана, когда нужен конкретный патч, модуль, экспериментальная опция ядра или воспроизводимая среда для разработки низкоуровневого ПО. Не стоит подменять ядро только ради «ускорения Linux»: неправильная конфигурация способна, наоборот, сломать сеть, файловые системы, GPU-интеграцию или запуск контейнеров. Перед изменением зафиксируйте текущую версию командами `wsl --version` и `uname -r` внутри Linux. Так будет понятно, к какой конфигурации возвращаться и действительно ли загрузилось новое ядро.
Совет: Храните исходный `.wslconfig` или хотя бы копию строки `kernel=`. Возврат на стандартное ядро должен занимать минуту, а не превращаться в восстановление дистрибутива.
Подключение ядра через .wslconfig
- 1. Скопируйте файл ядра в стабильный каталог Windows, например `C:\WSL\kernel\bzImage`. 2. Откройте `%UserProfile%\.wslconfig`. Если файла нет, создайте его как обычный текстовый файл без расширения `.txt`. 3. Добавьте секцию `[wsl2]` и строку `kernel=C:\WSL\kernel\bzImage`. В конфигурационных примерах Windows-пути записывают с обратными слешами; следите, чтобы путь был абсолютным. 4. Если вашей сборке нужен отдельный VHD с модулями, настройте `kernelModules=` только вместе с совместимым набором модулей. 5. Сохраните файл и выполните в PowerShell `wsl --shutdown`. 6. Запустите дистрибутив и проверьте `uname -r`, `dmesg | head` и работу нужной функции.
Важно: Изменение `.wslconfig` не применяется к уже работающей виртуальной машине WSL 2. Полный `wsl --shutdown` исключает ситуацию, когда вы тестируете старое ядро и считаете, что новое «не загрузилось».
Чем .wslconfig отличается от wsl.conf
Файлы легко перепутать из-за похожих названий. `.wslconfig` хранится в профиле Windows и задаёт параметры виртуальной машины WSL 2 целиком: ядро, память, процессоры, swap и сетевой режим. `/etc/wsl.conf` находится внутри конкретного дистрибутива и управляет его локальным поведением: пользователем по умолчанию, автомонтированием, systemd, boot-командой и другими параметрами. Поэтому строка `kernel=` в `/etc/wsl.conf` не даст нужного результата. Если установлено несколько WSL 2-дистрибутивов, выбранное через `.wslconfig` ядро относится к общей виртуальной машине, а не только к одной Ubuntu. Это важно при тестах: несовместимое ядро может затронуть сразу несколько дистрибутивов.
Параметры, которые часто путают
- `kernel=` | Путь к кастомному ядру WSL 2 | `.wslconfig`
- `kernelModules=` | VHD с модулями для кастомного ядра | `.wslconfig`
- `kernelCommandLine=` | Дополнительные параметры командной строки ядра | `.wslconfig`
- `systemd=true` | Запуск systemd в конкретном дистрибутиве | `/etc/wsl.conf`
- `[user] default=` | Пользователь по умолчанию | `/etc/wsl.conf`
Предупреждение: Если цель — просто включить systemd или ограничить память WSL, кастомное ядро не требуется. Используйте отдельную настройку для конкретной задачи.
Как безопасно откатиться
Если WSL перестал запускаться после замены ядра, сначала закройте все WSL-процессы и удалите или закомментируйте строку `kernel=` в `%UserProfile%\.wslconfig`, затем выполните `wsl --shutdown`. При следующем старте WSL должен вернуться к поставляемому Microsoft ядру. Если вы добавляли `kernelModules=` или `kernelCommandLine=`, откатывайте их вместе с кастомной сборкой, чтобы не оставить несовместимые параметры. Не трогайте `ext4.vhdx` и не импортируйте резервную копию, пока не исключили конфигурационную ошибку: данные дистрибутива и файл ядра — разные уровни системы. Для долгих экспериментов полезно держать два `.wslconfig`-варианта и переключать их осознанно, фиксируя версии ядра и WSL.
Проверка после загрузки
- `uname -r` соответствует ожидаемой сборке
- нужный модуль загружается без unknown symbol
- сеть и DNS работают
- диски `/mnt/c` и проекты доступны
- WSLg/GPU/контейнеры проверены, если вы ими пользуетесь
- есть понятный путь отката на стандартное ядро
Как тестировать кастомное ядро без хаоса
Кастомное ядро лучше проверять как отдельный релиз, а не заменять файл «на месте» без истории. Сохраните имя сборки, commit исходников, `.config` и путь к соответствующим модулям; файл ядра удобно называть с версией, например `bzImage-6.x-test1`. После загрузки сравните `uname -r`, затем проверьте именно ту функцию, ради которой делалась сборка: наличие модуля через `modinfo` и `lsmod`, сеть, WSLg, Docker или GPU-доступ. Дополнительно выполните короткий smoke-test обычных рабочих задач, потому что ядро может стартовать успешно, но ломать периферийную функцию. Если новая сборка нестабильна, не пытайтесь «чинить» дистрибутив: верните прежний путь `kernel=` или временно удалите эту строку, выполните `wsl --shutdown` и повторите проверку. Такой порядок отделяет дефект ядра от состояния Ubuntu и заметно упрощает откат. Перед финальным переходом на новую сборку повторите те же проверки после холодного запуска Windows, чтобы исключить эффект оставшегося состояния виртуальной машины.
Как проверить, что WSL действительно загрузил нужное ядро
После `wsl --shutdown` не ограничивайтесь тем, что дистрибутив снова открылся. Выполните `uname -r` и сравните вывод с ожидаемой версией сборки; при необходимости добавьте в имя ядра локальный суффикс, чтобы тестовую сборку было легко отличить от штатной. Затем проверьте именно ту функцию, ради которой ядро менялось: нужный файловый драйвер, модуль, системный вызов или поведение низкоуровневого инструмента. Если загрузка не удалась, сначала верните стандартное ядро удалением или комментированием `kernel=` в `%UserProfile%\.wslconfig`, снова выполните `wsl --shutdown` и убедитесь, что обычный WSL стартует. Только после этого разбирайте саму сборку. Не меняйте одновременно ядро, `kernelModules=`, память и сетевой режим: несколько изменений сразу лишают диагностику контрольной точки. Для повторяемого теста храните рядом исходный `.config`, commit или тег исходников и точный путь к образу ядра. Тогда откат и повторная проверка занимают несколько команд, а не восстановление всей Linux-среды.
Что учитывать
Условия меняются. Страница отражает состояние на 2026-09-20; при расхождении с официальной документацией приоритет у первоисточника.
Источники и проверка
Фактическая часть сверена по первичным источникам (в т.ч. Advanced settings configuration in WSL). Пример и формулировки — редакция N1RO на 2026-09-20.