web-dev-qa-db-ja.com

/ binの内容を/ usr / binに移動しました。元に戻すことはできますか？

Ubuntu 17.04を実行しているときに、リポジトリ以外のディストリビューションからソフトウェアをインストールしていました。ソフトウェアのbinフォルダーの内容を/ usr/binに移動することになっていた（これはすでに助言されていました）

それはその日のうちの1つなので、代わりに次のようにしました。

mv /bin/* /usr/bin

それで私は失敗し、誤ってbin内のすべてのファイルを/ usr/binに移動しましたが、/ binは空でした。私は/ binがシステムに不可欠であることを理解しているため、迅速な解決策として、/ usr/binの内容を/ binにコピーしました。

これで/ binと/ usr/binの内容は同じになり、どちらも元々/ binと/ usr/binに分離されたファイルが含まれています。

  1. 私のUbuntuは壊れた状態ですか？ （まだコンピュータを再起動しないでください、今のところすべてがまだ機能しているようです）
  2. 最近どのファイルが/ usr/binに移動/コピーされたかを知る方法はあるので、手動で状況を処理できますか？ 2.1通常、/ binと/ usr/binに重複するファイルがありますか
  3. 私がしたことを元に戻す他の方法はありますか？

Timeshiftをインストールしていないので、バックアップを復元することはできませんが、現在コンピューター上で重要なことは何もないので、Linuxパーティション全体を再インストールすることを認めることができます。

linuxubuntumv
18
oneOfThoseDays

Ubuntuは壊れた状態になっていますか？

はい、Ubuntuが壊れています

パッケージ管理 にとって重要な何かを台無しにしました。

したがって、実際には、重要なデータ（少なくとも/etcと/home）をバックアップしてください。おそらく、インストールされているパッケージのリストもバックアップしてください。 dpkg -lの出力、Ubuntuの再インストール。

（非初心者は他の回答のように-管理しようとする可能性がありますが、その場合、彼はそのような巨大で基本的な間違いをしなかったでしょう）

私はLinuxパーティション全体を再インストールすることを認めることができます。

それはおそらくあなたの時間のより少ないものになるでしょう。他の回答を利用して現在のシステムを維持することは、システムを非常に厄介な状態に維持することになります（将来の頭痛の種になるでしょう）。

ディスクを再フォーマットしているので、/homeを別のパーティションに配置することを検討してください（将来、このようなミスによってデータが失われることはありません）。紙に印刷する前に、df -h、df -hi、fdisk -lの出力（ディスクスペースに関する情報が表示されます（使用済みと使用可能の両方）...）。十分な大きさのシステムパーティション（ルートファイルシステム）を用意することをお勧めします。余裕があれば、100Gバイトで十分です。

ソフトウェアのbinフォルダーの内容を/ usr/binに移動することになっていた

（用語：Unixには「フォルダ」ではなくディレクトリがあります）。

（movingto /usr/bin/）は非常に間違っています。 /usr/bin/で $ PATH （できれば）または多くても追加symlinksを改善し、実行可能ファイルを/usr/local/bin/に移動（またはシンボリックリンクを追加）してください。

賢明なアプローチは、/usr/bin/、/bin、/sbin、/usr/sbin/をパッケージ管理ツールの外部で変更しないことです（例：dpkg、apt-get、aptitudeなど...）。 [〜＃〜] fhs [〜＃〜] をお読みください。

19
Basile Starynkevitch

Linux（および他のほとんどのシステム、ただしPOSIXではファイルシステムを越えて移動しない限り、その保証はありません）では、ctimeが更新されるため、/usr/binの他のどれも変更されていないと想定します。過去24時間以内に、次の方法で元に戻すことができるはずです。

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

正しく見える場合は、echoを削除します。 /binと/usr/binに同じ名前で存在していたファイルを復元することはできません（/usr/binの元のファイルは失われていたでしょう）。

潜在的な警告：一部のファイルが/binと/usr/binの両方でハードリンクされている場合、/usr/binのすべてのハードリンクは/binに移動されます。

さて、/binと/usr/binはデフォルトの$PATHであり、/binは/bootで少なくとも/usrより前に使用できると考えるかもしれませんがマウントされている場合、実行可能ファイルが/binではなく/usr/binにあるかどうかは関係ありません。

しかし、それは多くのコマンドが実行可能ファイルのパスをハードコードし、それらが特定のケースにあることを期待していることを見落としているでしょう。一般的なケースは、シバンです。次のすべてのスクリプト：

#! /usr/bin/env bash

mv /usr/bin/env /bin/envを実行すると、機能しなくなります。その点で、両方の場所にコマンドを置くことは、それらのスクリプトを壊さないという点でより安全です。

36
Stéphane Chazelas

  1. インストールはほとんど問題ありません。 /usrと/usr/bin（2.1に答える）に同じ名前の異なるファイルがあってはならないので、/binと/usr/binの両方にすべてのファイルが存在しますt（パッケージをアップグレードするまで）何かを壊します。あなたが今持っているかもしれない唯一の問題は、シンボリックリンクでバイナリを上書きした場合、壊れたシンボリックリンクです。これを修正するには、壊れたシンボリックリンクを探します。

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

    リストされたファイルに対応するパッケージを再インストールします（たとえば、/usr/bin/zshが壊れていると表示された場合、dpkg -S /bin/zsh /usr/bin/zshはファイルがどのパッケージからのものかを通知します。apt --reinstall install zshで再インストールします）。

  2. Ctimeで表示およびソートして、最近変更されたファイル（移動したファイルを含む）を確認できます。

    ls -ltc /bin

  3. 元に戻した最善の方法は、cruftパッケージを使用して、/binまたは/usr/binで見つかったファイルのうち、パッケージに含まれていないものを削除することです。

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

    ファイルが/etc/alternatives内のファイルへのシンボリックリンクでない場合（その場合は、そのままにしておきます）。

17
Stephen Kitt

お使いのシステムが多かれ少なかれ「壊れている」理由を詳しく説明することは、教育に役立つかもしれません。

  1. @ basile-starynkevitchが指摘しているように、パッケージ管理システムは、/binにあるはずのバイナリが/usr/binにあるはずのバイナリを見つけた場合、ひどく混乱する可能性があります。
  2. 一部の（おそらく重要な）スクリプトは、特定のバイナリを一方または他方のディレクトリで見つけるようにハードワイヤードされている場合があります（状況によっては、たとえばセキュリティの観点から、ではない$PATH）の内容に依存します。
  3. /binと/usr/binに違いがあるのは、前者がブートの初期段階でマウントされたパーティション上にある可能性があるためです。このコンテキスト（つまり、システムの起動時）では、/bin/xxxバイナリがフルパスで参照される可能性があるだけでなく、/usr/binディレクトリがその時点でシステムで使用できない場合があります。 （df /binとdf /usr/binの場合、同じファイルシステムがリストされているか、異なるファイルシステムが表示される場合があります。おそらく最近のデフォルトのインストールでは、両方のディレクトリを同じパーティションに残します）。

したがって、2倍になると、/binと/usr/binの両方にsameバイナリがある場合、問題2と3は発生せず、1からの損傷は小さい可能性があることがわかります。たとえば、パッケージを削除しようとすると、パッケージが正しくアンインストールされない可能性があります。アップグレードが「正しい」場所のコピーをアップグレードしようとしたが、「間違った」場所のコピーを無視した場合、アップグレードは文字化けする可能性があります。したがって、上記の救済策があまりにも徹底的または複雑に思われる場合は、システムをこの状態のままにしておくことを可能性があります。

しかし、これが重要なシステムであるなら、私reallyはそれに頼りません。

一般的なルール（ここでも@ basile-starynkevitchを繰り返します）は、/usr/bin、/binなどの友達（ディストリビューションに「属している」）とは決して一致しません。通常のインストールの一部としてそうすることを示唆するパッケージは...良くありませんパッケージ。

編集：ポイント3に関連して、- systemd/Fedoraとその仲間のコンテキストでの議論/binのすべてのコンテンツを移動することが理にかなっている理由について/usr/binに、最初のものを2番目にシンボリックリンクします。これはではありませんこれを自分で行うことをお勧めします-そのページは配布を行う人々に向けられています-しかし、この違いが存在する理由の履歴が含まれています今ではほこりっぽい伝統です）。

6
Norman Gray