Przypadkowo przeniosłem wszystkie foldery z katalogu głównego do podfolderu. ( /bin, /etc, /home, /lib, /usr... wszystko przeniesiony) jedynymi, które nie zostały przeniesione, ponieważ były one w użyciu, są /bak, /boot, /dev, /proc, /sys.
Teraz każde polecenie, które próbuję wykonać, po prostu się nie wydarzy. Ciągle pojawia się komunikat „Brak takiego pliku lub katalogu”.
Jestem połączony przez ssh i przez ftp, ale nie mogę przenosić plików przez ftp, ponieważ bezpośrednie logowanie SU jest wyłączone. Mam również dostęp do rzeczywistego serwera, jeśli muszę coś zrobić bezpośrednio z tego miejsca.
Zakładam, że musiałbym edytować plik konfiguracyjny, aby powiedzieć mu, gdzie znaleźć /binfolder, co pomogłoby mi uzyskać dostęp ponownie, ale nie wiem, który to plik i jak to zrobić (ponieważ nie można nawet uruchomić, chmodaby zmienić uprawnienia).
Czy jest na to wyjście poza ponownym zainstalowaniem?
Pracuję nad starą wersją CentOS.
Jestem niezwykle nowy w świecie Linuksa, stąd ta akcja i pytanie ...
Odpowiedzi:
Jeśli nadal masz powłokę root, możesz mieć szansę naprawić swój system. Powiedzmy, że przeniósł wszystkich wspólnych katalogów (
/bin,/etc,/lib,/sbin,/usr- są to te, które mogłyby spowodować odzyskanie trudną) pod/oops.Nie będziesz mógł wydać
mvpolecenia bezpośrednio, nawet jeśli podasz pełną ścieżkę/oops/bin/mv. To dlatego, żemvjest dynamicznie powiązany ; ponieważ/libkatalog został przeniesiony ,mvnie można go uruchomić, ponieważ nie można znaleźć bibliotek, które stanowią część jego kodu. W rzeczywistości jest nawet gorzej:mvnie można znaleźć dynamicznego modułu ładującego/lib/ld-linux.so.2(nazwa może się różnić w zależności od architektury i wariantu unix, a katalog może mieć inną nazwę, taką jak/lib32lub/lib64). Dlatego, dopóki nie przeniesiesz/libkatalogu z powrotem, musisz jawnie wywołać konsolidator i określić ścieżkę do przeniesionych bibliotek. Oto polecenie przetestowane na ściśnięciu Debiana i386.Może być konieczne dostosowanie tego nieco w przypadku innych dystrybucji lub architektur. Na przykład dla CentOS na x86_64:
Kiedy coś spieprzysz
/lib, pomoże Ci mieć statycznie połączony zestaw narzędzi. Niektóre dystrybucje (nie wiem o CentOS) zapewniają statycznie połączoną kopię Busybox . Jest też sash , samodzielna powłoka z wieloma wbudowanymi poleceniami. Jeśli masz jeden z nich, możesz odzyskać stamtąd. Jeśli nie zainstalowałeś ich wcześniej, jest za późno.Jeśli nie masz już powłoki roota, ale nadal nasłuchujesz demona SSH i możesz zalogować się bezpośrednio jako root przez ssh, a masz jeden z tych statycznie połączonych zestawów narzędzi, możesz być w stanie ssh. może działać, jeśli zostały przeniesione
/libi/bin, ale nie/etc.Niektórzy administratorzy zakładają alternatywne konto ze statycznie połączoną powłoką lub zmuszają konto root do korzystania ze statycznie połączonej powłoki, tylko dla tego rodzaju problemów.
Jeśli nie masz root-a i nie podjąłeś żadnych środków ostrożności, będziesz musiał uruchomić system z Live CD / USB na Linuksa (każdy będzie działał tak długo, jak będzie wystarczająco nowy, aby mieć dostęp do twoich dysków i systemów plików) i przenieś pliki z powrotem.
źródło
Prawdopodobnie możesz odzyskać bez ponownego uruchamiania, więc nie uruchamiaj ponownie, dopóki nie wypróbujesz innych rzeczy, ponieważ nie uruchomi się. Jeśli nadal masz otwartą sesję SSH, spróbuj wykonać następujące czynności:
Miejsce uruchamiania programów ustawia się za pomocą zmiennej $ PATH. Możesz dodać nową lokalizację kosza do ścieżki, uruchamiając
export PATH="$PATH:/newpath/to/bin:/newpath/to/usr/bin". Konieczne może być również dodanie odpowiednich katalogów sbin . Możesz także uruchamiać programy ręcznie przez ich pełną ścieżkę,/path/to/mv [from] [to]na przykład powinno działać, nawet jeśli mv znajduje się w innym miejscu. Trudna część polega na tym, że większość poleceń będzie chciała uzyskać dostęp do wspólnych bibliotek i mówisz, że zostałeś/libprzeniesiony, więc musisz ustawić zmienną dla tego, gdzie to jest.export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/newpath/to/lib/:/newpath/to/usr/libGdy będziesz w stanie wykonać kilka podstawowych poleceń, cofnij to!
mv /path/to/subfolder/* /byłoby w porządku! Gdy wszystko wróci na miejsce, system powinien działać normalnie.Jeśli to się nie powiedzie, uruchomienie KAŻDEJ płyty LiveCD i zamontowanie napędu powinno umożliwić przeniesienie folderów z powrotem do ich miejsca. Nie musisz ponownie instalować ani nawet korzystać z dystrybucji na żywo, wystarczy zamontować dysk i przenieść foldery z powrotem do właściwej lokalizacji na dysku. Wiele dysków ratunkowych opartych na systemie Linux specjalizuje się w udostępnianiu zaledwie kilku podstawowych narzędzi konsoli do wykonania tego rodzaju naprawy.
źródło
LD_LIBRARY_PATH, musisz również bezpośrednio wywołać moduł ładujący dynamiczny, npLD_LIBRARY_PATH=/newpath/to/lib /newpath/to/lib/ld-linux.so.2 /newpath/to/bin/mv.Powinieneś być w stanie ponownie uruchomić komputer z instalacyjną płytą CD w trybie pojedynczego użytkownika, zamontować główny system plików i przenieść pliki z powrotem na Linux. Nie znam dużo centów, ale to jest jak RHEL, więc to powinno działać.
źródło
Wielkie dzięki dla Gillesa, 5 lat później, a twoje posty wciąż uratowały mi dzień, jeśli nie tydzień.
Chciałem przenieść zawartość podfolderu do bieżącego folderu, ale zamiast tego
mv sub/* .zrobiłemmv sub /* ., więc przeniosłem wszystko do bieżącego folderu. Na szczęście znalazłem tę odpowiedź i byłem w stanie naprawić moją maszynę ze względną łatwością. Musiałem jednak nieco dostosować polecenia, ponieważ pracuję na maszynie x86_64 z systemem Ubuntu 16.04. Chciałbym zostawić instrukcje tutaj, na wypadek, gdyby ktoś miał problemy:źródło
Chciałbym dodać jeszcze kilka poleceń do wykonania po zastosowaniu odpowiedzi Ktipr dla nowoczesnych systemów (maszyny x86_64 z systemem Unix), nie byłem w stanie uzyskać przeniesienia katalogów „etc” z mv, ponieważ pokazywał błąd
więc musiałem użyć
aby upewnić się, że udało mi się odzyskać wszystko w porządku. Jeśli jeszcze go nie masz, musisz go najpierw zainstalować.
źródło