Przeniesiono zawartość / bin do / usr / bin, czy można cofnąć?

Korzystając z systemu Ubuntu 17.04, instalowałem oprogramowanie z dystrybucji nie repozytorium, miałem przenieść zawartość folderu bin oprogramowania do katalogu / usr / bin (co było już iffy poradą)

To jeden z tych dni, więc to, co zrobiłem zamiast tego:

mv /bin/* /usr/bin

Więc spieprzyłem i przypadkowo przeniosłem wszystkie pliki z bin do / usr / bin i / bin był pusty. Ponieważ uważam, że / bin ma krytyczne znaczenie dla systemu, w celu szybkiego rozwiązania problemu skopiowałem zawartość / usr / bin do / bin.

Teraz moja zawartość / bin i / usr / bin jest identyczna i oba zawierają oddzielne pliki w / bin i / usr / bin.

1. Czy moje Ubuntu jest teraz w stanie zepsucia? (Nie próbowałem jeszcze restartować komputera, teraz wszystko wydaje się nadal działać)
2. Czy istnieje sposób, aby dowiedzieć się, które pliki zostały ostatnio przeniesione / skopiowane do / usr / bin, więc mogłem po prostu ręcznie zająć się sytuacją? 2.1 Czy pliki / bin i / usr / bin nakładają się zwykle na siebie
3. Czy istnieją inne sposoby na cofnięcie tego, co zrobiłem?

Nie mam zainstalowanego Timeshift, więc przywracanie kopii zapasowych nie jest opcją, ale obecnie nie ma nic krytycznego na komputerze, więc mógłbym po prostu przyznać, że mam problem z ponownym zainstalowaniem całej partycji linux.

Czy moje Ubuntu jest teraz w stanie zepsucia?

Tak, twoje Ubuntu jest zepsute

Pomieszałeś coś ważnego dla zarządzania pakietami .

Więc w praktyce wykonaj kopię zapasową ważnych danych (przynajmniej /etci /home), być może także listy zainstalowanych pakietów, np. Wyjścia dpkg -li ponownie zainstaluj Ubuntu.

^{(nowicjusz mógłby spróbować poradzić sobie - podobnie jak w innych odpowiedziach - ale wtedy nie popełniłby tak wielkiej i podstawowej pomyłki)}

Mógłbym po prostu przyznać, że przykręciłem ponownie zainstalować całą partycję linuksową.

To prawdopodobnie pochłonie mniej czasu. Utrzymywanie obecnego systemu za pomocą innych odpowiedzi utrzymuje go w bardzo nieuporządkowanym stanie (co spowodowałoby w przyszłości bóle głowy).

Ponieważ ponownie formatujesz dysk, rozważ umieszczenie /homeosobnej partycji (aby w przyszłości takie błędy nie spowodowały utraty danych). Przed wykonaniem tego wydrukuj na papierze dane wyjściowe df -hi df -hioraz fdisk -l(podają informacje o miejscu na dysku - zarówno używanym, jak i dostępnym - ...). Mądrze jest mieć wystarczająco dużą partycję systemową (główny system plików); jeśli możesz sobie na to pozwolić, 100 Gbytes to więcej niż wystarcza.

Miałem przenieść zawartość folderu z binami oprogramowania do / usr / bin

(terminologia: Unix ma katalogi, a nie „foldery”).

To ( przejście do /usr/bin/) jest bardzo złe. Albo poprawić $ PATH (najlepiej) lub co najwyżej add dowiązania w /usr/bin/a najlepiej przenieść (lub dodać dowiązania) do wykonywalnych /usr/local/bin/.

Mądry podejście jest nie zmiana /usr/bin/, /bin, /sbin, /usr/sbin/ poza narzędzi zarządzania pakietami (np dpkg, apt-get, aptitude, etc ...). Przeczytaj FHS .

W systemie Linux (i na większości innych systemów, chociaż POSIX nie daje takiej gwarancji, chyba że przeniesienie dotyczyło systemów plików), zaktualizowałoby to ich czas działania, więc zakładając, że żaden z pozostałych /usr/binnie został dotknięty w ciągu ostatnich 24 godzin , powinieneś być w stanie przenieść je z powrotem za pomocą:

find /usr/bin/. ! -name . -prune -ctime -1 -exec sh -c '
   echo mv -i "$@" /bin' sh {} +

Usuń, echojeśli wygląda to poprawnie. Pamiętaj, że nie będziesz w stanie odzyskać plików, które istniały pod tą samą nazwą w /bini /usr/bin(oryginalne w /usr/binzostałyby utracone)

Potencjalny zastrzeżenie: jeśli niektóre pliki zostały ciężko związany zarówno /bini /usr/binwszystkie twarde ogniwa /usr/binzostaną przeniesione do /bin.

Teraz możesz pomyśleć, że skoro /bini /usr/binsą domyślnie $PATHi /binsą dostępne /bootprzynajmniej przed /usrzamontowaniem, nie powinno mieć znaczenia, czy /binzamiast nich znajdują się pliki wykonywalne /usr/bin.

Byłoby to jednak przeoczeniem faktu, że wiele poleceń sztywno koduje ścieżki plików wykonywalnych i oczekuje się, że będą one w określonym przypadku. Częstym przypadkiem jest grzywka. Wszystkie skrypty, które mają:

#! /usr/bin/env bash

po tym nie zadziała mv /usr/bin/env /bin/env. W związku z tym posiadanie poleceń w obu lokalizacjach jest bezpieczniejsze, ponieważ nie złamie tych skryptów.

1. Twoja instalacja powinna być w większości OK; nie powinno być różnych plików o tej samej nazwie w /usri /usr/bin(co odpowiada wersji 2.1), więc posiadanie wszystkich plików w obu /bini /usr/binnic nie zepsuje (dopóki nie uaktualnisz pakietów). Jedynym problemem, jaki możesz mieć teraz, są zepsute dowiązania symboliczne, jeśli zastąpisz plik binarny dowiązaniem symbolicznym do niego. Aby to naprawić, poszukaj uszkodzonych dowiązań symbolicznych:

   find -L /bin /usr/bin -type l -ls
   

   i ponownie zainstaluj wszystkie pakiety odpowiadające wymienionym plikom (na przykład, jeśli /usr/bin/zshpokaże się jako uszkodzony, dpkg -S /bin/zsh /usr/bin/zshpowie Ci, z którego pakietu pochodzi plik; zainstaluj ponownie za pomocą apt --reinstall install zsh).

2. Możesz wyświetlać i sortować według ctime, aby zobaczyć pliki, które zostały ostatnio zmienione (w tym pliki przeniesione):

   ls -ltc /bin
   

3. Najlepszym sposobem na cofnięcie tego, co zrobiłeś, jest użycie cruftpakietu i usunięcie plików, które znajdzie /binlub /usr/binktóre nie pochodzą z pakietu:

   sudo apt install cruft
   sudo cruft -d "/ /usr"
   

   chyba że pliki są dowiązaniami symbolicznymi do plików /etc/alternatives(w takim przypadku powinieneś zostawić je w spokoju).

Wyjaśnienie, dlaczego twój system jest w większym lub mniejszym stopniu „uszkodzony” może być edukacyjny .

1. Jak wskazuje @ basile-starynkevitch, system zarządzania pakietami może się strasznie pogubić, jeśli znajdzie binaria, /binkiedy powinny być /usr/bin, i odwrotnie.
2. Niektóre (być może ważne) skrypty mogą być na stałe podłączone do znalezienia konkretnego pliku binarnego w jednym lub drugim katalogu (w niektórych okolicznościach jest to dobra praktyka, na przykład z punktu widzenia bezpieczeństwa, nie poleganie na zawartości $PATH).
3. Powodem, dla którego istnieje różnica między tym /bini /usr/bintym, że ten pierwszy może potencjalnie znajdować się na partycji, która jest zamontowana na wcześniejszym etapie rozruchu. W tym kontekście (tj. Podczas uruchamiania systemu), do /bin/xxxplików binarnych prawdopodobnie nie wystarczyłaby pełna ścieżka, ale katalog /usr/binmoże być w tym momencie niedostępny w systemie. (Jeśli ty df /bini df /usr/binmożesz zobaczyć ten sam system plików na liście lub różne; prawdopodobnie większość domyślnych instalacji obecnie pozostawia oba katalogi na tej samej partycji).

Zatem bez wątpienia możesz zauważyć, że jeśli masz te same pliki binarne zarówno , jak /bini /usr/bin, wówczas problemy 2 i 3 nie wystąpią, a obrażenia od 1 mogą być niewielkie. Re 1, na przykład, pakiety mogą nie zostać poprawnie odinstalowane, jeśli spróbujesz je usunąć; a aktualizacje mogą zostać zniekształcone, jeśli aktualizacja spróbuje zaktualizować kopię w „poprawnym” miejscu, ale zignoruje kopię w „niewłaściwym” miejscu. Tak więc, jeśli powyższe środki zaradcze wydają się zbyt drastyczne lub skomplikowane, to może uciec z pozostawieniem systemu w tym stanie.

Ale jeśli jest to ważny system, naprawdę nie opierałbym się na tym.

Ogólna zasada (znowu echo @ basile-starynkevitch) nie polega na małpowaniu /usr/bin, /bina przyjaciele - „należą” do dystrybucji - a pakiet, który sugeruje zrobienie tego w ramach normalnej instalacji, nie jest… dobrym pakietem.

Edycja: Zależnie od punktu 3, w kontekście systemd / Fedora i znajomych dyskutuje się, dlaczego sensowne jest przenoszenie całej zawartości /bindo /usr/bini symlinkowanie pierwszego do drugiego. To nie zalecenie, aby to zrobić samemu - to strona skierowana jest do ludzi, którzy sprawiają, że dystrybucje - ale zawiera pewną historię, dlaczego istnieje rozróżnienie (a przez implikację, dlaczego jest teraz jedynie zakurzony tradycja).