rm /*
powinien usunąć bardzo mało. Nie ma tam żadnej -r
flagi, która rekurencyjnie usuwałaby cokolwiek, a bez niej katalogi nie zostaną usunięte (a nawet jeśli katalogi zostałyby usunięte, tylko puste można usunąć). Ta odpowiedź jest oparta na założeniu, że nie uruchomiłeś rm -rf /*
.
Jedynymi konsekwencjami w głównym systemie plików mogą być dowiązania symboliczne do jądra i initrd (chociaż na jednym systemie Ubuntu patrzę, nie istnieją) lub /lib64
dowiązanie symboliczne w systemach 64-bitowych.
Problemem może być po prostu usunięcie /lib64 -> /lib
dowiązania symbolicznego. To dość paskudne, ponieważ prawie każdy program będzie polegał na tym dowiązaniu symbolicznym:
$ ldd /bin/bash
...
/lib64/ld-linux-x86-64.so.2 (0x00007f8946ab7000)
To ld-linux
jest dynamiczny moduł ładujący, a jeśli nie jest dostępny, nie można uruchamiać żadnych dynamicznych plików wykonywalnych. To sprawi, że zalogowanie się będzie wyjątkowo trudne i może nie być w ogóle możliwe.
Może być jeden wybawca busybox
. Uruchom to, aby sprawdzić:
$ ldd /bin/busybox
not a dynamic executable
W takim przypadku busybox powinien być uruchamialny, ale pytanie brzmi: jak go uruchomić?
Jeśli masz dostęp do monitu programu ładującego, możesz być w stanie uruchomić init=/bin/static-sh
, gdzie static-sh jest dowiązaniem symbolicznym busybox
(sprawdź, czy /bin/static-sh
istnieje - działa w moim systemie, ale nie jest to standardowe Ubuntu. Ten błąd sugeruje, że jest dostępny .)
Po utworzeniu powłoki roota możesz ponownie utworzyć /lib64
dowiązanie symboliczne. Konieczne może być ponowne zamontowanie głównego systemu plików jako odczyt / zapis. busybox powinien mieć wbudowane te narzędzia, które można uruchomić w następujący sposób:
# busybox mount -o remount,rw /
# busybox ln -s /lib /lib64
# /bin/bash
bash#
Jeśli bash działa, problem powinien zostać rozwiązany.
-r
argumenturm
czy naprawdę wykonałeś polecenie, które pokazujesz. Czy Twój dostawca hostingu zapewnia sposób dostępu do obrazów dysków poza tym konkretnym komputerem?