Inhalt von / bin nach / usr / bin verschoben, Rückgängig machen möglich?

Unter Ubuntu 17.04 installierte ich eine Software von einer Nicht-Repository-Distribution. Ich sollte den Inhalt des Software-Ordners bin nach / usr / bin verschieben (was schon ein zweifelhafter Rat war).

Es ist einer dieser Tage, also was ich stattdessen getan habe:

mv /bin/* /usr/bin

Also habe ich es vermasselt und versehentlich alle Dateien in bin nach / usr / bin verschoben und / bin war leer. Da ich annehme, dass / bin systemkritisch ist, habe ich zur schnellen Behebung den Inhalt von / usr / bin nach / bin kopiert.

Jetzt sind meine / bin- und / usr / bin-Inhalte identisch und beide enthalten die ursprünglich in / bin und / usr / bin getrennten Dateien.

1. Ist mein Ubuntu jetzt kaputt? (Ich habe noch nicht versucht, den Computer neu zu starten. Im Moment scheint alles noch zu funktionieren.)
2. Gibt es eine Möglichkeit zu wissen, welche Dateien in letzter Zeit nach / usr / bin verschoben / kopiert wurden, sodass ich mich nur manuell um die Situation kümmern kann? 2.1 Gibt es normalerweise überlappende Dateien in / bin und / usr / bin?
3. Gibt es andere Möglichkeiten, um das, was ich getan habe, rückgängig zu machen?

Ich habe Timeshift nicht installiert, daher ist das Wiederherstellen von Backups keine Option, aber derzeit ist auf dem Computer nichts kritisch, sodass ich nur zugeben kann, dass die gesamte Linux-Partition falsch installiert wurde.

Ist mein Ubuntu jetzt kaputt?

Ja, dein Ubuntu ist kaputt

Sie haben etwas für die Paketverwaltung Wichtiges durcheinander gebracht .

Sichern Sie also in der Praxis Ihre wichtigen Daten (zumindest /etcund /home), möglicherweise auch die Liste der installierten Pakete, z. B. die Ausgabe von dpkg -l, und installieren Sie Ubuntu neu.

^{(Ein Nicht-Anfänger könnte versuchen, es zu schaffen - wie in anderen Antworten -, aber dann hätte er keinen so großen und grundlegenden Fehler begangen.)}

Ich könnte nur zugeben, dass ich die gesamte Linux-Partition durcheinanderbringe.

Das würde wahrscheinlich weniger Zeit in Anspruch nehmen. Wenn Sie Ihr aktuelles System mithilfe anderer Antworten erhalten, bleibt es in einem sehr chaotischen Zustand (der Ihnen in Zukunft Kopfschmerzen bereiten würde).

Da Sie Ihre Festplatte neu formatieren, ziehen Sie in Betracht, /homeeine separate Partition einzurichten (damit bei zukünftigen Fehlern Ihre Daten nicht verloren gehen). Bevor Sie dies tun, drucken Sie auf Papier die Ausgabe von df -hund df -hiund fdisk -l(sie geben Auskunft über den verwendeten und verfügbaren Speicherplatz). Seien Sie weise, um eine ausreichend große Systempartition (das Root-Dateisystem) zu haben; Wenn Sie es sich leisten können, sind 100 GB mehr als genug.

Ich sollte den Inhalt des Software-Ordners bin nach / usr / bin verschieben

(Terminologie: Unix hat Verzeichnisse, keine "Ordner").

Die ( bewegend zu /usr/bin/) ist sehr falsch. Entweder verbessern Sie Ihre $ PATH (vorzugsweise) oder höchstens Add Symlinks in /usr/bin/und vorzugsweise bewegen (oder fügen Sie Symlinks) ausführbare Dateien /usr/local/bin/.

Der weise Ansatz ist es , nie ändern /usr/bin/, /bin, /sbin, /usr/sbin/ außerhalb der Paket - Management - Tool (zB dpkg, apt-get, aptitude, etc ...). Lesen Sie die FHS .

Unter Linux (und auf den meisten anderen Systemen, obwohl POSIX Ihnen diese Garantie nur dann bietet, wenn der Wechsel zwischen Dateisystemen stattgefunden hat) hätte dies die Uhrzeit aktualisiert, vorausgesetzt, keiner der anderen /usr/binin den letzten 24 Stunden wurde berührt , sollten Sie in der Lage sein, sie zurück zu verschieben mit:

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

Entfernen Sie das, echowenn das richtig aussieht. Beachten Sie, dass Sie die Dateien mit demselben Namen in /binund nicht wiederherstellen können /usr/bin(die ursprünglichen Dateien in /usr/binwären verloren gegangen).

Eine mögliche Einschränkung: Wenn einige Dateien in beiden /binund /usr/binfest verknüpft /usr/binwären, würden alle festen Verknüpfungen in verschoben /bin.

Nun können Sie sich vorstellen, dass es keine Rolle spielen sollte, ob sich die ausführbaren Dateien in statt befinden , da /binund /usr/binin der Standardeinstellung $PATHsind und mindestens vor dem Mounten /binverfügbar sind ./boot/usr/bin/usr/bin

Aber das würde übersehen, dass viele Befehle die Pfade von ausführbaren Dateien hart codieren und erwarten, dass sie in einem bestimmten Fall vorliegen. Ein häufiger Fall ist sie-Pony. Alle Skripte mit:

#! /usr/bin/env bash

wird nicht funktionieren, nachdem Sie tun mv /usr/bin/env /bin/env. In dieser Hinsicht ist es sicherer, die Befehle an beiden Orten zu haben, da diese Skripte nicht beschädigt werden.

1. Ihre Installation sollte größtenteils in Ordnung sein. Es sollte keine unterschiedlichen Dateien mit demselben Namen in /usrund geben /usr/bin(was Ihrem 2.1 entspricht), sodass alle Dateien in beiden enthalten sind /binund /usr/binnichts kaputt gehen (bis Sie Pakete aktualisieren). Das einzige Problem, das Sie jetzt haben könnten, sind defekte Symlinks, wenn Sie eine Binärdatei mit einem Symlink darauf überschrieben haben. Um dies zu beheben, suchen Sie nach defekten Symlinks:

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

   und installieren Sie alle Pakete neu, die den aufgelisteten Dateien entsprechen (wenn /usr/bin/zshsie beispielsweise als fehlerhaft angezeigt werden, dpkg -S /bin/zsh /usr/bin/zshwerden Sie darüber informiert, von welchem ​​Paket die Datei stammt; installieren Sie sie mit apt --reinstall install zsh).

2. Sie können nach ctime anzeigen und sortieren, um Dateien anzuzeigen, die kürzlich geändert wurden (einschließlich der von Ihnen verschobenen Dateien):

   ls -ltc /bin
   

3. Der beste Weg, um das, was Sie getan haben, rückgängig zu machen, ist, das cruftPaket zu verwenden und Dateien zu löschen, die darin gefunden wurden /binoder /usr/binnicht aus einem Paket stammen:

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

   es sei denn, die Dateien sind Symlinks zu Dateien in /etc/alternatives(in diesem Fall sollten Sie sie in Ruhe lassen).

Es mag lehrreich sein, herauszufinden, warum Ihr System mehr oder weniger kaputt ist.

1. @ Basile-starynkevitch weist darauf hin, dass das Paketverwaltungssystem möglicherweise furchtbar verwirrt ist, wenn es Binärdateien findet, in /bindenen sie sich befinden sollten /usr/bin, und umgekehrt.
2. Einige (möglicherweise wichtige) Skripte sind möglicherweise fest verdrahtet, um eine bestimmte Binärdatei in dem einen oder anderen Verzeichnis zu finden (unter bestimmten Umständen ist es beispielsweise aus Sicherheitsgründen empfehlenswert, sich nicht auf den Inhalt der zu verlassen $PATH).
3. Der Grund, warum es einen Unterschied zwischen /binund /usr/bingibt, besteht darin, dass sich Ersteres möglicherweise auf einer Partition befindet, die zu einem früheren Zeitpunkt des Startvorgangs bereitgestellt wurde. In diesem Kontext (dh beim Booten des Systems) würde /bin/xxxwahrscheinlich nicht nur auf Binärdateien mit einem vollständigen Pfad verwiesen, sondern das Verzeichnis /usr/binist zu diesem Zeitpunkt möglicherweise nicht auf dem System verfügbar. (Wenn Sie df /binund df /usr/bindas gleiche oder ein anderes Dateisystem sehen, belassen die meisten Standardinstallationen heutzutage beide Verzeichnisse auf derselben Partition.)

Sie können also zweifellos sehen, dass die Probleme 2 und 3 nicht auftreten , wenn Sie in beiden und dieselben Binärdateien haben , und der Schaden von 1 möglicherweise geringfügig ist. Bei 1 werden Pakete möglicherweise nicht ordnungsgemäß deinstalliert, wenn Sie versuchen, sie zu entfernen. und Upgrades können verstümmelt werden, wenn das Upgrade versucht, die Kopie an der "richtigen" Stelle zu aktualisieren, die Kopie jedoch an der "falschen" Stelle ignoriert. Wenn die oben genannten Abhilfemaßnahmen zu drastisch oder zu kompliziert erscheinen, können Sie möglicherweise das System in diesem Zustand belassen./bin/usr/bin

Aber wenn dies ein wichtiges System ist, würde ich mich wirklich nicht darauf verlassen.

Eine allgemeine Regel (wieder Echo @ Basile-starynkevitch) ist nie zu Affen mit /usr/bin, /binund Freunde - sie ‚gehört‘ die Verteilung - und ein Paket , das so im Rahmen ihres normalen installieren schlägt zu tun ist ... nicht ein gutes Paket.

Bearbeiten: In Bezug auf Punkt 3 wird im Kontext von systemd / Fedora und Freunden diskutiert, warum es sinnvoll ist, den gesamten Inhalt von an /binzu verschieben /usr/binund den ersten mit dem zweiten zu verknüpfen. Dies ist keine Empfehlung, dass Sie dies selbst tun - diese Seite ist an die Personen gerichtet, die Verteilungen vornehmen -, aber sie enthält eine Geschichte darüber, warum diese Unterscheidung besteht (und implizit, warum sie jetzt nur noch eine staubige Tradition ist).