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.
- Czy moje Ubuntu jest teraz w stanie zepsucia? (Nie próbowałem jeszcze restartować komputera, teraz wszystko wydaje się nadal działać)
- 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
- 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.
/bin
ma krytyczne znaczenie dla systemu. Jego zawartość musi być obecna na najwcześniejszych etapach rozruchu. Nie chcesz tworzyć dowiązania symbolicznego do partycji (/usr
tutaj), która może nie zostać zamontowana podczas rozruchu./bin
domyślnie nie utrzymuje oddzielnego . Domyślne partycjonowanie Ubuntu nie tworzy osobnych/usr
partycji. Jestem ciekawy, jak wielu ludzi robi osobne rzeczy/usr
w nowoczesnej dystrybucji.Odpowiedzi:
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
/etc
i/home
), być może także listy zainstalowanych pakietów, np. Wyjściadpkg -l
i 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)
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
/home
osobnej partycji (aby w przyszłości takie błędy nie spowodowały utraty danych). Przed wykonaniem tego wydrukuj na papierze dane wyjściowedf -h
idf -hi
orazfdisk -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.(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 (npdpkg
,apt-get
,aptitude
, etc ...). Przeczytaj FHS .źródło
/bin
i/usr/bin
są teraz identyczne, nie jestem pewien, dlaczego zarządzanie pakietami miałoby być zepsute. Czy naprawdę istnieje przypadek, w którym/bin/foo
i/usr/bin/foo
są przewidziane zarówno przez pakiet (y). Jeśli nie, to tylko kilka dodatkowych plików unosi się wokół./
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.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/bin
nie został dotknięty w ciągu ostatnich 24 godzin , powinieneś być w stanie przenieść je z powrotem za pomocą:Usuń,
echo
jeś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/bin
i/usr/bin
(oryginalne w/usr/bin
zostałyby utracone)Potencjalny zastrzeżenie: jeśli niektóre pliki zostały ciężko związany zarówno
/bin
i/usr/bin
wszystkie twarde ogniwa/usr/bin
zostaną przeniesione do/bin
.Teraz możesz pomyśleć, że skoro
/bin
i/usr/bin
są domyślnie$PATH
i/bin
są dostępne/boot
przynajmniej przed/usr
zamontowaniem, nie powinno mieć znaczenia, czy/bin
zamiast 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ą:
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.źródło
i
niechęć!) 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 alternatywnymmv
dostarczonym przez BusyBox .Twoja instalacja powinna być w większości OK; nie powinno być różnych plików o tej samej nazwie w
/usr
i/usr/bin
(co odpowiada wersji 2.1), więc posiadanie wszystkich plików w obu/bin
i/usr/bin
nic 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:i ponownie zainstaluj wszystkie pakiety odpowiadające wymienionym plikom (na przykład, jeśli
/usr/bin/zsh
pokaże się jako uszkodzony,dpkg -S /bin/zsh /usr/bin/zsh
powie Ci, z którego pakietu pochodzi plik; zainstaluj ponownie za pomocąapt --reinstall install zsh
).Możesz wyświetlać i sortować według ctime, aby zobaczyć pliki, które zostały ostatnio zmienione (w tym pliki przeniesione):
Najlepszym sposobem na cofnięcie tego, co zrobiłeś, jest użycie
cruft
pakietu i usunięcie plików, które znajdzie/bin
lub/usr/bin
które nie pochodzą z pakietu:chyba że pliki są dowiązaniami symbolicznymi do plików
/etc/alternatives
(w takim przypadku powinieneś zostawić je w spokoju).źródło
#! /bin/sh
lub podobnych.sh
jest w obu/bin
i/usr/bin
(wszystkie pliki są teraz duplikowane).cruft
ten, nie jest konieczny do tego zadania, ponieważ menedżer pakietów śledzi również zainstalowane pliki. Zobacz unix.stackexchange.com/questions/153260/… .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
środkiemfoo
zostałyby utracone.Wyjaśnienie, dlaczego twój system jest w większym lub mniejszym stopniu „uszkodzony” może być edukacyjny .
/bin
kiedy powinny być/usr/bin
, i odwrotnie.$PATH
)./bin
i/usr/bin
tym, ż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/xxx
plików binarnych prawdopodobnie nie wystarczyłaby pełna ścieżka, ale katalog/usr/bin
może być w tym momencie niedostępny w systemie. (Jeśli tydf /bin
idf /usr/bin
moż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
/bin
i/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
,/bin
a 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
/bin
do/usr/bin
i 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).źródło