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

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.

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.

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.

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.

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

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