Para ver as velocidades aproximadas para tarballar um sistema inteiro e, em seguida, restaurar esse sistema quando ele foi enganado, clonei parcialmente um de nossos sistemas primários em uma estação de trabalho que, embora não seja parte integrante dos sistemas de nossa empresa, seria bom para tem funcionamento. Cronometrei a criação do tarball de todo o sistema e o inspecionei para ter certeza de que estava bom.
Eu então corri rm -rf / --no-preserve-root. Nunca tive a oportunidade de fazer isso antes, então foi muito divertido. Inicialmente.
Quando reiniciei a caixa, nada apareceu. Nem um logotipo “Dell”, nem opções para o BIOS, nada.
Conectei a unidade a uma caixa diferente e, para meu desgosto, descobri que ela tinha uma partição UEFI. Presumo que meu Comando da Morte tenha efetivamente limpado aquela partição.
Conectei uma unidade diferente e funcional à estação de trabalho extinta, mas a estação de trabalho ainda não faz nada.
Alguém já viu algo assim ou tem sugestões sobre o que procurar? Como a execução desse rmcomando conseguiu bagunçar tanto a caixa inteira?
ATUALIZAÇÃO: Devolvemos a caixa para a Dell. Não conseguimos diagnosticar com precisão se foi uma coincidência ou a situaçãoconforme descrito por dronus. No entanto, aceitarei a resposta do dronus, pois descreve uma possível razão pela qual isso aconteceria. Além disso, alertará outros contra fazerem a mesma coisa no futuro. Se alguém encontrar algum registro da Dell usando UEFI com bugs, isso seria útil.
Responder1
Uma rara possibilidade seria você ter acionado alguns dos infames bugs UEFI, que já mataram algumas séries de notebooks Samsung e Lenovo.
Funciona assim: as especificações UEFI propõem uma memória não volátil (nvram ou eeprom) que pode ser acessada pelo sistema operacional para armazenar configurações ou informações de depuração. Na verdade, o Linux usa esse recurso no caso de kernel panic: se o sistema de arquivos raiz não for mais confiável (por exemplo, após uma exceção no código do kernel), ele será alterado para somente leitura. Agora o recurso UEFI pode ser usado e as informações de depuração são gravadas na memória não volátil. Até agora, isso parece uma boa ideia: os dados podem ser recuperados posteriormente e usados para explorar os motivos da falha.
No entanto, com algumas linhas de firmware UEFI com bugs, algumas rotinas de gerenciamento da memória de mensagens não volátil são interrompidas. Dependendo das mensagens, esses firmwares travam na inicialização da memória de mensagens, geralmente bem no início da inicialização. Eles podem nem chegar à inicialização VGA e, nesse caso, a máquina parece totalmente bloqueada. Nos casos mencionados acima, não houve solução de software e as placas-mãe tiveram que ser substituídas.
A execução rm -rf / --no-preserve-rootpode desencadear outro bug do kernel ao atravessar e excluir sistemas de arquivos do kernel como /sys, /devou /proc, que pode finalmente levar a um kernel panic, finalmente acionando o bug de memória de mensagem não volátil mencionado acima.
Responder2
Não, não é possível destruir o BIOS (legado ou UEFI) desta forma com esse comando.
Mesmo que você tenha conseguido destruir a partição UEFI, os arquivos principais do BIOS não serão afetados, pois residem na memória não volátil (principalmente baseada em flash) inserida na placa-mãe.
A partição UEFI hospeda componentes de software adicionais (por exemplo: depurador, driver, ecc), mas a máquina deve inicializar no BIOS mesmo sem uma partição UEFI válida.
Responder3
Embora seja divertido, rm -rf /ele só pode causar estragos dentro de sua própria pequena prisão - e essa é a(s) partição(ões) que lhe é dada. Ele não pode bagunçar o disco MBR, nem destruir magicamente o seu computador.
Algo mais está errado no seu caso.
Responder4
/sys/firmware/efi/efivarsé umsistema de arquivos especialcontendo todas as variáveis EFI. Se o fornecedor não seguiuMelhores Práticas, é possível que você rm -rftenha apagado os itens importantes e confundido o firmware.