Soluciona “Se requiere actualización del kernel de WSL” de forma limpia

Qué significa realmente el error (y qué no significa)

“Se requiere actualización del kernel de WSL” es Windows diciéndote que el kernel de Linux usado por WSL2 falta, es demasiado antiguo o es incompatible con los componentes de WSL actualmente instalados. No se está quejando de tus paquetes de Ubuntu. No te está pidiendo que ejecutes apt upgrade. Es la plataforma WSL diciendo: “No puedo arrancar el entorno tipo VM porque la pieza del kernel no está en el estado que espero”.

En la práctica normalmente es uno de estos casos:

• La aplicación WSL (versión de Store) se actualizó pero el paquete del kernel no, por lo que la app espera una interfaz de kernel más nueva.
• Windows se actualizó y WSL ahora es más estricto con la versión o la ubicación del kernel.
• No está instalado el kernel de WSL2 (común en imágenes antiguas, instalaciones offline o máquinas que omitieron el MSI del kernel).
• No hay virtualización disponible (la pila Hyper-V no está activa, se cambiaron políticas de VBS, se alteró la BIOS o la característica de Plataforma de Máquina Virtual está desactivada), y el mensaje de error es simplemente el primero que ves.
• Endurecimiento corporativo bloqueó la Store, bloqueó descargas o ancló componentes en una combinación incómoda.

Si tratas esto como un “problema de Linux”, perderás tiempo. Esto es un problema de alineación de componentes de Windows. La solución es alinear: características de Windows, app WSL, kernel y virtualización.

Una idea parafraseada del mundo de la fiabilidad: idea parafraseada — John Allspaw a menudo enfatiza que los incidentes tratan sobre sistemas, no errores individuales. Este error es una desalineación del sistema disfrazada de un único mensaje.

Broma #1: Los errores de WSL son como las impresoras de oficina: no fallan cuando estás aburrido, fallan cuando te quedan cinco minutos para la entrega.

Datos interesantes y breve historial que puedes usar

Saber cómo llegó WSL hasta aquí te ayuda a depurarlo más rápido. Algunos hechos concretos que importan en operaciones del mundo real:

1. WSL1 vs WSL2 son fundamentalmente diferentes: WSL1 traduce llamadas al sistema de Linux; WSL2 ejecuta un kernel Linux real en una VM ligera. “Se requiere actualización del kernel” es un problema de clase WSL2.
2. El kernel de WSL2 lo mantiene y entrega Microsoft (es una compilación del kernel Linux con integración específica para WSL). No estás compilando el tuyo a menos que decidas hacerlo.
3. Antes el kernel de WSL se instalaba mediante un paquete MSI separado de las Windows Updates. Ese legado sigue apareciendo en entornos empresariales e imágenes offline.
4. WSL se movió a la Microsoft Store para actualizaciones más rápidas e independientes de las versiones completas del SO. Eso es bueno para la velocidad y malo para flotas bloqueadas a menos que lo planifiques.
5. “wsl.exe” es el plano de control: puede informar versiones, gestionar distros, establecer predeterminados y actualizar WSL. La mayoría de las “soluciones” deberían empezar con él, no con reinstalaciones aleatorias.
6. Docker Desktop empujó a muchas organizaciones hacia WSL2 porque es la opción práctica para contenedores locales en Windows. Por eso los problemas de kernel de WSL suelen aparecer como “Docker está roto”.
7. La seguridad basada en virtualización (VBS) y las configuraciones del hipervisor pueden afectar si WSL2 puede iniciar o no. Tu kernel puede estar perfecto y aun así no arrancar.
8. El kernel de WSL vive fuera del sistema de archivos de tu distro. Resetear Ubuntu no arreglará un kernel faltante. Puede que simplemente borres tus datos mientras el problema real persiste.
9. WSLg (aplicaciones GUI) se apoya en la misma infraestructura. Una desalineación del kernel puede romper no solo shells y contenedores, sino también apps GUI de Linux en Windows.

Ese es el encuadre. Ahora arreglémoslo como adultos.

Guion de diagnóstico rápido

Cuando estás de guardia por la productividad de desarrolladores (sí, eso existe), no empiezas reinstalando. Empiezas con un embudo de tres preguntas:

1) ¿Es esto una desalineación de versión del kernel de WSL2 o un fallo de virtualización?

• Si wsl --status muestra una versión del kernel y wsl -d aún falla, suele ser una desalineación app/kernel o una configuración rota de la distro.
• Si obtienes errores que mencionan virtualización, Hyper-V o códigos como 0x80370102, estás en territorio de “características de plataforma/BIOS”.

2) ¿Tu WSL se entrega vía Store o como componente incluido en Windows?

• WSL gestionado por la Store normalmente se actualiza con wsl --update (y a veces vía mecanismos de Store que no puedes ver).
• En entornos bloqueados, la Store está bloqueada, por lo que necesitas un canal de actualización aprobado offline.

3) ¿Qué cambió recientemente?

• ¿Actualización acumulativa de Windows?
• ¿Despliegue de línea base de seguridad / directiva de grupo?
• ¿Actualización de Docker Desktop?
• ¿Una actualización de BIOS/firmware que cambió ajustes de virtualización?

No lo sobrepienses. La vía más rápida es reunir los hechos mínimos y luego elegir un carril de solución: actualizar WSL, reparar características o arreglar virtualización.

Tareas prácticas: comandos, salidas y decisiones

Estas son tareas reales que ejecutaría en una máquina Windows (PowerShell) y dentro de una distro WSL (bash). Cada tarea incluye: un comando, qué significa la salida y la decisión que tomas a partir de ello.

Task 1: Confirmar que WSL está instalado y ver el estado básico

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

Significado: WSL está presente y la versión del kernel es visible. Si la línea del kernel falta o está en blanco, la instalación/actualización del kernel es sospechosa.

Decisión: Si ves una versión del kernel pero aún obtienes “kernel update required”, probablemente necesites wsl --update o una reparación. Si no ves versión del kernel, prioriza la instalación/actualización del kernel.

Task 2: Listar distros e identificar cuáles son WSL1 vs WSL2

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

Significado: Tienes múltiples distros; una es WSL1. Solo WSL2 necesita el kernel.

Decisión: Si la distro que falla es WSL2, continúa. Si es WSL1, este mensaje es una pista de que en realidad estás lanzando herramientas de WSL2 o Docker, no esa distro.

Task 3: Comprobar la versión de WSL y si usas WSL de la 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

Significado: En sistemas modernos, wsl --version existe e imprime versiones de componentes. En WSL incluido en versiones antiguas, este comando puede fallar o mostrar menos información.

Decisión: Si wsl --version no funciona, puede que estés en un WSL antiguo/inbox; actualizar vía Store puede ser necesario (o estar bloqueado), así que planifica en consecuencia.

Task 4: Intentar una actualización limpia de los componentes de WSL

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

Significado: WSL se actualizó correctamente (esto puede incluir el paquete del kernel según tu canal).

Decisión: Reintenta lanzar la distro que fallaba. Si sigue fallando, pasa a comprobaciones de ubicación/configuración del kernel y verificación de características.

Task 5: Apagar WSL limpiamente (no luches contra VMs zombies)

cr0x@server:~$ wsl --shutdown

Significado: Termina todas las instancias WSL en ejecución y el backend de VM ligera.

Decisión: Haz esto siempre después de actualizaciones o cambios de características. Si reiniciar lo arregla, tenías un estado de runtime obsoleto.

Task 6: Confirmar que la virtualización está disponible (verificación rápida)

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

Significado: Si aparece “Virtualization Enabled In Firmware: No”, WSL2 no arrancará independientemente de la versión del kernel.

Decisión: Si la virtualización en firmware está desactivada, corrige los ajustes de BIOS/UEFI primero. Si está activada, continúa con las comprobaciones de características de Windows.

Task 7: Verificar las características de Windows requeridas para 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

Significado: Ambas características deben estar habilitadas para WSL2. Si alguna está deshabilitada, el arranque del kernel de WSL2 puede fallar o comportarse de forma extraña.

Decisión: Si están deshabilitadas, habilítalas y reinicia. No te saltes el reinicio porque “te sientes con suerte”.

Task 8: Habilitar características faltantes (y aceptar el reinicio)

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.

Significado: Las características están habilitadas, pero el estado del sistema puede seguir requiriendo un reinicio para cargar componentes del hipervisor.

Decisión: Reinicia. Luego ejecuta wsl --status de nuevo.

Task 9: Validar la versión WSL predeterminada (no asumas)

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.

Significado: Las nuevas distros usarán WSL2 por defecto. Las existentes mantienen su versión hasta ser convertidas.

Decisión: Si tu distro objetivo es WSL1 y necesitas características de WSL2 (integración con Docker, mejor compatibilidad de syscalls), conviértela. Si solo necesitas un shell funcional rápidamente, WSL1 puede ser un escape temporal.

Task 10: Convertir una distro a WSL2 (o volver a WSL1 para contención)

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.

Significado: Esto usa un disco virtual; el tiempo de conversión depende del tamaño y I/O.

Decisión: Si la conversión falla con errores relacionados con el kernel, tu problema de plataforma/kernel es real; no sigas hurgando en la distro.

Task 11: Forzar un kernel específico (solo si sabes por qué)

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

Ejemplo de configuración que podrías encontrar o añadir:

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

Significado: Una ruta de kernel personalizada sobrescribe la predeterminada. Si ese archivo apunta a un kernel faltante o antiguo, obtendrás “kernel update required” o fallos de arranque.

Decisión: Si no pretendías usar un kernel personalizado, elimina la línea kernel= o corrige la ruta. Los kernels personalizados son un compromiso de mantenimiento, no una moda.

Task 12: Comprobar si un proxy o inspección SSL está rompiendo las actualizaciones

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)

Significado: Los mecanismos de actualización de WSL (y la entrega por Store) pueden ser sensibles a configuraciones de proxy/inspección dependiendo de la política.

Decisión: Si las actualizaciones fallan con errores de red/SSL, coordina con IT para permitir el canal de actualización. No “simplemente desactives el proxy” en un equipo gestionado a menos que te gusten las reuniones de cumplimiento.

Task 13: Mirar los registros de eventos relacionados con WSL (cuando la interfaz falla)

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

Significado: 0x800701bc se asocia comúnmente con necesitar una actualización del kernel (o paquete de kernel faltante).

Decisión: Usa el código para elegir un carril: actualización del kernel vs virtualización. Si ves códigos relacionados con el hipervisor, deja de perseguir instaladores de kernel.

Task 14: Dentro de WSL, confirmar la versión del kernel (si puedes arrancar algo)

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

Significado: Confirma qué kernel está realmente en ejecución. Si estás en ejecución, al menos el kernel está presente.

Decisión: Si Windows dice que se requiere actualización del kernel pero puedes ejecutar uname -r, puede que tengas múltiples contextos (diferente usuario, distinta instalación de WSL o un kernel personalizado para una cuenta).

Task 15: Comprobar espacio en disco en la unidad del sistema Windows (las actualizaciones de kernel también necesitan espacio)

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

Significado: Si el espacio libre es pequeño, las actualizaciones pueden fallar de maneras poco útiles.

Decisión: Si estás al límite, libera espacio primero. WSL no es especial; es otro consumidor de una unidad C: apretada.

Rutas de solución limpias (elige el carril correcto)

Hay tres carriles limpios. Elige según lo que te dijo tu diagnóstico. La peor opción es mezclarlos al azar hasta que algo cambie. Eso no es solución; es apostar con el entorno de desarrollo.

Carril A: Actualizar WSL correctamente (preferido cuando la Store está disponible)

Si tu entorno lo permite, wsl --update es la solución menos dramática. Síguelo con wsl --shutdown y un relanzamiento. Si usas Docker Desktop, reinícialo también: Docker cachea suposiciones sobre la disponibilidad de WSL.

Cuando este carril funciona, es aburrido. Lo aburrido es bueno.

Carril B: Reparar características de Windows y virtualización (preferido cuando los errores huelen a hipervisor)

Si systeminfo.exe dice que la virtualización está deshabilitada en firmware, para. Ve al BIOS/UEFI y habilita Intel VT-x/AMD-V (los nombres varían). Si la virtualización en firmware está habilitada pero WSL2 aún falla, confirma que las características de Windows estén habilitadas:

• Microsoft-Windows-Subsystem-Linux
• VirtualMachinePlatform

También ten en cuenta los controles de seguridad corporativos. VBS, Credential Guard y políticas del hipervisor pueden configurarse de maneras que aún permiten Hyper-V pero rompen el comportamiento de virtualización anidada o restringida. Tu trabajo aquí es encontrar la delta de la política, no “luchar contra Windows”.

Carril C: Canal de actualización offline/gestionado (preferido en empresas)

Aquí es donde la solución limpia se vuelve política. Si la Microsoft Store está bloqueada y las descargas salientes están restringidas, necesitas un mecanismo aprobado para actualizar WSL y su kernel. La parte técnica es fácil. La parte de proceso es por qué las flotas permanecen con versiones desalineadas.

Si eres SRE o ingeniero de plataforma que soporta estaciones de trabajo de desarrolladores, trata WSL como cualquier otra dependencia de runtime: versiona, prueba y despliega a través del mismo pipeline de parches que usas para otras herramientas. WSL deja de ser un hobby personal cuando es el backend de contenedores para la mitad de tu organización.

Broma #2: “Simplemente reinstala Windows” no es una solución; es un cambio de carrera hacia la danza interpretativa.

Tres micro-historias corporativas desde el terreno

Incidente: la suposición equivocada que saturó el service desk

Una empresa mediana desplegó un anillo de actualización de Windows que movió a varios ingenieros a una build más nueva. La aplicación WSL había sido instalada desde la Store para algunos usuarios, mientras que otros tenían el WSL antiguo incluido. El equipo de soporte asumió que WSL se comportaba como un paquete de Linux: si se rompe, actualiza la distro.

Así que la primera ola de tickets recibió el mismo consejo: “Ejecuta apt update && apt upgrade en Ubuntu.” Hizo que la gente se sintiera ocupada. No arregló la desalineación del kernel. Algunos usuarios intentaron reinstalar Ubuntu, lo que borró herramientas locales y claves SSH guardadas dentro de la distro. Seguía roto.

La segunda ola de tickets se escaló. Alguien finalmente ejecutó wsl --status y vio que la versión del kernel faltaba en las máquinas afectadas. En otras, la versión del kernel existía pero estaba por detrás de lo que la app esperaba. El mensaje de error era el mismo; el estado subyacente no lo era.

La solución real fue un despliegue controlado de wsl --update donde estaba permitido, y un paquete offline de actualización del kernel a través del sistema de distribución de software de la compañía donde la Store estaba bloqueada. Una vez que el equipo dejó de tratar WSL como “Ubuntu en Windows” y empezó a tratarlo como “una pila de virtualización gestionada por Windows”, el incidente terminó rápido.

Optimización que salió mal: “Aceleremos actualizaciones fijando versiones”

Otra organización intentó ser lista. Fijaron actualizaciones de características de Windows para reducir la rotación, mientras permitían que las apps de la Store se actualizaran libremente porque “las apps son seguras”. WSL quedó en esa categoría de “apps”. Se actualizó más rápido que el OS.

Durante un tiempo estuvo bien. Luego la app WSL recogió un cambio que esperaba un comportamiento de kernel más nuevo, mientras que la build de OS fijada y el mecanismo de entrega del kernel iban por detrás. Los ingenieros empezaron a ver “WSL kernel update required”, especialmente tras reinicios o después de que Docker Desktop se actualizara.

El equipo de plataforma respondió fijando también la app WSL. Eso redujo incidentes pero introdujo otro modo de fallo: Docker Desktop comenzó a requerir una versión de WSL más nueva para habilitar ciertas integraciones. Ahora el problema no era un shell roto; eran builds locales de contenedores que fallaban de manera confusa.

La solución eventual fue gobernanza adulta: mantener una matriz de compatibilidad probada (build de Windows ↔ versión de WSL ↔ versión de Docker Desktop) y avanzar conjuntamente en un anillo controlado. La “optimización” no fue fijar versiones. La optimización fue coordinar el cambio.

Práctica aburrida pero correcta que salvó el día: una comprobación previa simple

Una empresa financiera tenía controles estrictos en endpoints y una ventana de cambios predecible. Su equipo de ingeniería de estaciones de trabajo escribió un script de preflight que se ejecutaba en el inicio de sesión para desarrolladores y en el momento de imagen para máquinas nuevas.

Hacía tres cosas: comprobaba que la virtualización estuviera habilitada en firmware (cuando era detectable), verificaba que las características de Windows para WSL2 estuvieran habilitadas y comprobaba versiones de componentes WSL vía wsl --status. Si algo parecía mal, ofrecía una remediación dirigida: habilitar características + reinicio, o activar el flujo de actualización aprobado.

Este script no era sofisticado. No arreglaba todo automáticamente. No intentaba eludir políticas. Simplemente evitaba que las condiciones comunes de deriva llegaran al lunes por la mañana del usuario.

Cuando una ola de desajustes de kernel llegó tras un ciclo amplio de parches de OS, su volumen de tickets apenas se movió. El script lo detectó. El anillo de actualización lo gestionó. Nadie tuvo que aprender por las malas que reinstalar Ubuntu no instala el kernel de WSL.

Errores comunes: síntomas → causa raíz → solución

Esta sección existe porque la gente sigue haciendo las mismas cosas con confianza mientras el sistema sigue roto. Pongamos esos patrones fuera de su sufrimiento.

1) Síntoma: “Se requiere actualización del kernel de WSL” justo después de una actualización de Windows

Causa raíz: La app WSL o componentes del OS se actualizaron; el paquete del kernel no se actualizó o falta.

Solución: Ejecuta wsl --update, luego wsl --shutdown y reintenta. Si la Store está bloqueada, usa tu canal empresarial aprobado para instalar el paquete WSL/kernel.

2) Síntoma: wsl --update falla con errores de red/proxy

Causa raíz: Proxy corporativo/inspección SSL o restricciones de Store bloquean el canal de actualización de WSL.

Solución: Verifica el proxy con netsh winhttp show proxy. Coordina una allowlist para el mecanismo de actualización. No lo soluciones forzando la desactivación de controles de seguridad en dispositivos gestionados.

3) Síntoma: Código de error 0x80370102 o mensajes sobre Hyper-V/virtualización

Causa raíz: Virtualización deshabilitada en BIOS/UEFI, o características de Windows requeridas no habilitadas.

Solución: Confirma con systeminfo.exe. Habilita la virtualización en firmware. Habilita VirtualMachinePlatform y Microsoft-Windows-Subsystem-Linux con DISM, luego reinicia.

4) Síntoma: Solo una cuenta de usuario ve el problema

Causa raíz: Configuración por usuario como %UserProfile%\.wslconfig apunta a un kernel personalizado faltante, o distinto contexto de instalación de WSL.

Solución: Inspecciona .wslconfig y elimina/repara sobreescrituras de kernel personalizadas a menos que estén gestionadas intencionalmente.

5) Síntoma: Puedes iniciar distros WSL1 pero WSL2 falla

Causa raíz: Problema con el kernel/pila de virtualización. WSL1 no necesita la VM del kernel.

Solución: Trátalo como un problema de plataforma WSL2: actualiza WSL, habilita características y verifica virtualización.

6) Síntoma: Reinstalar Ubuntu no ayudó (y ahora tus herramientas se han ido)

Causa raíz: El kernel no está dentro de Ubuntu. Borraste una distro intentando arreglar un componente del host.

Solución: Deja de reinstalar distros. Arregla los componentes WSL del host. Restaura desde copias de seguridad si tenías algo importante dentro del sistema de archivos de la distro.

7) Síntoma: Docker Desktop dice que WSL2 es requerido, o los contenedores no arrancan

Causa raíz: Docker usa WSL2; la desalineación del kernel impide que el backend arranque.

Solución: Arregla WSL primero. Luego reinicia Docker Desktop. Si Docker se actualizó recientemente, asegúrate de que WSL esté actualizado a una versión compatible en tu política de flota.

8) Síntoma: Todo funcionaba ayer y hoy falla solo después del reinicio

Causa raíz: Cambios de características pendientes o actualizaciones no aplicadas completamente hasta el reinicio; ahora la desalineación es visible.

Solución: Ejecuta wsl --status, wsl --update y valida las características. Si togglaste características de Windows, reinicia de nuevo tras habilitarlas correctamente.

Listas de verificación / plan paso a paso

Checklist A: La solución limpia de 10 minutos (la mayoría de máquinas)

1. Ejecuta wsl --status. Confirma si se muestra una versión del kernel.
2. Ejecuta wsl --update.
3. Ejecuta wsl --shutdown.
4. Inicia la distro que fallaba: wsl -d Ubuntu (o el nombre de tu distro).
5. Si funciona, para. No sigas “ajustando”.

Checklist B: Reparación de plataforma cuando la virtualización es el verdadero problema

1. Ejecuta systeminfo.exe y lee la sección Hyper-V Requirements.
2. Si la virtualización en firmware es “No”: reinicia en BIOS/UEFI y habilita Intel VT-x/AMD-V.
3. De vuelta en Windows: verifica las características con DISM (Subsystem-Linux + VirtualMachinePlatform).
4. Habilita características faltantes con DISM.
5. Reinicia.
6. Ejecuta wsl --status otra vez, luego intenta iniciar una distro.

Checklist C: Remediación segura para empresas (Store bloqueada)

1. Reúne hechos: wsl --status, wsl --version (si está disponible), últimos 20 eventos de wevtutil para WSL.
2. Confirma tu mecanismo aprobado de actualización para WSL (software center, herramienta de gestión de endpoints, paquetes offline).
3. Aplica el paquete de actualización WSL/kernel aprobado.
4. wsl --shutdown y reinicia si tu herramienta lo requiere.
5. Valida con wsl --status. Asegúrate de que la versión del kernel esté presente y actual.
6. Documenta el conjunto de compatibilidad (build de Windows + versión de WSL + versión de Docker Desktop) para el siguiente despliegue.

Checklist D: Paquete de escalado “sigue fallando” (qué entregar a IT/SRE)

• Salida de wsl --status y wsl -l -v
• Salida de systeminfo.exe sección Hyper-V Requirements
• Salida de comprobaciones DISM para WSL y VM platform
• Últimos 20 eventos del registro operacional LxssManager
• Si está permitido el acceso a la Store y si hay un proxy forzado
• Si existe %UserProfile%\.wslconfig y contiene una ruta de kernel personalizada

Preguntas frecuentes

1) ¿Necesito actualizar paquetes de Ubuntu para arreglar “Se requiere actualización del kernel de WSL”?

No. Este error trata sobre el kernel WSL2 y componentes del lado del host. Actualizar la distro puede ser sano, pero no instalará el kernel faltante.

2) ¿Por qué ocurre esto después de actualizaciones de Docker Desktop?

Porque Docker Desktop usa WSL2 como backend en muchos sistemas. Si Docker espera características que proporciona una combinación más nueva de WSL/kernel, hará visible la desalineación de inmediato.

3) ¿Puedo simplemente cambiar a WSL1 y seguir?

A veces. WSL1 puede ser una solución táctica si solo necesitas un shell y herramientas de archivos. Pero Docker y muchos flujos modernos asumen WSL2. Trata WSL1 como contención, no como plan a largo plazo.

4) Ejecuté wsl --update y dice “Update successful,” pero aún falla. ¿Ahora qué?

Ejecuta wsl --shutdown, reinicia si habilitaste recientemente características, y revisa %UserProfile%\.wslconfig por una ruta de kernel personalizada. También inspecciona los registros de LxssManager para un código de error más específico.

5) ¿Qué significa si wsl --version no se reconoce?

Probablemente estás en un modelo WSL más antiguo donde el reporte de versión no está disponible así. Aún puedes usar wsl --status (si está presente) y comprobaciones de características de Windows. Actualizar WSL vía tu canal permitido suele ser la acción a tomar.

6) ¿Reinstalar WSL borrará mis archivos Linux?

Puede hacerlo, depende de lo que desinstales/resetees. Desregistrar una distro elimina su sistema de archivos. No hagas eso como primera respuesta. Arregla la desalineación host/kernel primero.

7) ¿Por qué falla solo una distro pero otras funcionan?

Si una distro particular está mal configurada o corrupta, puede fallar de forma independiente. Pero si el error es “kernel update required”, primero sospecha una desalineación del host/kernel, luego mira problemas por-distro.

8) ¿Es esto un problema de seguridad?

Usualmente no—es un problema de ciclo de vida/alineación de parches. Pero puede ser provocado por endurecimiento de seguridad que cambia la disponibilidad de virtualización o bloquea canales de actualización.

9) ¿Necesito tener Hyper-V habilitado?

WSL2 depende de la pila de virtualización de Windows. No necesitas necesariamente el rol completo de Hyper-V como se usa para cargas de servidor, pero sí necesitas soporte de virtualización y la característica Virtual Machine Platform.

10) ¿Cuál es la forma más limpia de evitar recurrencias?

Mantén alineados build de Windows, versión de WSL y Docker Desktop (si se usa) mediante un anillo de actualización probado. También evita sobreescrituras de kernel no gestionadas a menos que pretendas mantenerlas.

Siguientes pasos que realmente puedes hacer hoy

Arreglar “Se requiere actualización del kernel de WSL” de forma limpia tiene menos que ver con heroicidades y más con negarse a adivinar. Obtén el estado (wsl --status), actualiza el componente que está realmente mal (wsl --update o tu canal empresarial), y verifica que la plataforma pueda arrancar virtualización (systeminfo.exe + comprobaciones de características DISM).

Si soportas más que tu propio portátil, da un paso más: estandariza un conjunto de compatibilidad y desplégalo deliberadamente. WSL ya no es “solo una herramienta de desarrollo” cuando es la base para builds locales y flujos de contenedores. Es parte de producción, aunque esté bajo el escritorio de alguien.

Acciones prácticas siguientes:

• Ejecuta el guion de diagnóstico rápido en una máquina rota y en una que funcione; diferencia las salidas.
• Elimina sobreescrituras accidentales de kernel en .wslconfig a menos que estén gestionadas intencionalmente.
• Construye un pequeño script de preflight para comprobaciones de virtualización + características + versiones, y ejecútalo en el aprovisionamiento.
• Deja de decirle a la gente que reinstale Ubuntu para problemas del kernel del host. Así es como pierdes datos y confianza al mismo tiempo.