Una historia que ha circulado en el mundo Linux durante los últimos días nos habla de un usuario de Arch Linux que decidió ejecutar un comando clásico como «rm -rf –no-preserve-root /» para ver de cerca su inevitable efecto. El problema es que dicho usuario recibió mucho más de lo que esperaba: Su instalación de Arch se encontraba sobre un ordenador portátil MSI cuyo firmware al parecer no estaba tan protegido como debería. Consecuencia: Un portátil fuera de combate.
Cada vez que realizamos una actualización de BIOS o firmware, automáticamente se nos hace un pequeño nudo en la garganta. La razón es que si llegamos a sufrir una pérdida de energía eléctrica durante el proceso, lo más probable es que nuestra pieza de hardware pase a un retiro casi permanente. Digo «casi», porque existe la remota posibilidad de «re-flashear» un chip o ingresar en un modo más profundo de recuperación que nos permita hacerlo regresar de las tinieblas. Aún así, no es una experiencia agradable, y en esta época de firmwares dinámicos con actualizaciones frecuentes sumados a bugs inesperados, hay suficientes razones para preocuparse.
Algo muy similar afectó a un usuario de Arch Linux, identificado en el foro oficial como «9233». Lamentablemente, su publicación original ya no se encuentra disponible, pero la magia del caché nos deja ver que pasó: En el mensaje original explica que decidió eliminar su instalación actual de Arch porque estaba un poco «hinchada», pero en vez de utilizar un método tradicional, decidió desmontar todas las particiones críticas, y ejecutar el comando «rm -rf –no-preserve-root /». Esto debería haber purgado esa instalación de Linux y nada más… sin embargo, su ordenador portátil jamás respondió. El modelo en cuestión es MSI GP60 2PE Leopard, un sistema con especificaciones muy interesantes, pero no posee nada que transmita la idea de problemas más serios. Entonces… ¿qué sucedió?
Después de intercambiar varios mensajes con otros usuarios, se llegó a la conclusión de que el comando hizo volar por los aires a «/sys/firmware/efi/efivars/», directorio que contiene scripts y datos adicionales para que un ordenador bajo el estándar UEFI se inicie correctamente. Ante la falta de esos datos, el portátil MSI no pudo hacer más que quedarse en silencio, disparando de inmediato un intenso debate: ¿Quién tiene la culpa? Por un lado, Linux hizo exactamente lo que el usuario le pidió con ese comando, y no podemos negar que tenía opciones mucho más seguras para limpiar su instalación. Luego, noquear un ordenador manipulando de forma inapropiada a «/sys/firmware/efi/efivars/» no es algo nuevo que digamos, pero si el estándar UEFI es implementado como corresponde, debería existir alguna opción de recuperación. Finalmente, ¿tal vez el comando rm es demasiado poderoso, y se debe montar efivars en modo de sólo lectura? Los comentarios están abiertos.
