Hace un mes nos hicimos eco de uno de los mayores desastres protagonizados por un sistema operativo GNU/Linux, el hecho de que Ubuntu 17.10 estuviese corrompiendo las BIOS de muchos modelos de portátiles, sobre todo de Lenovo.
Cuando las incidencias fueron reportadas, a Canonical no le quedó otra que eliminar la imagen de instalación de Ubuntu 17.10 de su web, algo que también afectó a los distintos “sabores” (Kubuntu, Xubuntu… ) debido a que el error no era provocado por el entorno de escritorio, sino por el driver Intel SPI incluido en Linux 4.13. El problema era y es bastante serio, ya que en caso de corromper la BIOS hasta el extremo de ser irrecuperable, la única solución que queda es el cambio de placa madre si el correspondiente chip no era reemplazable. Los usuarios afectados han reportado situaciones en las cuales no podían modificar la configuración de la BIOS o bien ni siquiera arrancar su computadora.
Ahora son los responsables de Everyday Linux User los que intentan arrojar cierta luz a un escándalo que no solo dejó en un mal lugar a Ubuntu, sino también todo el ecosistema de GNU/Linux para el escritorio. Lo primero que se puede resaltar es que el problema no es exclusivo de Ubuntu 17.10, sino que según un usuario que participó en el reporte del bug, también afectaba a otras distribuciones como Antergos.
Sin embargo, el centro del debate ha sido saber quién tenía al final la culpa, si los desarrolladores de Ubuntu o bien Lenovo y otros fabricantes por no incluir implementaciones BIOS lo suficientemente “fortificadas” frente a este tipo de incidencias. En Everyday Linux User se mojan señalando más a los fabricantes que a Canonical, porque si el sistema operativo tiene acceso para modificar la BIOS, no hay nada que indique que esto mismo no pueda ser causado por “un virus en una instalación de Windows que consiga el mismo efecto”, según su argumentación.
Profundizando un poco más, señalan a un tipo de BIOS en particular llamado Insyde, presunto responsable de las incidencias ocurridas con Linux. Los fabricantes no se dedican a fabricar ellos mismos todos los componentes incluidos en sus ordenadores, sino que los encargan a otras empresas, y si encargan un tipo de BIOS defectuoso o no confiable, podría ser la desarrolladora de este componente la culpable del problema.
Yendo más allá de la frustración humana, porque el hecho de que el ordenador deje de funcionar siempre provocará un gran cabreo en el usuario, también es interesante señalar a la revista Linux User & Developer, que ha estado distribuyendo con los números de noviembre y diciembre de 2017 un DVD con Ubuntu 17.10. Obviamente, la revista nunca tendría intención de romper (mediante software) el ordenador de nadie, pero que un medio con repercusión se dedique a expandir un problema de este calibre de forma involuntaria no ayuda a su prestigio ni a la del sistema que promociona.
Otros, quizá dejándose llevar por la frustración, han llevado a cabo medidas extremas. Toninetto, otro usuario que comentó en el bug de Launchpad, comentó lo siguiente:
He tenido el mismo problema. Después de intentar diferentes soluciones, he tenido que quitar el chip de la BIOS con aire caliente, leer el contenido con un programador USB y flashear un nuevo chip. Ahora puedo eliminar Secure Boot y guardar los cambios al salir… Sé que es una solución extrema, pero espero poder ayudar a alguien a encontrar una solución más simple.
Por otro lado, desde Everyday Linux User repiten un consejo que ya publicamos hace años en MuyLinux, la de utilizar las versiones LTS en lugar de las que tienen solo nueve meses de soporte. Sin embargo, hay usuarios que utilizan hardware muy reciente y posiblemente necesiten de una versión reciente para tener buen soporte en este apartado, aunque también se puede instalar un kernel más reciente desde los repositorios de Ubuntu (en Ubuntu 16.04 se puede instalar Linux 4.13).
Como vemos, no queda del todo claro quién tiene la culpa en todo este asunto, sobre todo porque se pudo, al menos aparentemente, haber abordado desde distintos frentes. Canonical (y otros desarrolladores de distribuciones GNU/Linux) podrían no haber incluido Intel SPI, Intel podría haber probado más el mencionado driver y el desarrollador de las BIOS afectadas podría haber puesto más barreras, o al menos eso desprende el artículo publicado por Everyday Linux User.
Terminamos recordando que las imágenes corregidas de Ubuntu 17.10 serán publicadas el jueves de esta semana, concretamente el 11 de enero de 2017.
