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

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.

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.

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.

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.

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).

/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.