¿Podría `rm -rf / --no-preserve-root` estropear la BIOS?


35

Para ver velocidades aproximadas de tarballing un sistema completo, y luego restaurar ese sistema cuando si fuera foobar, cloné parcialmente uno de nuestros sistemas primarios en una estación de trabajo que, aunque no es parte integral de los sistemas de nuestra compañía, sería bueno tener funcionamiento Tomé el tiempo creando el tarball de todo el sistema, y ​​lo inspeccioné para asegurarme de que se veía bien.

Entonces corrí rm -rf / --no-preserve-root. Nunca he tenido la oportunidad de hacer eso antes, así que fue muy divertido. Primero.

Cuando reinicié la caja, no apareció nada. No es un logotipo de "Dell", no hay opciones para el BIOS, nada.

Conecté el disco a una caja diferente y descubrí para mi disgusto que tenía una partición UEFI. Supongo que mi Comando de la Muerte efectivamente manguera esa partición.

Conecté un disco diferente y funcional a la estación de trabajo ahora desaparecida, pero la estación de trabajo todavía no hace nada.

¿Alguien ha visto algo como esto o tiene sugerencias sobre qué buscar? ¿Cómo se ejecutó ese rmcomando para desordenar de manera tan real toda la caja?

ACTUALIZACIÓN: devolvimos la caja a Dell. No pudimos diagnosticar con precisión si fue una coincidencia o la situación descrita por Dronus . Sin embargo, aceptaré la respuesta de Dronus ya que describe una posible razón por la que esto sucedería. Además, advertirá a otros que no hagan lo mismo en el futuro. Si alguien encuentra algún registro de Dell usando UEFI con errores, sería útil.


10
¿Estaba la partición del sistema UEFI montada en el momento en que ejecutó ese comando? Si no fuera así, no debería verse afectado. Fue entonces cuando aún debería poder iniciar el firmware. La mejor GUESS es que se montó, que eliminó algún cargador de arranque y que el firmware todavía está configurado para cargar solo desde eso. Aún así, debería poder ingresar al firmware.
Hennes

@ Hennes Sí, estoy bastante seguro de que fue montado.
MirroredFate

¿Qué modelo de Dell?
Mark Plotnick

@MarkPlotnick XPS8700
MirroredFate

Intente restablecer la configuración de CMOS. Se hace moviendo un puente; No necesita quitar una batería. Página 84 en downloads.dell.com/Manuals/all-products/esuprt_desktop/… . También puede intentar presionar F2 tan pronto como parezca que ha terminado la POST para intentar llegar a una pantalla de configuración.
Mark Plotnick

Respuestas:


47

Una posibilidad rara podría ser que desencadenara algunos de los infames errores UEFI, que ya mataron algunas series de portátiles Samsung y Lenovo.

Funciona así: las especificaciones UEFI proponen una memoria no volátil (nvram o eeprom) a la que puede acceder el sistema operativo para almacenar configuraciones o depurar información. Linux en realidad usa esta característica en caso de pánico en el núcleo: si el sistema de archivos raíz ya no es confiable (por ejemplo, después de una excepción en el código del núcleo), se cambia a solo lectura. Ahora se puede utilizar la función UEFI y la información de depuración se escribe en la memoria no volátil. Hasta ahora, esto parece una buena idea: los datos pueden recuperarse más tarde y usarse para explorar los motivos del bloqueo.

Sin embargo, con algunas líneas de firmas con errores de UEFI, se rompen algunas rutinas de gestión de la memoria de mensajes no volátiles. Dependiendo de los mensajes, estos firmwares se bloquean con la inicialización de la memoria de mensajes, generalmente bastante temprano en el arranque. Es posible que ni siquiera alcancen la inicialización de VGA, en cuyo caso la máquina parece totalmente bloqueada. En los casos mencionados anteriormente, no había solución de software y las placas principales tuvieron que ser reemplazadas.

La ejecución rm -rf / --no-preserve-rootpuede desencadenar otro error del kernel al atravesar y eliminar sistemas de archivos del kernel como /sys, /devo /proc, eso finalmente puede conducir a un pánico del kernel, y finalmente desencadenar el error no volátil de la memoria de mensajes mencionado anteriormente.


55
Bueno, eso es deprimente. Pero es una explicación funcional, al menos.
MirroredFate

44
Para obtener un poco más sobre esto, consulte, por ejemplo, Cómo lidiar con las peculiaridades de memoria no volátil de UEFI y el error anterior de la computadora portátil Samsung no es específico de Linux , ambos por Matthew Garrett.
un CVn

@ MichaelKjörling Wow. Eso va en contra de todo lo que habría sospechado.
MirroredFate

2
¿Puede reemplazar la palabra "BIOS" con una palabra apropiada como "firmware" a menos que realmente se refiera al BIOS de PC de IBM? Esto no es algo de lo que normalmente soy exigente, pero en este caso realmente debes dejarlo en claro porque usas las palabras UEFI y BIOS en la misma oración (incluso una al lado de la otra), lo cual es un poco confuso.
Mehrdad

1
Reemplazado. Para la mayoría de la gente, algo que casi todavía se ve como BIOS y se siente como BIOS BIOS será para siempre ...
dronus

27

No, no es posible destruir el BIOS (heredado o UEFI) de esta manera con ese comando.

Incluso si logró destruir la partición UEFI, los archivos principales del BIOS no se verán afectados, ya que residen en la memoria no volátil (basada en flash, en su mayoría) en la placa base.

La partición UEFI aloja componentes de software adicionales (por ejemplo: depurador, controlador, ecc), pero la máquina debe arrancar con BIOS incluso sin una partición UEFI válida.


Este ha sido mi entendimiento. ¿Conoces alguna razón para ver el comportamiento que he descrito?
MirroredFate

1
Solo puedo imaginar que la estación de trabajo tenía un hardware defectuoso y que la carga (relativamente) alta impuesta por su untar / delete lo derribó. ¿Tienes que intentar volver a colocar la CPU y la memoria? ¿Intentaste borrar el CMOS?
shodanshok

1
El recuerdo, sí. Lo cual fue extraño, porque sacar la memoria ni siquiera resultó en que la computadora indicara que algo estaba mal. No he intentado volver a colocar el IPC. Intenté borrar el CMOS, pero probablemente debería dejar la batería fuera por más tiempo.
MirroredFate

Si bien es cierto, es extremadamente raro destruir realmente el hardware solo a través del software. Una excepción notable fue en la era de los CRT, donde los tiempos mal programados podían destruir la electrónica del CRT. Sin embargo, no es el caso aquí: lo peor sería una corrupción de BIOS / UEFI, que no es destrucción de hardware en sentido real. Además, el OP probó con otro disco idéntico (con la partición UEFI en su lugar) y no cambió nada. Probablemente el hardware WS ya estaba defectuoso , y la carga impuesta por el comando emitido deletreó el final.
shodanshok

10

Si bien es divertido, rm -rf /solo puede causar estragos dentro de su propia pequeña cárcel, y esas son las particiones que se le dan. No puede estropear el disco MBR, ni puede destruir mágicamente su computadora.

Algo más está mal en tu caso.


Cierto. Probablemente GPT de disco para sistemas UEFI (sin MBR, pero partición GPT. Y una partición de sistema UEFI que generalmente es FAT32).
Hennes

1
Diría que ejecutar "rm -rf / --no-preserve-root" solo es divertido en teoría. En la práctica, se cierra pronto una vez que se ha eliminado alguna biblioteca vital.
aseq

1
@aseq En realidad, en la mayoría de los casos, el programa y las bibliotecas se almacenan en caché en la memoria, tenga en cuenta que con Linux puede eliminar un programa binario mientras se está ejecutando y continuará ejecutándose hasta su finalización. En realidad, esto puede llegar bastante lejos.
Vality

Sí, lo sé, pero en algún momento vomitará. :-)
aseq

8

Las otras respuestas parecen estar de acuerdo en que limpiar el BIOS probablemente no sea su problema, así que aquí hay otro pensamiento:

Mi computadora, cuando se cambia al modo UEFI, omite la pantalla del BIOS por completo. Sin logotipo del fabricante, sin nada. Solo intenta arrancar y me dice que no hay medios de arranque (o arranques).

Si recuerdo la clave para ingresar a la configuración, puedo descifrarla cuando aparece la computadora y aún puedo acceder a la configuración del BIOS.

Si conoce la clave de configuración del BIOS, puede intentar presionarla para ingresar a la configuración, o confiar en que realmente está funcionando y restaurar su tar en el disco, luego intente arrancar. Puede ser más rápido usar algún otro medio de arranque UEFI e intentar arrancarlo si se trata de un gran tar ( se supone que Memtest86 es compatible con el arranque UEFI).


Aunque, dado que presumiblemente no está recibiendo un error de "no hay medios de arranque", la respuesta de dronus puede ser su solución en este caso. ¡Espero que no!
Sompom

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.