Le «rm -rf / – no-preserve-root» pourrait-il gâcher le bios?

Afin de voir les vitesses approximatives pour tarballing un système entier, puis la restauration de ce système si, si cela était possible, j'ai cloné partiellement l'un de nos systèmes primaires sur un post de travail qui, tout en ne faisant pas partie intégrante des systèmes de notre entreprise, serait agréable à fonctionnent. J'ai chronométré la création du tarball de l'set du système et l'ai inspecté pour m'assurer qu'il avait l'air bien.

J'ai ensuite exécuté rm -rf / --no-preserve-root . Je n'ai jamais eu l'occasion de le faire avant, donc c'était très amusant. En premier.

Lorsque j'ai redémarré la boîte, rien n'est apparu. Pas un logo "Dell", pas des options pour le BIOS, rien.

J'ai branché le lecteur dans une boîte différente, et j'ai trouvé à mon excès qu'il avait une partition UEFI. Je suppose que mon Command of Death a effectivement manqué cette partition.

J'ai branché un lecteur différent et fonctionnant vers le post de travail déjà défunté, mais le post de travail ne fait toujours rien.

Est-ce que quelqu'un a vu quelque chose comme ça ou a des suggestions quant à ce qu'il faut searchr? Comment l'exécution de cette command rm réussi à gâcher vraiment la boîte entière?

MISE À JOUR: Nous avons returnné la boîte à Dell. Nous n'avons pas pu diagnostiquer précisément si c'était une coïncidence ou la situation décrite par dronus . Cependant, j'accepterai la réponse de dronus car elle décrit une raison possible pour laquelle cela se produirait. En outre, cela mettra en garde les autres contre la même chose à l'avenir. Si quelqu'un trouve un dossier de Dell en utilisant UEFI buggy, cela serait utile.

5 Solutions collect form web for “Le «rm -rf / – no-preserve-root» pourrait-il gâcher le bios?”

Une possibilité rare pourrait être que vous avez déclenché certains des infamer UEFI bugs, qui ont déjà tué des séries de portables Samsung et Lenovo.

Cela fonctionne comme suit: les spécifications de l'UEFI proposent une memory non volatile (nvram ou eeprom) accessible par le operating system pour stocker les parameters ou les informations de debugging. Linux utilise cette fonctionnalité en cas de panique du kernel: si le système de files racine n'est plus approuvé (par exemple après une exception dans le code du kernel), il est commuté en lecture seule. Maintenant, la fonction UEFI peut être utilisée, et les informations de debugging sont écrites dans la memory non volatile. Jusqu'à présent, cela ressemble à une bonne idée: datatables peuvent être récupérées plus tard et utilisées pour explorer les raisons du crash.

Cependant, avec certaines lignes de buggy UEFI firwares, certaines routines de memory management de messages non volatile sont interrompues. Selon les messages, ces firmwares se bloquent lors de l'initialisation de la memory des messages, généralement très tôt lors du démarrage. Ils peuvent même ne pas atteindre l'initialisation VGA, auquel cas la machine semble totalement brique. Dans les cas mentionnés ci-dessus, il n'y avait pas de solution logicielle et les maps mères devaient être remplacées.

L'exécution de rm -rf / --no-preserve-root peut triggersr un autre bogue du kernel lorsque vous traversez et supprimez des filesystems du kernel comme /sys , /dev ou /proc , ce qui peut finalement conduire à une panique du kernel, déclenchant finalement le bogue de memory de message non volatile mentionné au dessus.

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

Même si vous avez quelque peu réussi à détruire la partition UEFI, les files BIOS de base ne seront pas affectés, car ils résident dans une memory non volatile (basée sur flash, principalement) sur 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 sur le BIOS même sans partition UEFI valide.

Bien que fun, rm -rf / ne peut que briser un ravissement dans sa propre petite prison – et c'est la partition (s) elle est donnée. Il ne peut pas gâcher le disque MBR, ni il ne peut pas détruire par magie votre ordinateur.

Quelque chose d'autre est fausse 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:

Mon ordinateur, lorsqu'il est mis en mode UEFI, ignore complètement l'écran du BIOS. Pas de logo du fabricant, pas rien. Il tente simplement de démarrer et me dit qu'il n'y a pas de support de démarrage (ou de bottes).

Si je me souviens de la key pour entrer dans la configuration, je peux la bloquer à mesure que l'ordinateur arrive, et je peux encore entrer dans les parameters du BIOS.

Si vous connaissez la key de configuration du BIOS, vous pouvez essayer de l'entrer pour entrer dans l'installation, ou croire qu'il fonctionne réellement et restaurer votre tar sur le disque, puis essayer de démarrer. Il est peut-être plus rapide d'utiliser une autre partie de média boiteuse UEFI et essayer de démarrer que si c'est un énorme tar ( Memtest86 est censé supporter le démarrage UEFI).

/sys/firmware/efi/efivars est un système de files spécial contenant toutes les variables EFI. Si le fournisseur n'a pas suivi les meilleures pratiques , il est possible que votre rm -rf effacé des éléments importants et ait donc confondu le microprogramme.

  • L'image de démarrage WDS ne veut pas démarrer
  • CentOS 7 et Hyper-V
  • Images (p. Ex. Avec Clonezilla) de Windows et Linux sur un ordinateur UEFI
  • Esxi hypervisor install: uefi ou bios?
  • Menu UEFI netboot
  • Serveur 2012 R2 FSRM ID d'événement 8197 Erreur: GetVolumeNameForVolumeMountPoint, 0x800700001, fonction incorrecte
  • Comment effectuer une conversion P2V d'un système EFI Windows Server 2008 R2?
  • Reimagez un Hyper V Gen 2 / UEFI VM
  • Architecture PXE: "BC EFI"
  • Convertir de UEFI en BIOS hérité dans Windows Server 2012
  • Installation du server 2012R2 sur VM avec des problèmes de disque dur GPT
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de rĂ©seau.