Czy `rm -rf / --no-preserve-root` może zepsuć bios?

35

Aby zobaczyć przybliżone prędkości tarballowania całego systemu, a następnie przywracania tego systemu, gdy byłby on foobarowany, częściowo sklonowałem jeden z naszych głównych systemów na stacji roboczej, która, choć nie jest integralna z systemami naszej firmy, byłaby miła mieć funkcjonowanie. Stworzyłem tarballa całego systemu i sprawdziłem go, aby upewnić się, że wygląda dobrze.

Wtedy pobiegłem rm -rf / --no-preserve-root. Nigdy wcześniej nie miałem okazji tego robić, więc było dużo zabawy. Najpierw.

Po ponownym uruchomieniu pudełka nic się nie pojawiło. Brak logo „Dell”, brak opcji dla BIOS-u, nic.

Podłączyłem dysk do innego urządzenia i ku mojemu rozczarowaniu odkryłem, że ma on partycję UEFI. Zakładam, że moje Dowództwo Śmierci skutecznie ukryło tę partycję.

Podłączyłem inny, działający dysk do już niedziałającej stacji roboczej, ale stacja robocza nadal nic nie robi.

Czy ktoś widział coś takiego lub masz sugestie, czego szukać? Jak uruchomienie tego rmpolecenia tak królewsko zepsuło całe pudełko?

AKTUALIZACJA: Zwróciliśmy pudełko firmie Dell. Nie byliśmy w stanie dokładnie zdiagnozować, czy był to zbieg okoliczności, czy sytuacja opisana przez dronusa . Przyjmuję jednak odpowiedź dronusa, ponieważ opisuje ona możliwy powód, dla którego tak się stanie. Ponadto ostrzeże innych przed robieniem tego samego w przyszłości. Gdyby ktoś znalazł jakiś zapis dotyczący używania przez Dell błędnego UEFI, byłoby to pomocne.

MirroredFate
źródło
10
Czy partycja systemowa UEFI została zamontowana w momencie uruchomienia tego polecenia? Jeśli tak nie było, nie powinno to mieć wpływu. To było wtedy powinieneś nadal być w stanie uruchomić się do oprogramowania. najlepiej zgadnąć, że został zainstalowany, że usunąłeś bootloader i że oprogramowanie układowe jest nadal ustawione na ładowanie tylko z tego. Nadal powinieneś być w stanie wprowadzić oprogramowanie wewnętrzne.
Hennes
@Hennes Tak, jestem prawie pewien, że został zamontowany.
MirroredFate
Jaki model Dell?
Mark Plotnick
@MarkPlotnick XPS8700
MirroredFate
Spróbuj zresetować ustawienia CMOS. Odbywa się to poprzez przesunięcie skoczka; nie musisz wyjmować baterii. Strona 84 w download.dell.com/Manuals/all-products/esuprt_desktop/… . Możesz także spróbować nacisnąć klawisz F2, gdy tylko skończy się test POST, aby przejść do ekranu konfiguracji.
Mark Plotnick,

Odpowiedzi:

47

Jedną rzadką możliwością może być wywołanie niektórych niesławnych błędów UEFI, które już zabiły niektóre serie notebooków Samsung i Lenovo.

Działa to w ten sposób: specyfikacje UEFI proponują pamięć nieulotną (nvram lub eeprom), do której system operacyjny może uzyskać dostęp do przechowywania ustawień lub informacji debugowania. Linux faktycznie korzysta z tej funkcji w przypadku paniki jądra: Jeśli główny system plików nie jest już zaufany (np. Po wyjątku w kodzie jądra), zostaje przełączony na tryb tylko do odczytu. Teraz można użyć funkcji UEFI, a informacje debugowania są zapisywane w nieulotnej pamięci. Jak na razie wydaje się to dobrym pomysłem: dane można później odzyskać i wykorzystać do zbadania przyczyn awarii.

Jednak w przypadku niektórych linii błędnych programów firf UEFI niektóre procedury zarządzania nieulotną pamięcią komunikatów są przerywane. W zależności od komunikatów te oprogramowanie układowe ulega awarii podczas inicjowania pamięci wiadomości, zwykle dość wcześnie podczas uruchamiania. Mogą nawet nie osiągnąć inicjalizacji VGA, w którym to przypadku maszyna wydaje się całkowicie zepsuta. W wyżej wymienionych przypadkach nie było oprogramowania i płyty główne musiały zostać wymienione.

Uruchomienie rm -rf / --no-preserve-rootmoże wyzwolić kolejny błąd jądra podczas przeszukiwania i usuwania systemów plików jądra, takich jak /sys, /devlub /proc, co może ostatecznie doprowadzić do paniki jądra, ostatecznie wyzwalając wspomniany wyżej błąd nieulotnej pamięci komunikatów.

dronus
źródło
5
Cóż, to przygnębiające. Ale to przynajmniej praktyczne wyjaśnienie.
MirroredFate
4
Aby dowiedzieć się więcej na ten temat, zobacz na przykład Radzenie sobie z nieulotnymi dziwactwami pamięci UEFI, a wcześniejszy błąd laptopa Samsung nie jest specyficzny dla Linuksa , oba autorstwa Matthew Garretta.
CVn
@ MichaelKjörling Wow. Jest to sprzeczne ze wszystkim, co bym podejrzewał.
MirroredFate
2
Czy możesz zastąpić słowo „BIOS” odpowiednim słowem, takim jak „oprogramowanie układowe”, chyba że naprawdę masz na myśli BIOS komputera IBM? To nie jest coś, co zwykle wybieram, ale w tym przypadku naprawdę musisz to wyjaśnić, ponieważ używasz słów UEFI i BIOS w tym samym zdaniu (nawet obok siebie), co jest dość mylące.
Mehrdad
1
Zastąpiony Dla większości ludzi coś, co prawie nadal wygląda na BIOS i wydaje się, że BIOS będzie BIOSem na zawsze ...
dronus
27

Nie, nie można w ten sposób zniszczyć systemu BIOS (starszego typu lub UEFI) za pomocą tego polecenia.

Nawet jeśli w jakiś sposób udało ci się zniszczyć partycję UEFI, nie będzie to miało wpływu na podstawowe pliki BIOS, ponieważ znajdują się one w nieulotnej pamięci (głównie opartej na flashu) na płycie głównej.

Partycja UEFI obsługuje dodatkowe komponenty oprogramowania (np. Debugger, sterownik, ecc), ale maszyna powinna uruchomić się z BIOS-em nawet bez prawidłowej partycji UEFI.

Shodanshok
źródło
To było moje zrozumienie. Czy znasz jakiś powód, aby zobaczyć opisywane przeze mnie zachowanie?
MirroredFate
1
Mogę sobie tylko wyobrazić, że stacja robocza ma wadliwy sprzęt i że (względnie) duże obciążenie narzucone przez twoje narzędzie do usuwania / usuwania powoduje jego obniżenie. Czy próbowałeś ponownie umieścić procesor i pamięć? Czy próbowałeś wyczyścić pamięć CMOS?
shodanshok
1
Tak, pamięć. Co było dziwne, ponieważ usunięcie pamięci nawet nie spowodowało, że komputer wskazał, że coś jest nie tak. Nie próbowałem ponownie ustawić CPI. Próbowałem wyczyścić pamięć CMOS, ale prawdopodobnie powinno pozostawić baterię na dłużej.
MirroredFate
Chociaż to prawda, niezwykle rzadko zdarza się, aby naprawdę niszczyć sprzęt za pomocą samego oprogramowania. Godnym uwagi wyjątkiem był wiek CRT, gdzie źle zaprogramowane czasy mogą zniszczyć elektronikę CRT. Jednak tak nie jest: najgorszą rzeczą byłoby uszkodzenie BIOS / UEFI, które nie jest prawdziwym zniszczeniem sprzętu. Co więcej, OP próbował inny identyczny dysk (z partycją UEFI na miejscu) i nic nie zmienił. Prawdopodobnie sprzęt WS był już uszkodzony , a obciążenie nałożone przez wydane polecenie oznaczało koniec.
shodanshok
10

Podczas zabawy rm -rf /może jedynie zniszczyć spustoszenie w swoim własnym małym więzieniu - i to jest ta partycja, którą otrzymano. Nie może zepsuć MBR dysku ani nie może magicznie zniszczyć twojego komputera.

W twoim przypadku coś innego jest nie tak.

Janne Pikkarainen
źródło
Prawdziwe. Prawdopodobnie dyskowy GPT dla systemów UEFI (bez MBR, ale z podziałem GPT. I partycja systemowa UEFI, która jest zwykle FAT32).
Hennes
1
Powiedziałbym, że uruchamianie „rm -rf / --no-preserve-root” to tylko zabawa w teorii. W praktyce kończy się wkrótce po usunięciu ważnej biblioteki.
aseq
1
@aseq W rzeczywistości w większości przypadków program i biblioteki są buforowane w pamięci, zwróć uwagę, że dzięki linuxowi możesz usunąć program binarny podczas jego działania i będzie on działał do końca. To naprawdę może zajść naprawdę daleko.
Rzeczywistość
Tak, wiem, ale w pewnym momencie to się wyda. :-)
aseq
8

Inne odpowiedzi wydają się zgadzać, że czyszczenie BIOSu prawdopodobnie nie jest twoim problemem, więc oto inna myśl:

Mój komputer po przełączeniu w tryb UEFI całkowicie pomija ekran BIOS. Brak logo producenta, nic. Po prostu próbuje się uruchomić i mówi mi, że nie ma nośnika startowego (lub bootowania).

Jeśli pamiętam klucz do konfiguracji, mogę go zrzucić, gdy komputer się uruchomi, i nadal mogę przejść do ustawień BIOS-u.

Jeśli znasz klucz instalacyjny BIOS, możesz spróbować go nacisnąć, aby wejść do Instalatora, lub zaufać, że faktycznie działa i przywrócić tar na dysk, a następnie spróbuj uruchomić komputer. Szybsze może być użycie innego elementu nośnika startowego UEFI i próba uruchomienia go, jeśli jest to ogromny tar ( Memtest86 powinien obsługiwać rozruch UEFI).

Sompom
źródło
Chociaż, ponieważ prawdopodobnie nie pojawia się błąd „brak nośnika startowego”, odpowiedź dronusa może być rozwiązaniem w tym przypadku. Mam nadzieję, że nie!
Sompom,
2

/sys/firmware/efi/efivarsto specjalny system plików zawierający wszystkie zmienne EFI. Jeśli dostawca nie zastosował się do najlepszych praktyk , możliwe, że rm -rfwyczyściłeś ważne, a tym samym pomyliłeś oprogramowanie wewnętrzne.

Waldteufel
źródło