`Rm -rf / --no-preserve-root` pourrait-il gâcher le bios?

35

Afin de voir les vitesses approximatives pour archiver un système entier, puis de le restaurer quand il était masqué, j'ai partiellement cloné l'un de nos systèmes principaux sur un poste de travail qui, même s'il ne fait pas partie intégrante des systèmes de notre entreprise, serait agréable à utiliser. avoir fonctionné. J'ai chronométré la création de l'archive de tout le système et je l'ai inspectée pour m'assurer qu'elle était belle.

J'ai ensuite couru rm -rf / --no-preserve-root. Je n'avais jamais eu l'occasion de le faire auparavant, alors c'était très amusant. En premier.

Lorsque j'ai redémarré la boîte, rien ne s'est présenté. Pas un logo "Dell", pas d'options pour le BIOS, rien.

J'ai branché le lecteur à une autre boîte et constaté à mon grand chagrin qu'il avait une partition UEFI. Je suppose que ma commande de mort a effectivement arrosé cette partition.

J'ai branché un lecteur différent et fonctionnel au poste de travail aujourd'hui disparu, mais ce dernier ne fait toujours rien.

Quelqu'un a-t-il déjà vu quelque chose comme cela ou des suggestions sur ce qu'il faut rechercher? Comment l'exécution de cette rmcommande a-t-elle réussi à gâcher si royalement toute la boîte?

MISE À JOUR: Nous avons renvoyé la boîte à Dell. Nous n'avons pas été en mesure de déterminer avec précision s'il s'agissait d'une coïncidence ou de la situation décrite par dronus . Cependant, j'accepterai la réponse de dronus car elle décrit une raison possible pour que cela se produise. De plus, il mettra les autres en garde contre la même chose à l'avenir. Si quelqu'un découvre que Dell utilise un UEFI bogué, cela serait utile.

MirroredFate
la source
10
La partition système UEFI était-elle montée au moment où vous avez exécuté cette commande? Si ce n'était pas le cas, cela ne devrait pas être affecté. C'est alors que vous devriez toujours pouvoir démarrer au firmware. Le mieux, c'est qu'il a été monté, que vous avez supprimé un chargeur de démarrage et que le micrologiciel est toujours configuré pour se charger uniquement à partir de celui-ci. Néanmoins, vous devriez pouvoir entrer le firmware.
Hennes
@Hennes Ouais, je suis à peu près sûr qu'il était monté.
MirroredFate
Quel modèle Dell?
Mark Plotnick
@MarkPlotnick XPS8700
MirroredFate
Essayez de réinitialiser les paramètres CMOS. C'est fait en déplaçant un cavalier; vous n'avez pas besoin de retirer une batterie. Page 84 dans downloads.dell.com/Manuals/all-products/esuprt_desktop/… . Vous pouvez également essayer d'appuyer sur F2 dès que vous avez l'impression que le POST est terminé pour essayer d'obtenir un écran de configuration.
Mark Plotnick

Réponses:

47

Une possibilité rare pourrait être que vous ayez déclenché certains des tristement célèbres bogues de l’UEFI, qui ont déjà tué certaines séries de portables Samsung et Lenovo.

Cela fonctionne comme ceci: les spécifications UEFI proposent une mémoire non volatile (nvram ou eeprom) à laquelle le système d’exploitation peut accéder pour stocker les paramètres ou les informations de débogage. En réalité, Linux utilise cette fonctionnalité en cas de panique du noyau: si le système de fichiers racine n’est plus approuvé (par exemple, après une exception dans le code du noyau), il passe en lecture seule. Maintenant, la fonctionnalité UEFI peut être utilisée et les informations de débogage sont écrites dans la mémoire non volatile. Jusqu'ici, cela semble être une bonne idée: les données peuvent être récupérées plus tard et utilisées pour explorer les raisons d'un crash.

Toutefois, avec certaines lignes de firmes UEFI boguées, certaines routines de gestion de la mémoire de messages non volatile sont rompues. Selon les messages, ces firmwares se bloquent lors de l’initialisation de la mémoire des messages, généralement assez tôt au démarrage. Ils risquent même de ne pas atteindre l’initialisation VGA, auquel cas la machine semble totalement bâtie. Dans les cas mentionnés ci-dessus, il n'y avait pas de solution logicielle et les cartes mères devaient être remplacées.

L'exécution rm -rf / --no-preserve-rootpeut déclencher un autre bogue du noyau lors de la traversée et de la suppression de systèmes de fichiers du noyau /sys, /devou /proc, éventuellement, provoquer une panique du noyau, entraînant enfin le bogue de mémoire de message non volatile mentionné ci-dessus.

dronus
la source
5
C'est déprimant. Mais c'est une explication de travail, au moins.
MirroredFate
4
Pour en savoir plus à ce sujet, voir, par exemple, Traitement des excès de mémoire non-volatile de l'UEFI et le bogue précédent de Samsung pour ordinateur portable n'est pas spécifique à Linux , à la fois par Matthew Garrett.
un CVn
@ MichaelKjörling Wow. Cela va à l'encontre de tout ce que je soupçonnais.
MirroredFate
2
Pouvez-vous remplacer le mot "BIOS" par un mot approprié tel que "firmware", à moins que vous ne parliez réellement du BIOS IBM PC? Ce n'est pas quelque chose qui me préoccupe normalement, mais dans ce cas, vous devez vraiment préciser, car vous utilisez les mots UEFI et BIOS dans la même phrase (même l'un à côté de l'autre), ce qui est assez déroutant.
Mehrdad
1
Remplacé. Pour la plupart des gens, quelque chose qui ressemble presque toujours au BIOS et donne l'impression que le BIOS sera le BIOS pour toujours ...
dronus
27

Non, il n'est pas possible de détruire le BIOS (hérité ou UEFI) de cette manière avec cette commande.

Même si vous avez quelque peu réussi à détruire la partition UEFI, les fichiers BIOS essentiels ne seront pas affectés car ils résident dans une mémoire non volatile (basée sur la mémoire flash, pour la plupart) insérée dans votre carte mère.

La partition UEFI héberge des composants logiciels supplémentaires (par exemple: débogueur, pilote, ecc), mais la machine doit démarrer avec le BIOS même sans partition UEFI valide.

Shodanshok
la source
Cela a été ma compréhension. Connaissez-vous une raison quelconque de voir le comportement que j'ai décrit?
MirroredFate
1
Je peux seulement imaginer que le poste de travail avait un matériel défectueux et que la charge (relativement) élevée imposée par votre untar / delete l’abat. Vous devez essayer de réinstaller le processeur et la mémoire? Avez-vous essayé de vider la CMOS?
Shodanshok
1
La mémoire, oui. Ce qui était étrange, parce que sortir la mémoire n'a même pas pour résultat que l'ordinateur indique que quelque chose ne va pas. Je n'ai pas essayé de réassoir l'IPC. Essayé d'effacer le CMOS, mais devrait probablement laisser la batterie plus longtemps.
MirroredFate
Bien que vrai, il est extrêmement rare de détruire réellement du matériel via un logiciel uniquement. Une exception notable était à l'ère des tubes cathodiques, où des timings mal programmés pouvaient détruire les composants électroniques du tube cathodique. Cependant, ce n’est pas le cas ici: la pire chose à faire serait une corruption du BIOS / UEFI, qui n’est pas une destruction matérielle proprement dite. De plus, l'OP a essayé un autre disque identique (avec la partition UEFI en place) et cela n'a rien changé. Le matériel de WS était probablement déjà défectueux et la charge imposée par la commande émise s'épelle.
Shodanshok
10

Bien amusant, rm -rf / il ne peut que briser les ravages à l’intérieur de sa propre petite prison - et c’est la partition (les partitions) qui lui est attribuée. Il ne peut pas gâcher le disque MBR, ni détruire magiquement votre ordinateur.

Quelque chose ne va pas dans votre cas.

Janne Pikkarainen
la source
Vrai. Probablement disque GPT pour les systèmes UEFI cependant (pas de MBR, mais une partition GPT. Et une partition système UEFI qui est habituellement FAT32).
Hennes
1
Je dirais que lancer "rm -rf / --no-preserve-root" n'est amusant qu'en théorie. En pratique, il se ferme assez tôt une fois qu'une bibliothèque essentielle a été supprimée.
Assek
1
@aseq En fait, dans la plupart des cas, le programme et les bibliothèques sont mis en cache dans la mémoire. Notez qu'avec Linux, vous pouvez supprimer un programme binaire en cours d'exécution et le poursuivre jusqu'à son terme. Cela peut réellement aller très loin.
Vality
Oui je sais, mais à un moment donné ça va déconner. :-)
aseq
8

Les autres réponses semblent convenir que l’effacement du BIOS n’est probablement pas votre problème, alors voici une autre pensée:

Lorsque je suis en mode UEFI, mon ordinateur passe complètement à l’écran du BIOS. Pas de logo du fabricant, rien. Il essaie juste de démarrer et me dit qu'il n'y a pas de média de démarrage (ou de démarrage).

Si je me souviens de la clé pour entrer dans le programme d’installation, je peux la frapper à mesure que l’ordinateur s’allume et je peux toujours accéder aux paramètres du BIOS.

Si vous connaissez la clé de configuration du BIOS, vous pouvez essayer de la frapper pour entrer dans la configuration, ou vous assurer qu'elle fonctionne réellement et restaurer votre tar sur le disque, puis essayez de démarrer. Il serait peut-être plus rapide d’utiliser un autre support de démarrage UEFI et d’essayer de le faire s’il s’agit d’un fichier tar énorme ( Memtest86 est supposé prendre en charge le démarrage UEFI).

Sompom
la source
Bien que, dans la mesure où vous n'obtiendrez probablement pas l'erreur "pas de support amorçable", la réponse de dronus peut être votre solution dans ce cas. J'espère que non!
Sompom
2

/sys/firmware/efi/efivarsest un système de fichiers spécial contenant toutes les variables EFI. Si le fournisseur n’a pas suivi les meilleures pratiques , il est possible que vous rm -rfeffaciez celles qui étaient importantes et confondiez ainsi le micrologiciel.

Waldteufel
la source