Corrección de errores: Microsoft vuelve a hacer operativo el arranque dual Windows/Linux

Escrito por Guillaume
Fecha de publicación : {{ dayjs(1747843201*1000).local().format("L").toString()}}
Síguenos en
Este artículo es una traducción automática

Durante nueve meses, el arranque dual Windows/Linux no pudo seguir funcionando debido al bloqueo de los cargadores de arranque vulnerables a un fallo crítico.

Como explica la propia Microsoft en el registro de seguimiento del parche, el despliegue del parche de seguridad(KB5041160) había provocado un problema sustancial a varios entusiastas del arranque dual Windows/Linux. En varios casos, el arranque dual simplemente dejó de funcionar, con un mensaje de error como "Fallo en la verificación de los datos SBAT del shim: Violación de la política de seguridad. Algo ha ido muy mal: la autocomprobación de SBAT ha fallado: violación de la política de seguridad". Es un problema que ya es molesto de por sí, pero que además ha tenido el mal gusto de durar, ¡ya que se remonta a agosto de 2024!

Microsoft ha confirmado ahora, a través de la actualización KB5058385 del 13 de mayo, que el fallo ya es cosa del pasado. El parche se ha incluido en esta actualización, que se desplegó hace unos días y permite reiniciar el sistema sin necesidad de realizar ningún tipo de operación. Cabe destacar que el parche resuelve el problema en todos los sistemas que estaban afectados, es decir, Windows 10, Windows 11 y Windows Server. Según explica Microsoft, "corrige los efectos no deseados de la actualización SBAT ".

La actualización KB5041160 del pasado agosto no estaba diseñada para estropear las configuraciones multiarranque. Su objetivo era bloquear los cargadores de arranque vulnerables a un fallo crítico de GRUB2 (CVE-2022-2601). El problema era que en algunas distribuciones de Linux -lo que explicaría por qué no todos los usuarios de arranque dual se veían afectados- la versión corregida de GRUB2 no había sido integrada o, lo que es prácticamente lo mismo, no había sido firmada por Microsoft. Como resultado, el proceso de arranque seguro ya no podía funcionar correctamente. Microsoft tardó en reaccionar, por no decir otra cosa, pero está claro que no fue el único culpable.