`Rm -rf / --no-preserv-root` potrebbe rovinare il bios?


35

Al fine di vedere le velocità approssimative per tarballare un intero sistema, e poi ripristinare quel sistema quando, se fosse stato foobar, ho clonato parzialmente uno dei nostri sistemi primari su una workstation che, sebbene non fosse parte integrante dei nostri sistemi aziendali, sarebbe bello avere funzionante. Ho cronometrato creando il tarball dell'intero sistema e l'ho ispezionato per assicurarmi che stesse bene.

Allora ho corso rm -rf / --no-preserve-root. Non ho mai avuto l'opportunità di farlo prima, quindi è stato molto divertente. All'inizio.

Quando ho riavviato il box, non è apparso nulla. Niente logo "Dell", niente opzioni per il BIOS, niente.

Ho collegato l'unità a una scatola diversa e con mio disappunto ho scoperto che aveva una partizione UEFI. Presumo che il mio Comando della morte abbia effettivamente cancellato quella divisione.

Ho collegato un'unità diversa e funzionante alla workstation ormai defunta, ma la workstation continua a non funzionare.

Qualcuno ha visto qualcosa di simile o hai suggerimenti su cosa cercare? In che modo l'esecuzione di quel rmcomando è riuscita a rovinare così regalmente l'intera scatola?

AGGIORNAMENTO: abbiamo restituito la scatola a Dell. Non siamo stati in grado di diagnosticare con precisione se fosse una coincidenza o la situazione descritta da Dronus . Tuttavia, accetterò la risposta di Dronus in quanto descrive una possibile ragione per cui ciò potrebbe accadere. Inoltre, metterà in guardia gli altri dal fare la stessa cosa in futuro. Se qualcuno trova qualche record di Dell che utilizza un UEFI difettoso, ciò sarebbe utile.


10
La partizione di sistema UEFI è stata montata al momento dell'esecuzione di quel comando? In caso contrario, non dovrebbe essere interessato. È stato quindi dovresti essere ancora in grado di avviare il firmware. la cosa migliore è che è stato montato, che hai eliminato alcuni bootloader e che il firmware è ancora impostato per caricare solo da quello. Tuttavia, dovresti essere in grado di inserire il firmware.
Hennes,

@Hennes Sì, sono abbastanza sicuro che sia stato montato.
MirroredFate

Quale modello Dell?
Mark Plotnick,

@MarkPlotnick XPS8700
MirroredFate

Prova a ripristinare le impostazioni CMOS. Viene fatto spostando un ponticello; non è necessario rimuovere una batteria. Pagina 84 in download.dell.com/Manuals/all-products/esuprt_desktop/… . Puoi anche provare a colpire F2 non appena sembra che sia POST finito per provare ad accedere a una schermata di configurazione.
Mark Plotnick,

Risposte:


47

Una rara possibilità potrebbe essere che tu abbia innescato alcuni dei famigerati bug UEFI, che hanno già ucciso alcune serie di notebook Samsung e Lenovo.

Funziona così: le specifiche UEFI propongono una memoria non volatile (nvram o eeprom) a cui il sistema operativo può accedere per memorizzare le impostazioni o le informazioni di debug. Linux attualmente utilizza questa funzionalità in caso di panico nel kernel: se il filesystem di root non è più attendibile (ad es. Dopo un'eccezione nel codice del kernel), passa a sola lettura. Ora è possibile utilizzare la funzione UEFI e le informazioni di debug vengono scritte nella memoria non volatile. Finora sembra una buona idea: i dati possono essere recuperati in un secondo momento e utilizzati per esplorare le ragioni del crash.

Tuttavia, con alcune linee di fuochi UEFI buggy, alcune routine di gestione della memoria dei messaggi non volatile vengono interrotte. A seconda dei messaggi, questi firmware si arrestano in modo anomalo all'inizializzazione della memoria dei messaggi, in genere abbastanza presto all'avvio. Potrebbero anche non raggiungere l'inizializzazione VGA, nel qual caso la macchina sembra completamente in muratura. Nei casi sopra menzionati, non esisteva una soluzione software e le schede madri dovevano essere sostituite.

L'esecuzione rm -rf / --no-preserve-rootpuò innescare un altro bug del kernel quando si attraversano ed eliminano file system del kernel come /sys, /devo /proc, che può infine portare a un panico del kernel, innescando infine il bug di memoria dei messaggi non volatile sopra menzionato.


5
Bene, è deprimente. Ma almeno una spiegazione funzionante.
MirroredFate

4
Per un po 'di più a riguardo, vedi ad esempio Gestire le stranezze di memoria non volatile UEFI e il precedente bug del laptop Samsung non è specifico di Linux , entrambi di Matthew Garrett.
un CVn del

@ MichaelKjörling Wow. Questo va contro tutto ciò che avrei sospettato.
MirroredFate

2
Puoi sostituire la parola "BIOS" con una parola appropriata come "firmware" a meno che tu non intenda realmente il BIOS del PC IBM? Questo non è qualcosa di cui di solito sono esigente, ma in questo caso devi davvero chiarirlo perché usi le parole UEFI e BIOS nella stessa frase (anche l'una accanto all'altra) che è un po 'confusa.
Mehrdad,

1
Sostituito. Per la maggior parte delle persone, qualcosa che sembra quasi ancora BIOS e sembra che il BIOS sarà BIOS per sempre ...
dronus,

27

No, non è possibile distruggere il BIOS (legacy o UEFI) in questo modo con quel comando.

Anche se in qualche modo sei riuscito a distruggere la partizione UEFI, i file BIOS principali non saranno interessati, poiché risiedono in una memoria non volatile (basata principalmente su flash) inserita nella scheda madre.

La partizione UEFI ospita componenti software aggiuntivi (ad es. Debugger, driver, ecc), ma la macchina dovrebbe avviarsi nel BIOS anche senza una partizione UEFI valida.


Questa è stata la mia comprensione. Conosci qualche motivo per vedere il comportamento che ho descritto?
MirroredFate

1
Posso solo immaginare che la workstation avesse un hardware difettoso e che il carico (relativamente) elevato imposto dal tuo untar / delete lo abbattesse. Devo provare a riposizionare CPU e memoria? Hai provato a cancellare il CMOS?
shodanshok,

1
Il ricordo, si. Il che era strano, perché togliere la memoria non ha nemmeno portato il computer a indicare che qualcosa non andava. Non ho mai provato a ricollocare l'IPC. Ho provato a cancellare il CMOS, ma probabilmente dovrebbe lasciare la batteria più a lungo.
MirroredFate

Sebbene sia vero, è estremamente raro distruggere davvero l'hardware solo tramite il software. Un'eccezione notevole era nell'era dei CRT, in cui i tempi programmati male potevano distruggere l'elettronica di CRT. Tuttavia, qui non è il caso: la cosa peggiore sarebbe una corruzione BIOS / UEFI, che non è la distruzione dell'hardware nel vero senso della parola. Inoltre, l'OP ha provato un altro disco identico (con la partizione UEFI in atto) e non ha cambiato nulla. Probabilmente l'hardware WS era già difettoso e il carico imposto dal comando emesso terminò.
shodanshok,

10

Mentre è divertente, rm -rf /può solo spezzare il caos all'interno della sua piccola prigione - e questa è la / le partizione / i che viene data. Non può rovinare l'MBR del disco, né può distruggere magicamente il tuo computer.

Qualcos'altro non va nel tuo caso.


Vero. Probabilmente GPT su disco per sistemi UEFI (nessun MBR, ma una partizione GPT. E una partizione di sistema UEFI che di solito è FAT32).
Hennes,

1
Direi che eseguire "rm -rf / --no-preserv-root" è solo divertente in teoria. In pratica si chiude abbastanza presto una volta rimossa una libreria vitale.
aseq,

1
@aseq In realtà nella maggior parte dei casi il programma e le librerie vengono memorizzati nella cache, si noti che con Linux è possibile eliminare un programma binario mentre è in esecuzione e continuerà a funzionare fino al completamento. Questo può effettivamente andare molto lontano.
Valità,

Sì, lo so, ma a un certo punto fallirà. :-)
aseq

8

Le altre risposte sembrano concordare sul fatto che cancellare il BIOS non è probabilmente un tuo problema, quindi ecco un altro pensiero:

Il mio computer, quando passa alla modalità UEFI, salta completamente la schermata del BIOS. Nessun logo del produttore, niente di niente. Cerca solo di avviarsi e mi dice che non ci sono supporti di avvio (o boot).

Se ricordo la chiave per accedere al programma di installazione, posso aprirla mentre il computer si accende e posso ancora accedere alle impostazioni del BIOS.

Se conosci la chiave di configurazione del BIOS, puoi provare a premerla per accedere alla configurazione o fidarti che funzioni effettivamente e ripristinare il tar sul disco, quindi provare ad avviare. Potrebbe essere più veloce usare qualche altro pezzo di supporto di avvio UEFI e provare ad avviarlo se si tratta di un tar enorme ( Memtest86 dovrebbe supportare l'avvio UEFI).


Sebbene, dal momento che presumibilmente non si ottiene un errore "nessun supporto di avvio", la risposta di dronus potrebbe essere la soluzione in questo caso. Spero di no!
Sompom,

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.