Canonical recordó la distribución Ubuntu 17.10 lanzada en octubre y
ocultó el enlace del sitio de descarga . La razón fue un
error crítico con daños en el BIOS en algunos modelos de computadoras portátiles Lenovo y un modelo de Acer. Actualmente se está actualizando y actualizando una lista completa de los modelos afectados.
El daño al BIOS se manifiesta en el hecho de que la nueva configuración ya no se puede guardar, y después de un reinicio, la computadora portátil comienza con la configuración anterior.
Para empeorar las cosas, el arranque desde una memoria USB se rompe porque no se reconoce USB.
A juzgar por la descripción del error, parece suceder después de la activación de los controladores intel-spi- * en el kernel. Aparentemente, estos controladores aún no están completamente desarrollados y no están listos para su uso en sistemas de usuario.
Como solución alternativa, puede intentar desactivar los controladores intel-spi- *. La descripción del error dice que las consecuencias de tales acciones serán mínimas: "Es poco probable que alguien realmente haga algo que requiera este controlador".
Lista de modelos de portátiles afectados:
- Lenovo B40-70
- Lenovo B50-70
- Lenovo B50-80
- Lenovo Flex-3
- Lenovo Flex-10
- Lenovo G40-30
- Lenovo G50-70
- Lenovo G50-80
- Lenovo S20-30
- Lenovo U31-70
- Lenovo Y50-70
- Lenovo Y70-70
- Lenovo Yoga Thinkpad (20C0)
- Lenovo Yoga 2 11 "- 20332
- Lenovo Z50-70
- Lenovo Z51-70
- Lenovo Ideapad 100-15IBY
- Acer Aspire E5-771G
Como ya se señaló, la lista está creciendo.
Los comentarios de errores también mencionan el Toshiba L50B-23G.
En muchos foros, los usuarios se quejan de este problema, porque muchas computadoras portátiles no tienen unidades de CD-ROM, por lo que ya no pueden arrancar desde otra distribución.
Especialmente muchas quejas en los foros de Lenovo. Esto es especialmente desagradable, porque a menudo son las computadoras portátiles Lenovo ThinkPad las que se recomiendan para trabajar con Linux, y Canonical las tiene en el exterior y están incluidas en la lista de equipos compatibles oficialmente.
En versiones anteriores de Ubuntu, no se produce un error.
Teóricamente, el BIOS puede actualizarse y volver a su estado original (por ejemplo, usando el programador), pero este es un procedimiento no trivial y ligeramente arriesgado. Además, no todos los usuarios tienen un programador. Por lo tanto, uno puede entender la gran insatisfacción de quienes enfrentan este problema y no pueden cargar la computadora portátil. "Esto es inaceptable, en este momento mi Lenovo G50-80 se ha convertido en un ladrillo", escribió una de las víctimas en un comentario sobre un error en el sitio web de Canonical.
UPD Nota del usuario r0mik en los comentarios al artículo: "BIOS no se deteriora" en sentido literal: el chip SPI Flash se basa en la grabación. Aparentemente, esto sucede a través del módulo del kernel mencionado anteriormente, ya que es el único que es capaz de tales acciones (para esto, también fue escrito). Precisamente porque SPI Flash está bloqueado por hardware para la grabación, no funcionará ningún modo de retroceder a la configuración estándar del BIOS, porque la configuración se almacena en SPI Flash. El programador tampoco ayudará. Solo el reemplazo físico del microcircuito ayudará ...
Canonical ahora está trabajando activamente con Lenovo para encontrar la verdadera causa del problema y lanzar el parche. Se están preparando nuevas imágenes para Ubuntu 17.10 con un kernel actualizado que no romperá el BIOS en las nuevas instalaciones.
Desafortunadamente, las nuevas imágenes no ayudarán a nadie que ya haya instalado Ubuntu 17.10 y haya dañado el firmware del BIOS. Un caso extremo es llevar una computadora portátil para repararla y reemplazar la placa base. Si la computadora portátil aún se carga, puede probar una
solución alternativa que se ofrece en los foros de soporte técnico de Lenovo.
Este usuario tampoco pudo guardar la nueva configuración del BIOS y perdió la capacidad de iniciar desde USB. Primero, verificó la secuencia de arranque de EFI. Esto se hace con el siguiente comando:
efibootmgr -vEn su caso, la secuencia de arranque se veía así:
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,0002,2001,2002,2003
Boot0001* antergos_grub HD(1,GPT,f128f12b-fa3e-45b1-b5c9-f03c328498cb,0x800,0x64000)/File(\EFI\antergos_grub\grubx64.efi)
Boot0002* Windows Boot Manager HD(1,GPT,f128f12b-fa3e-45b1-b5c9-f03c328498cb,0x800,0x64000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)RC
Boot2001* EFI USB Device RC
Boot2002* EFI DVD/CDROM RC
Boot2003* EFI Network RCDe esto se deduce que grubx64.efi del directorio antergos_grub será el primero en cargarse de cualquier manera, y solo desde el disco especificado.
Es lógico suponer que podemos controlar la descarga cambiando el contenido de la carpeta antergos_grub. Simplemente reemplazó el contenido de esta carpeta con el contenido del paquete del administrador de descargas
rEFInd , renombrando refind_x64.efi a grubx64.efi. Luego, después de cargar la computadora portátil, aparece el menú de inicio estándar rEFInd.