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

18

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.

jeden z tych dni
źródło
2
dpkg-query -l | awk '{system ("dpkg-query -L" $ 2 "| grep -E \" ^ / usr / bin /.*$ \ "")}' To da ci wszystkie pliki początkowo w / usr / bin na podstawie zainstalowane pakiety
Raman Sailopal
7
@ SatōKatsura /binma krytyczne znaczenie dla systemu. Jego zawartość musi być obecna na najwcześniejszych etapach rozruchu. Nie chcesz tworzyć dowiązania symbolicznego do partycji ( /usrtutaj), która może nie zostać zamontowana podczas rozruchu.
xhienne,
1
@xhienne Nigdy nie powiedziałem, że przetrwa restart. Jest to tymczasowa poprawka, aby uzyskać wystarczającą funkcjonalność, aby móc naprawić system.
Satō Katsura,
1
@xhienne zależy od tego, jak skonfigurowałeś dystrybucję. Arch, na przykład, /bindomyślnie nie utrzymuje oddzielnego . Domyślne partycjonowanie Ubuntu nie tworzy osobnych /usrpartycji. Jestem ciekawy, jak wielu ludzi robi osobne rzeczy /usrw nowoczesnej dystrybucji.
muru
1
@muru Weź mój komentarz jako ogólny. Możesz założyć, co chcesz na liczbę partycji, wolę tego nie robić i ostrzegam przed łączeniem / usr / bin / * do / bin, co w najlepszym wypadku jest całkowicie bezużyteczne, aw najgorszym przypadku może uniemożliwić korzystanie z systemu przy następnym uruchomieniu . Żaden system następujący po FHS nie powinien zawierać dowiązań symbolicznych do / usr / bin. OP zaleca, aby zamiast tego skopiować pliki.
xhienne,

Odpowiedzi:

19

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 .

Basile Starynkevitch
źródło
4
Przyjmę tę odpowiedź: wygląda na to, że po próbie odzyskania działała do momentu ponownego uruchomienia komputera, który nie był w stanie uruchomić żadnej sesji środowiska pulpitu. Zamiast próbować to naprawić, przyznaję, że się zepsułem i po prostu ponownie zainstaluję partycję Linux. Ponieważ wszystko było pod kontrolą wersji i korzystałem z systemu tylko przez tydzień, straciłem tylko godność i miałem mały atak paniki, ale wydaje się to normalne, gdy życie uczy mnie lekcji.
oneOfThoseDays
1
Ponieważ są /bini /usr/binsą teraz identyczne, nie jestem pewien, dlaczego zarządzanie pakietami miałoby być zepsute. Czy naprawdę istnieje przypadek, w którym /bin/fooi /usr/bin/foosą przewidziane zarówno przez pakiet (y). Jeśli nie, to tylko kilka dodatkowych plików unosi się wokół.
StrongBad
3
@Basile nie to nie byłoby (nieszczęśliwe); zarządzanie pakietami dba tylko o pliki, o których wie, nie narzeka na pliki, o których nie wie. Nawet dla plików to nie wiedzą o, to nie będzie przeszkadzało szczególnie jeśli oni zmieniło ...
Stephen Kitt
2
@Basile również nie liczyłbym na tę drugą część „(nie-nowicjusz mógłby spróbować poradzić sobie - jak w innych odpowiedziach, ale wtedy nie popełniłby tak ogromnego i podstawowego błędu)” - to prawda ;-). Nawet eksperci czasem się potykają!
Stephen Kitt,
1
FWIW moja główna /partycja systemowa ma 12 GB i nigdy nie natknąłem się na problem z przestrzenią, mimo że używam jej do programowania (odczytywanie plików nagłówka i wielu narzędzi) biura i projektowania (odczytywanie ciężkich narzędzi), na KDE (odczytywanie nie jest najsmuklejsze). Dodaj 4 GB więcej, jeśli się nie podzielisz /var, napompuj o 25%, jeśli chcesz mieć większy margines niż ja, a przy 20 GB jesteś więcej niż dobry.
spectras
36

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.

Stéphane Chazelas
źródło
3
Jak wspomniałem powyżej (usunąłem mój komentarz, ponieważ miał poważny błąd, który próbował przenieść wszystko do katalogu o nazwie - iniechęć!) W systemach GNU / Linux, takich jak Ubuntu, z których można korzystać, find /usr/bin/. ! -name . -prune -ctime -1 -exec echo mv -it /bin {} +ponieważ GNU Coreutilsmv obsługuje -t. Inne systemy operacyjne na ogół go nie obsługują ani nie działają w systemie alternatywnym mvdostarczonym przez BusyBox .
Eliah Kagan,
17
  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).

Stephen Kitt
źródło
Z wyjątkiem skryptów rozpoczynających się od #! /bin/shlub podobnych.
Satō Katsura,
@ SatōKatsura nadal będą działać poprawnie, jeśli shjest w obu /bini /usr/bin(wszystkie pliki są teraz duplikowane).
Stephen Kitt,
1
Specjalny zestaw narzędzi, taki jak cruftten, nie jest konieczny do tego zadania, ponieważ menedżer pakietów śledzi również zainstalowane pliki. Zobacz unix.stackexchange.com/questions/153260/… .
Ned64,
1
comm -12 <(ls /bin) <(ls /usr/bin)pokaż kilka wpisów w systemie Ubuntu, na którym go testowałem. Niektóre z jakimś /bin/foo -> /usr/bin/foośrodkiem foozostałyby utracone.
Stéphane Chazelas,
@ Stéphane ah tak, przeniesienie linku zniszczyłoby oryginał ...
Stephen Kitt
6

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

Norman Gray
źródło