Виправлення «WSL kernel update required» чистим способом

Що насправді означає ця помилка (і чого вона не означає)

«WSL kernel update required» — це повідомлення від Windows, що Linux-ядро, яке використовує WSL2, відсутнє, застаріле або несумісне з поточними компонентами WSL. Воно не скаржиться на ваші пакети Ubuntu. Воно не просить зробити apt upgrade. Це платформа WSL каже: «Я не можу завантажити середовище, схоже на віртуальну машину, бо компонент ядра не в очікуваному стані.»

На практиці зазвичай це одне з наступного:

• Додаток WSL (версія зі Store) оновився, але пакет ядра — ні, тож додаток очікує новішого інтерфейсу ядра.
• Windows оновився і WSL став суворішим щодо версії або розташування ядра.
• Ядро WSL2 не встановлене (часто на старіших образах, офлайн-збірках або на машинах, які пропустили MSI-пакет ядра).
• Віртуалізація недоступна (стек Hyper-V неактивний, політики VBS змінились, у BIOS вимкнено опцію або вимкнено функцію платформи віртуальної машини), і це повідомлення — лише перше, яке ви бачите.
• Корпоративне жорстке затвердження заблокувало Store, блокувало завантаження або зафіксувало компоненти в незручному несумісному стані.

Якщо ви сприйматимете це як «Linux-проблему», ви втратите час. Це проблема узгодження компонентів Windows. Виправлення — узгодити: функції Windows, додаток WSL, ядро й віртуалізацію.

Одна перефразована ідея із світу надійності: перефразована ідея — John Allspaw часто наголошує, що інциденти стосуються систем, а не окремих помилок. Ця помилка — системна невідповідність, загорнута в одне повідомлення.

Жарт №1: Помилки WSL схожі на офісні принтери: вони ламаються не коли вам нудно, а коли ви за п’ять хвилин до дедлайну.

Цікаві факти й коротка історія, яку можна використати

Розуміння, як WSL дійшов до цього стану, допоможе дебажити швидше. Кілька конкретних фактів, які мають значення в реальних операціях:

1. WSL1 і WSL2 принципово відрізняються: WSL1 транслює виклики системних викликів Linux; WSL2 запускає справжнє Linux-ядро в легкій віртуальній машині. «Потрібне оновлення ядра» — це проблема класу WSL2.
2. Ядро WSL2 підтримується й постачається Microsoft (це збірка ядра Linux з інтеграцією для WSL). Ви не компілюєте його самі, якщо не обрали такий шлях.
3. Раніше ядро WSL встановлювалося через MSI-пакет, окремо від Windows Update. Така спадщина досі присутня в підприємствах і офлайн-образах.
4. WSL перейшов у Microsoft Store для швидших оновлень незалежно від повних оновлень ОС. Це добре для швидкості і погано для заблокованих флотів, якщо це не передбачити.
5. «wsl.exe» — це плоскость керування: воно може відображати версії, керувати дистро, встановлювати за замовчуванням і оновлювати WSL. Більшість «виправлень» треба починати з нього, а не з випадкових перевстановлень.
6. Docker Desktop підштовхнув багато організацій до WSL2, бо це практичний дефолт для локальних контейнерів на Windows. Тому проблеми з ядром WSL часто видаються як «зламався Docker».
7. Безпека, заснована на віртуалізації (VBS), і налаштування гіпервізора можуть впливати на здатність WSL2 запускатись. Ваше ядро може бути ідеальним, але воно все одно не завантажиться.
8. Ядро WSL знаходиться поза файловою системою вашого дистро. Скидання Ubuntu не виправить відсутнє ядро. Воно може просто видалити ваші дані, а справжня проблема залишиться.
9. WSLg (GUI-додатки) використовує ту саму інфраструктуру. Невідповідність ядра може зламати не лише shell і контейнери, а й GUI-додатки Linux на Windows.

Ось така рамка. Тепер вирішуємо по-діловому.

Швидкий план діагностики

Коли ви на вахті за продуктивністю розробників (так, це існує), ви не починаєте з перевстановлення. Ви починаєте з воронки з трьох питань:

1) Це невідповідність версій ядра WSL2 чи збій віртуалізації?

• Якщо wsl --status показує версію ядра, а wsl -d все одно падає — часто це невідповідність додатка й ядра або злочинна конфігурація дистро.
• Якщо ви отримуєте помилки, що згадують віртуалізацію, Hyper-V або коди на кшталт 0x80370102, ви в зоні «функцій платформи/BIOS».

2) Чи ваш WSL постачається через Store чи як вбудований компонент Windows?

• WSL зі Store зазвичай оновлюється через wsl --update (і іноді через механізми Store, які ви не бачите).
• У заблокованих середовищах Store заблоковано, тому потрібен затверджений офлайн/корпоративний канал оновлення.

3) Що змінилося останнім часом?

• Кумулятивне оновлення Windows?
• Впровадження бази безпеки / групової політики?
• Оновлення Docker Desktop?
• Оновлення BIOS/прошивки, що перемкнуло налаштування віртуалізації?

Не перевантажуйтеся. Найшвидший шлях — зібрати мінімум фактів і потім обрати доріжку виправлення: оновити WSL, полагодити функції або виправити віртуалізацію.

Практичні завдання: команди, виводи та рішення

Це реальні завдання, які я виконую на Windows (PowerShell) і всередині дистро WSL (bash). Кожне завдання включає: команду, що означає її вивід, і рішення, яке з цього випливає.

Завдання 1: Підтвердити встановлення WSL і побачити базовий статус

cr0x@server:~$ wsl --status
Default Distribution: Ubuntu
Default Version: 2
WSL version: 2.1.5.0
Kernel version: 5.15.153.1-2
WSLg version: 1.0.61
MSRDC version: 1.2.5105
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.22631.3007

Значення: WSL присутній, і версія ядра видна. Якщо рядок ядра відсутній або порожній — підозра на проблему з встановленням/оновленням ядра.

Рішення: Якщо ви бачите версію ядра, але все ще отримуєте «kernel update required», ймовірно, потрібно виконати wsl --update або ремонт. Якщо ви не бачите версії ядра — в пріоритеті встановлення/оновлення ядра.

Завдання 2: Перелік дистро і визначення, які з них WSL1 чи WSL2

cr0x@server:~$ wsl -l -v
  NAME            STATE           VERSION
* Ubuntu          Stopped         2
  Debian          Running         2
  Alpine          Stopped         1

Значення: У вас декілька дистро; одне — WSL1. Лише WSL2 потребує ядра.

Рішення: Якщо проблемне дистро — WSL2, продовжуйте. Якщо це WSL1, це повідомлення підказує, що ви фактично запускаєте інструменти WSL2 або Docker, а не саме дистро.

Завдання 3: Перевірити версію WSL і чи це Store-версія

cr0x@server:~$ wsl --version
WSL version: 2.1.5.0
Kernel version: 5.15.153.1-2
WSLg version: 1.0.61
MSRDC version: 1.2.5105
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.22631.3007

Значення: На сучасних системах wsl --version існує й друкує версії компонентів. На старіших вбудованих версіях WSL ця команда може видавати помилку або давати обмаль інформації.

Рішення: Якщо wsl --version не працює, можливо, ви на старішому вбудованому WSL; оновлення через Store може бути необхідним (або заблоковано), тому плануйте відповідно.

Завдання 4: Спроба чистого оновлення компонентів WSL

cr0x@server:~$ wsl --update
Checking for updates...
Installing: Windows Subsystem for Linux
Update successful.

Значення: WSL успішно оновився (це може включати пакет ядра залежно від каналу).

Рішення: Спробуйте знову запустити проблемне дистро. Якщо все ще падає — переходьте до перевірки розташування/конфігурації ядра та верифікації функцій.

Завдання 5: Акуратно завершити роботу WSL (не боріться з зомбі-ВМ)

cr0x@server:~$ wsl --shutdown

Значення: Завершує всі запущені екземпляри WSL і бекенд легких віртуальних машин.

Рішення: Завжди робіть це після оновлень або зміни функцій. Якщо після перезапуску все запрацювало — у вас був застарілий стан рантайму.

Завдання 6: Підтвердити доступність віртуалізації (швидка перевірка)

cr0x@server:~$ systeminfo.exe
...
Hyper-V Requirements:      VM Monitor Mode Extensions: Yes
                           Virtualization Enabled In Firmware: Yes
                           Second Level Address Translation: Yes
                           Data Execution Prevention Available: Yes

Значення: Якщо відображається «Virtualization Enabled In Firmware: No», WSL2 не зможе завантажитись незалежно від версії ядра.

Рішення: Якщо в прошивці віртуалізація вимкнена — виправити налаштування BIOS/UEFI. Якщо ввімкнено — продовжуйте перевірку функцій Windows.

Завдання 7: Перевірити необхідні функції Windows для WSL2

cr0x@server:~$ dism.exe /online /get-features /format:table | findstr /i /c:"VirtualMachinePlatform" /c:"Microsoft-Windows-Subsystem-Linux"
Microsoft-Windows-Subsystem-Linux   Enabled
VirtualMachinePlatform              Enabled

Значення: Обидві функції мають бути ввімкнені для WSL2. Якщо одна з них вимкнена — запуск ядра WSL2 може падати або поводитися дивно.

Рішення: Якщо вимкнено — увімкніть і перезавантажте. Не пропускайте перезавантаження, бо «почуваєтеся щасливим» — погана ідея.

Завдання 8: Увімкнути відсутні функції (і прийняти перезавантаження)

cr0x@server:~$ dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
...
The operation completed successfully.

cr0x@server:~$ dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
...
The operation completed successfully.

Значення: Функції ввімкнено, але системний стан може вимагати перезавантаження, щоб завантажити компоненти гіпервізора.

Рішення: Перезавантажте. Потім запустіть wsl --status знову.

Завдання 9: Перевірити версію WSL за замовчуванням (не робіть припущень)

cr0x@server:~$ wsl --set-default-version 2
For information on key differences with WSL 2 please visit https://aka.ms/wsl2
The operation completed successfully.

Значення: Нові дистро матимуть за замовчуванням WSL2. Існуючі залишаються на своїй версії, поки ви їх не конвертуєте.

Рішення: Якщо ваше цільове дистро — WSL1 і вам потрібні функції WSL2 (інтеграція з Docker, краща сумісність викликів) — конвертуйте його. Якщо потрібно швидко отримати робочий shell — WSL1 може бути тимчасовим виходом.

Завдання 10: Конвертувати дистро у WSL2 (або назад у WSL1 для ізоляції)

cr0x@server:~$ wsl --set-version Ubuntu 2
Conversion in progress, this may take a few minutes...
For information on key differences with WSL 2 please visit https://aka.ms/wsl2
Conversion complete.

Значення: Це використовує віртуальний диск; час конвертації залежить від розміру й I/O.

Рішення: Якщо конвертація падає з помилками, пов’язаними з ядром — ваша проблема платформи/ядра реальна; не продовжуйте тикати дистро.

Завдання 11: Примусово вказати конкретне ядро (тільки якщо знаєте, навіщо)

cr0x@server:~$ notepad.exe %UserProfile%\.wslconfig

Приклад конфігурації, яку ви можете знайти або додати:

cr0x@server:~$ type %UserProfile%\.wslconfig
[wsl2]
kernel=C:\\WSL\\kernel
memory=8GB
processors=4

Значення: Кастомний шлях до ядра перекриває дефолтний. Якщо цей файл вказує на відсутнє або застаріле ядро — ви отримаєте «kernel update required» або помилки завантаження.

Рішення: Якщо ви не збиралися використовувати кастомне ядро — видаліть рядок kernel= або виправте шлях. Кастомні ядра — це зобов’язання по обслуговуванню, а не модне хобі.

Завдання 12: Перевірити, чи проксі або SSL-інспекція ламають оновлення

cr0x@server:~$ netsh winhttp show proxy
Current WinHTTP proxy settings:

    Proxy Server(s) :  http=proxy.corp.local:8080;https=proxy.corp.local:8080
    Bypass List     :  (none)

Значення: Механізми оновлення WSL (і доставка через Store) можуть бути чутливі до налаштувань проксі/інспекції SSL залежно від політик.

Рішення: Якщо оновлення падають з помилками мережі/SSL — координуйтеся з IT, щоб дозволити канал оновлення. Не вимикайте політики безпеки на керованому пристрої просто так.

Завдання 13: Подивитися журнали, пов’язані з WSL (коли UI брешуть)

cr0x@server:~$ wevtutil qe Microsoft-Windows-LxssManager/Operational /c:20 /rd:true /f:text
Event[0]:
  Log Name: Microsoft-Windows-LxssManager/Operational
  Source: Microsoft-Windows-LxssManager
  Event ID: 1000
  Level: Error
  Description:
  Failed to start the Linux distribution. Error: 0x800701bc

Значення: 0x800701bc часто асоціюється з необхідністю оновлення ядра (або відсутнім пакетом ядра).

Рішення: Використовуйте код для вибору доріжки: оновлення ядра проти віртуалізації. Якщо бачите коди, пов’язані з гіпервізором — перестаньте шукати інсталятори ядра.

Завдання 14: Всередині WSL підтвердити версію ядра (якщо щось запускається)

cr0x@server:~$ uname -r
5.15.153.1-microsoft-standard-WSL2

Значення: Підтверджує, яке ядро фактично працює. Якщо ви запускаєтесь — ядро щонайменше присутнє.

Рішення: Якщо Windows каже «kernel update required», але ви можете виконати uname -r, можливо, у вас кілька контекстів (інший користувач, інша інсталяція WSL або кастомне ядро для одного облікового запису).

Завдання 15: Перевірити вільне місце на диску системного диска Windows (оновлення ядра теж потребують місця)

cr0x@server:~$ dir C:\
 Volume in drive C is Windows
 Volume Serial Number is 1234-ABCD

 Directory of C:\

...
               3 File(s)      1,234,567 bytes
               0 Dir(s)  1,024,000,000 bytes free

Значення: Якщо вільного місця мало — оновлення можуть падати в незрозумілих формах.

Рішення: Якщо місця бракує — звільніть його спочатку. WSL не особливий; це просто ще один споживач переповненого диска C:.

Чисті шляхи виправлення (оберіть правильну доріжку)

Є три чисті доріжки. Обирайте залежно від того, що показала ваша діагностика. Найгірший варіант — змішувати їх навмання, поки щось зміниться. Це не налагодження; це гра в рулетку з оточенням розробника.

Доріжка A: Правильне оновлення WSL (переважно, коли доступний Store)

Якщо ваше середовище це дозволяє, wsl --update — це найменш драматичне рішення. Виконайте його, потім wsl --shutdown і перезапустіть дистро. Якщо ви використовуєте Docker Desktop — перезапустіть і його теж: Docker кешує припущення про доступність WSL.

Коли ця доріжка спрацьовує — це нудно. Нудно — добре.

Доріжка B: Ремонт функцій Windows і віртуалізації (переважно, коли помилки нагадують гіпервізор)

Якщо systeminfo.exe каже, що віртуалізація вимкнена в прошивці — зупиніться. Зайдіть у BIOS/UEFI і увімкніть Intel VT-x/AMD-V (назви відрізняються). Якщо в прошивці віртуалізація увімкнена, але WSL2 все одно падає — підтвердіть, що функції Windows ввімкнені:

• Microsoft-Windows-Subsystem-Linux
• VirtualMachinePlatform

Також майте на увазі корпоративні контролі безпеки. VBS, Credential Guard і політики гіпервізора можуть бути налаштовані так, що Hyper-V працює, але ламає вкладену чи обмежену поведінку віртуалізації. Ваше завдання — знайти політичний дефект, а не «боротися з Windows».

Доріжка C: Офлайн/керований канал оновлення (переважно в підприємствах)

Тут чисте виправлення стає політичним. Якщо Microsoft Store заблоковано, й зовнішні завантаження обмежені, потрібен погоджений механізм оновлення WSL і його ядра. Технічна частина проста. Процесна частина — чому флот залишається на несумісних версіях.

Якщо ви SRE або інженер платформи, що підтримує робочі станції розробників, ставтеся до WSL як до будь-якої іншої залежності рантайму: версіонуйте її, тестуйте й розгортайте через той самий патч-пайплайн, який ви використовуєте для іншого ПЗ. WSL перестає бути персональним хобі, коли він стає бекендом контейнерів для половини інженерної організації.

Жарт №2: «Просто перевстановіть Windows» — це не виправлення; це поворот кар’єри у бік експресивного танцю.

Три корпоративні міні-історії з польових боїв

Інцидент: неправильне припущення, яке засвітило службу підтримки

Середня компанія розгорнула кільце оновлень Windows, що перевела частину інженерів на новіший збір. Додаток WSL був встановлений через Store для деяких користувачів, тоді як інші мали старий вбудований WSL. Служба підтримки припустила, що WSL поводиться як Linux-пакет: якщо він ламається — оновіть дистро.

Отже перша хвиля звернень отримала ту саму пораду: «Запустіть apt update && apt upgrade в Ubuntu.» Це дало відчуття зайнятості. Але це не виправило невідповідність ядра. Декілька користувачів перевстановили Ubuntu, що видалило локальні інструменти й SSH-ключі, що зберігались всередині дистро. Проблема лишилась.

Друга хвиля звернень була ескалована. Хтось нарешті запустив wsl --status і побачив відсутню версію ядра на уражених машинах. В інших ядро було, але застаріле відносно того, що очікував додаток. Повідомлення було однаковим; стан — різний.

Фактичне виправлення — контрольований rollout wsl --update там, де дозволено, і окремий офлайн-пакет оновлення ядра через корпоративну систему розповсюдження там, де Store заблоковано. Коли команда припинила ставитися до WSL як «Ubuntu на Windows» і почала ставитися як «віртуалізаційний стек, яким керує Windows», інцидент швидко завершився.

Оптимізація, що відкотилась: «Швидкіше оновлення шляхом фіксації версій»

Інша організація намагалася бути хитрою. Вони зафіксували оновлення функцій Windows, щоб зменшити хвилі змін, а додатки в Store дозволили оновлюватись вільно, бо «додатки безпечні». WSL потрапив у корзину «додатків». Воно оновлювалось швидше за ОС.

Поки що це працювало. Потім додаток WSL отримав зміну, яка очікувала новішої поведінки ядра, тоді як зафіксована збірка ОС і механізм доставки ядра відставали. Інженери почали бачити «WSL kernel update required», особливо після ребуту або після оновлення Docker Desktop.

Команда платформи відреагувала фіксацією версії WSL також. Це зменшило інциденти, але породило інший режим відмов: Docker Desktop почав вимагати новішу версію WSL для деяких інтеграцій. Тепер проблема була не в оболонці — а в локальних збірках контейнерів, що падали без очевидної причини.

Кінцеве вирішення — доросла керованість: підтримувати протестовану матрицю сумісності (збірка Windows ↔ версія WSL ↔ версія Docker Desktop) і просувати їх разом у контрольованому кільці. Оптимізація — не фіксація; оптимізація — координування змін.

Нудна але правильна практика, що врятувала день: простий preflight-чек

Фінансова компанія мала жорсткі контролі кінцевих точок і передбачуване вікно змін. Їхня команда інженерів робочих станцій написала preflight-скрипт, який запускався при логіні розробників і при іміджингу нових машин.

Він робив три речі: перевіряв, чи віртуалізація увімкнена в прошивці (де це можна визначити), верифікував функції Windows для WSL2 і перевіряв версії компонентів WSL через wsl --status. Якщо щось було не так, він пропонував цільове виправлення: увімкнути функції + перезавантажити або запустити погоджений робочий процес оновлення.

Цей скрипт не був крутим. Він не виправляв усе автоматично. Він не намагався перехитрити політику. Він просто не дозволяв поширеним умовам дрейфу дійти до ранкового понеділка користувача.

Коли хвиля невідповідностей ядер вдарила після загального циклу патчів ОС, кількість тикетів майже не змінилась. Скрипт зловив це. Кільце оновлень опрацювало. Нікому не довелось вчитися на власних помилках, що перевстановлення Ubuntu не встановлює ядро WSL.

Поширені помилки: симптом → коренева причина → виправлення

Цей розділ існує, бо люди продовжують робити одні й ті ж речі з впевненістю, поки система лишається поламаною. Давайте покінчимо з цими шаблонами.

1) Симптом: «WSL kernel update required» відразу після оновлення Windows

Коренева причина: Додаток WSL або компоненти ОС оновилися; пакет ядра не оновився або відсутній.

Виправлення: Запустіть wsl --update, потім wsl --shutdown, і спробуйте ще раз. Якщо Store заблоковано — використайте корпоративний канал оновлення для інсталяції затвердженого пакета WSL/ядра.

2) Симптом: wsl --update падає з помилками мережі/проксі

Коренева причина: Корпоративний проксі/SSL-інспекція або обмеження Store блокують канал оновлення WSL.

Виправлення: Перевірте проксі через netsh winhttp show proxy. Координуйте allowlist для механізму оновлення. Не ламаючи політики безпеки на керованих пристроях.

3) Симптом: код помилки 0x80370102 або повідомлення про Hyper-V/віртуалізацію

Коренева причина: Віртуалізація вимкнена в BIOS/UEFI, або потрібні функції Windows не ввімкнені.

Виправлення: Підтвердіть через systeminfo.exe. Увімкніть в прошивці віртуалізацію. Увімкніть VirtualMachinePlatform і Microsoft-Windows-Subsystem-Linux через DISM, потім перезавантажте.

4) Симптом: тільки один обліковий запис користувача бачить проблему

Коренева причина: Персональна конфігурація, як-от %UserProfile%\.wslconfig, вказує на відсутнє кастомне ядро, або різний контекст інсталяції WSL.

Виправлення: Перевірте .wslconfig і видаліть/виправте кастомні шляхи до ядра, якщо вони не керуються навмисно.

5) Симптом: запускаються тільки WSL1-дистро, а WSL2 падає

Коренева причина: Проблема зі стеком ядра/віртуалізації. WSL1 не потребує VM-ядра.

Виправлення: Розглядайте як проблему платформи WSL2: оновіть WSL, увімкніть функції, перевірте віртуалізацію.

6) Симптом: перевстановлення Ubuntu не допомогло (і тепер ваші інструменти зникли)

Коренева причина: Ядро не знаходиться всередині Ubuntu. Ви видалили дистро, щоб виправити хост-компонент.

Виправлення: Перестаньте перевстановлювати дистро. Виправте компоненти WSL хоста. Відновіть із бэкапів, якщо всередині дистро було щось важливе.

7) Симптом: Docker Desktop каже, що потрібен WSL2, або контейнери не стартують

Коренева причина: Docker використовує WSL2; невідповідність ядра заважає бекенду завантажитись.

Виправлення: Спочатку виправте WSL. Потім перезапустіть Docker Desktop. Якщо Docker нещодавно оновився — переконайтеся, що WSL оновлено до сумісної версії у вашому флоті.

8) Симптом: вчора все працювало, а сьогодні після ребуту — падає

Коренева причина: Очікувані зміни функцій або оновлення повністю не застосувалися до перезавантаження; тепер невідповідність стала видимою.

Виправлення: Запустіть wsl --status, wsl --update і верифікуйте функції. Якщо ви перемикали функції Windows — перезавантажтесь ще раз після їх коректного увімкнення.

Контрольні списки / покроковий план

Контрольний список A: Чисте 10-хвилинне виправлення (більшість машин)

1. Запустіть wsl --status. Підтвердіть, чи показано версію ядра.
2. Запустіть wsl --update.
3. Запустіть wsl --shutdown.
4. Запустіть проблемне дистро: wsl -d Ubuntu (або назва вашого дистро).
5. Якщо працює — зупиняйтесь. Не «налаштовуйте далі» просто так.

Контрольний список B: Ремонт платформи, коли віртуалізація — реальна проблема

1. Запустіть systeminfo.exe і прочитайте розділ Hyper-V Requirements.
2. Якщо в прошивці віртуалізація «No»: перезавантажтесь у BIOS/UEFI і увімкніть Intel VT-x/AMD-V.
3. У Windows: перевірте функції через DISM (Subsystem-Linux + VirtualMachinePlatform).
4. Увімкніть відсутні функції через DISM.
5. Перезавантажте.
6. Знову запустіть wsl --status і спробуйте стартувати дистро.

Контрольний список C: Підхід безпечний для підприємств (Store заблоковано)

1. Зберіть факти: wsl --status, wsl --version (якщо доступно), останні 20 подій WSL через wevtutil.
2. Підтвердіть ваш затверджений механізм оновлення WSL (software center, інструмент управління кінцевими точками, офлайн-пакети).
3. Застосуйте затверджений пакет оновлення WSL/ядра.
4. wsl --shutdown і перезавантаження, якщо вимагає ваше ПЗ.
5. Перевірте через wsl --status. Переконайтесь, що версія ядра присутня й актуальна.
6. Задокументуйте набір сумісності (збірка Windows + версія WSL + версія Docker Desktop) для наступного розгортання.

Контрольний список D: «Залишилось не працювати» пакет для ескалації (що передати IT/SRE)

• Вивід wsl --status і wsl -l -v
• Вивід systeminfo.exe розділ Hyper-V Requirements
• Вивід перевірок DISM для WSL і VM platform
• Останні 20 подій із журналу LxssManager operational
• Чи дозволено доступ до Store і чи застосовано проксі
• Чи існує %UserProfile%\.wslconfig і чи містить він кастомний шлях до ядра

FAQ

1) Чи потрібно оновлювати пакети Ubuntu, щоб виправити «WSL kernel update required»?

Ні. Ця помилка стосується ядра WSL2 і компонентів на боці хоста. Оновлення дистро може бути корисним, але воно не встановить відсутнє ядро.

2) Чому це відбувається після оновлення Docker Desktop?

Бо Docker Desktop на багатьох системах використовує WSL2 як бекенд. Якщо Docker очікує функції WSL, які надаються новішим поєднанням WSL/ядра, він одразу показує невідповідність.

3) Чи можна просто переключитися на WSL1 і забути?

Іноді. WSL1 може бути тактичним обходом, якщо вам потрібна лише оболонка й файлові інструменти. Але Docker і багато сучасних робочих процесів очікують WSL2. Тримайте WSL1 як тимчасовий вихід, не як довгий план.

4) Я запустив wsl --update і воно каже «Update successful», але все одно не працює. Що робити?

Запустіть wsl --shutdown, перезавантажте, якщо ви нещодавно вмикали функції, і перевірте %UserProfile%\.wslconfig на предмет кастомного шляху до ядра. Також перегляньте журнали LxssManager для конкретнішого коду помилки.

5) Що означає, якщо wsl --version не розпізнається?

Ймовірно, у вас старіша модель WSL, де звіт про версію недоступний таким чином. Ви все ще можете використати wsl --status (якщо є) і перевірки функцій Windows. Зазвичай рух — оновлення WSL через ваш дозволений канал.

6) Чи видалить перевстановлення WSL мої файли Linux?

Може, залежно від того, що ви видаляєте/скидаєте. Від’єднання дистро видаляє його файлову систему. Не робіть цього як перший крок. Спочатку виправте несумісність хоста/ядра.

7) Чому лише одне дистро падає, а інші працюють?

Якщо конкретне дистро неправильне або пошкоджене, воно може падати окремо. Але якщо повідомлення — «kernel update required», спочатку підозрюйте несумісність хоста/ядра, потім дивіться на проблеми конкретного дистро.

8) Чи це проблема безпеки?

Зазвичай ні — це питання життєвого циклу та узгодження патчів. Але це може бути спровоковано жорстким посиленням безпеки, яке змінює доступність віртуалізації або блокує канали оновлення.

9) Чи потрібно ввімкнути Hyper-V?

WSL2 покладається на стек віртуалізації Windows. Вам не обов’язково потрібна повна роль Hyper-V, як для серверних робочих навантажень, але потрібна підтримка віртуалізації і функція Virtual Machine Platform.

10) Який найчистіший спосіб уникнути цього повторно?

Тримайте збірку Windows, версію WSL і Docker Desktop (якщо використовується) узгодженими через протестоване кільце оновлень. Також уникайте некерованих кастомних ядер, якщо ви не готові їх обслуговувати.

Наступні кроки, які ви можете зробити сьогодні

Виправлення «WSL kernel update required» чисто — це не про героїзм, а про відмову від гадань. Отримайте стан (wsl --status), оновіть компонент, який справді неправильний (wsl --update або ваш корпоративний канал), і перевірте, чи платформа може завантажити віртуалізацію (systeminfo.exe + перевірки DISM).

Якщо ви підтримуєте більше ніж власний ноутбук — зробіть ще один крок: стандартизируйте набір сумісності і розгортайте його цілеспрямовано. WSL вже не «лише інструмент розробника», коли він стає основою локальних збірок і контейнерних робочих процесів. Він частина продукції, навіть якщо стоїть під столом у когось.

Практичні наступні дії:

• Пройдіть Швидкий план діагностики на одній зламаній машині і на одній робочій; порівняйте виводи.
• Прибрати випадкові кастомні перевизначення ядра в .wslconfig, якщо вони не керуються навмисно.
• Напишіть невеликий preflight-скрипт для перевірок віртуалізації + функцій + версії і запускайте його під час підготовки машин.
• Перестаньте радити перевстановлення Ubuntu для проблем хоста з ядром. Так втрачають дані й довіру одночасно.