WSL kernelBootTimeout: увеличить время ожидания запуска ядра

Что делает `kernelBootTimeout` в WSL 2

`kernelBootTimeout` относится к глобальным настройкам WSL 2. Задаёт ожидание запуска linux-ядра; по умолчанию 30000 мс. Это не то же самое, что `/etc/wsl.conf`: тот файл относится к отдельному дистрибутиву, а `.wslconfig` лежит в профиле Windows. Практический смысл настройки появляется, когда отладочное или кастомное ядро стабильно стартует дольше. Если измеримого симптома нет, значение по умолчанию обычно лучше дополнительной нестандартной переменной. Перед изменением запишите текущее состояние и тест, по которому будете сравнивать результат.

Совет: Сохраните копию `.wslconfig` и меняйте один ключ за раз. Так проще понять, что именно повлияло на систему.

Как задать `kernelBootTimeout` и применить конфигурацию

1. Откройте PowerShell и выполните `notepad $env:USERPROFILE\.wslconfig`; если файла нет, создайте его без расширения `.txt`.
2. В секции `[wsl2]` добавьте `kernelBootTimeout=60000`. Если `kernelBootTimeout` уже есть, измените существующую строку, а не создавайте дубликат.
3. Сохраните файл и закройте работающие Linux-процессы, чтобы не потерять несохранённую работу.
4. В Windows выполните `wsl --shutdown`. Простого закрытия окна терминала недостаточно, потому что VM может продолжать работать.
5. Запустите дистрибутив снова и проверьте результат: измерьте время запуска и сравните поведение пользовательского ядра со штатным.

Предупреждение: Увеличение таймаута не чинит зависшее ядро. Если результат ухудшился, верните прежнее значение, снова выполните `wsl --shutdown` и повторите исходный тест.

Как проверить эффект `kernelBootTimeout` после перезапуска

Не меняйте одновременно память, сеть, ядро и `kernelBootTimeout`. Сначала воспроизведите проблему, зафиксируйте результат, затем примените только эту правку. После перезапуска выполните тот же сценарий: измерить старт и проверить dmesg. Если улучшение не повторяется, причина может быть в службе дистрибутива, Windows-драйвере, VPN, файловой системе или другой части стека. Возврат к дефолту уменьшит число переменных и упростит следующую диагностику. Для длительного использования оставляйте параметр только при устойчивом, понятном результате.

Важно: Критерий успеха должен быть измеримым: время старта, число CPU, доступность сети, наличие модуля или созданный лог, а не ощущение «стало лучше».

Что зафиксировать до изменения `kernelBootTimeout`

Перед правкой выполните `wsl -l -v` и запишите исходное поведение. Для `kernelBootTimeout` важно иметь один повторяемый тест: измерьте время запуска и сравните поведение пользовательского ядра со штатным. Это позволит сравнить состояние до и после, а не оценивать изменение по общему впечатлению.

Как откатить `kernelBootTimeout` без переустановки дистрибутива

Верните прежнюю строку или удалите явный `kernelBootTimeout`, сохраните `.wslconfig` и выполните `wsl --shutdown`. После нового запуска WSL снова применит значение по умолчанию: 30000 мс. Файлы Linux при таком откате не удаляются.

Какая ошибка чаще всего мешает проверить `kernelBootTimeout`

Не меняйте одновременно соседние параметры `.wslconfig`. Если вместе с `kernelBootTimeout` изменить сеть, память или ядро, источник эффекта потеряется. Сначала меняйте только этот ключ, затем повторяйте тот же тест: измерьте время запуска и сравните поведение пользовательского ядра со штатным.

Когда оставить `kernelBootTimeout`, а когда откатить

• `.wslconfig` находится в `%UserProfile%` Windows
• настройка относится к WSL 2, а не WSL 1
• после изменения выполнен `wsl --shutdown`
• проверена именно исходная задача, а не случайный соседний симптом
• старое значение сохранено для быстрого отката

Что учитывать

Условия меняются. Страница отражает состояние на 2026-09-23; при расхождении с официальной документацией приоритет у первоисточника.

Источники и проверка

Фактическая часть сверена по первичным источникам (в т.ч. Advanced settings configuration in WSL). Пример и формулировки — редакция N1RO на 2026-09-23.

• Advanced settings configuration in WSL