/ bin / etc / lib64 / root / sbinが削除されたか、mvフォルダーによって移動されました/ * / * su中に
OSはCentos 6.5 64ビット
私はtarファイルをダウンロードし、解凍してmvしたかった。
解凍した後、誤って（rootとして）mv folder/* /*ではなくmv folder/* .を実行したbashは、一部のファイルを上書きできないと述べ、他のユーザーに許可を求めました。 Ctrl + Cを押した。
ターミナルセッションを開いたままにしましたが、suを終了しました。
現在、ほとんどのShellコマンドにアクセスできなくなり、どのディレクトリもlsできず、suに戻ることができません。
Webサーバーとサービスはまだ実行されているようです。実行できるコマンドは非常に少なく、cdはその1つであり、cdを/etcまたは/binにしようとすると、no directory foundでエラーが発生します。
[〜＃〜] edit [〜＃〜]/（bin、etc、lib64、 root、sbin）が/varディレクトリに移動しました。私は/var/bin/suを試して、次のように取得しました：-bash: /var/bin/su: /lib64/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory
[〜＃〜]重要[〜＃〜]ここにいて、mvを誤って実行した場合、Shellコマンドを実行できず、フォルダが見つからないルートディレクトリ（/）まず、SUがある場合は、修正されるまでSUを終了しないでください。元に戻せません。リモートで接続している場合、切断すると、sshを実行できなくなり、サーバーをそのままにしておくことはできません。rebootを実行しないでください。実行中のほとんどのサービスは正常です。 Patrickが提案する多くの解決策の1つを試すことができますが、私が行ったように台無しにした場合は、物理的なアクセスが必要になる可能性があります。
マシンの前で、私はそれをリブートしました。予想通り、カーネルパニックが発生しました。
これはかなり簡単な修正だと思いました。livecdを挿入し、レスキューモードに入ります。これまでは簡単でした。ルートディレクトリをマウントしてみる必要がありました。ただし、必要なのは、単純なマウントコマンドだけではありません。
これは、多くの人と同じようにlvmファイルシステムがあったためであり、このような救急に対処しなければならなかったのはこれが初めてでした。私は何をすべきかを見るためにウェブを検索しなければなりませんでした。その情報をこの投稿に統合しました。これが私の問題を修正するための私のプロセスでした。
1）挿入されたCentos_6.4_min cd
2）GUIインターフェースで何をしたいかを尋ねられ、Rescueを選択しました
3）Rescueは現在のシステムをマウントしようとしましたが、Linuxパーティションがないことを示しました
4）オプションが指定されたときにShellを入力することを選択します
この時点で、システムをマウントするために多くのことを試みましたが、運が悪かったので、これらは（lvmのため）実行しなければならないすべての手順であると確信しています。
5）私のボリュームをスキャンし、
lvmdiskscan
6）lvscanを実行し、すべてを「非アクティブ」として表示
lvscan
7）デバイスモジュールをロードする
modprobe dm-mod
8）存在するボリュームをアクティブに変更する
vgchange -ay
9）再びlvscanを実行し、すべてのアイテムが「アクティブ」としてリストされるようになりました
10）マウントポイントの作成と論理パーティションのマウント
mkdir /mnt/root
mount /dev/VolGroup00/LogVol00 /mnt/root
11）フォルダーを移動しました（他のユーザーが必要になる場合があります）：
mv /var/{bin,etc,lib64,mnt,root,sbin} /
12）reboot
13）成功！
システムにbusyboxがインストールされている場合、これを使用して元に戻すことができます。
busyboxは、多くの標準ユーティリティが組み込まれたバイナリです。 mv、sh、lsなど。
Pavelの回答に対するコメントから、すべてが/varになっているようです。 /var/bin/busybox mv /var/{bin,etc,lib32,lib64,root,sbin,usr} /をお試しください。これで、システムのほとんどが再び動作可能になります。 /tmpのように/var/tmpとしても存在するディレクトリがいくつかあるため、単に移動することはできません。うまくいけば、それらがmvが不平を言ったものであり、彼らは一人にされました。
ルートシェルを取得する
また、ルートシェルを紛失し、suがld-linuxライブラリエラーを発生させていることも説明しました。以下を使用できる場合があります。
LD_LIBRARY_PATH=/var/lib64 /var/lib64/ld-linux-x86-64.so.2 /var/bin/su
注：これを試行しても機能しません。これは、suが/etcにいくつかのファイルを必要とするためです（passwd、pam.dなど） 。/etcがまだ完全である場合、これは成功する可能性が高くなります。
Busyboxなし
Busyboxが利用できない場合、suと同じld-linuxトリックを使用できる可能性があります。
LD_LIBRARY_PATH=/var/lib64 /var/lib64/ld-linux-x86-64.so.2 /var/bin/mv /var/{bin,etc,lib32,lib64,root,sbin,usr} /
ライブCDから
コメントで説明したように、ルートシェルを失った場合は、かなり行き詰まっています。基本的にこれを修正するには、root権限が必要です。そこに到達する唯一の方法は、suやSudoなどのユーティリティを使用して権限をエスカレートする（どちらも現時点では機能しない）か、すでにルートとして実行されている別のプログラムをハイジャックすることです（実行されているものに応じて、可能性は低いです）。
これにより、唯一のオプションがライブCDになります。ライブCD（またはライブUSBなど）で起動したら、ルートボリュームをマウントし、影響を受けるディレクトリを/varから/の元のホームに戻します。
何が起こったかの概要
folder/*は、folder/fooやfolder/barなどに拡張されます。/*は/bin/lib32/lib64/etc/home/root/var。 /varが最後のアイテムであることに注意してください。
シェルがこれらのグロブをすべて展開すると、次のように実行されます。
mv folder/foo folder/bar /bin /lib32 /lib64 /etc /home /root /var
/varはリストの最後のアイテムなので、すべてがそれに移動しました。
/var/bin/suで/lib64/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directoryエラーが発生する理由
Linuxのほとんどすべてのバイナリは、ld-linuxに対して動的にリンクされています。 ld-linuxは、バイナリが必要とする他のライブラリをロードするライブラリです。あなたのシステムでは、これは/lib64/ld-linux-x86-64.so.2にあります。このディレクトリが移動したため、動的にリンクされた実行可能ファイルは機能しなくなります。
Busyboxが機能する理由は、busyboxが静的にリンクされているためです。 ld-linuxは使用しません。
mv folder/* ./*も間違っています。実行するコマンドのセマンティクスに注意する必要があります。 3つ以上の引数を指定したmvコマンドは、最後の引数を除くすべての引数を取得し、それらが指すパスを最後の引数で指定されたディレクトリに移動します。
すべてのディレクトリ（非表示のディレクトリを除く）をfolderから現在のディレクトリに移動するには、次を使用する必要があります。
mv folder/* .
実行中のシステムが壊れています。シェルと組み込みコマンドは引き続き機能します。ライブCDを起動して、ディレクトリを戻す必要があります。再起動せずに状況を修正できるファイルを移動/名前変更する組み込みのbashについては知りません。詳細については、Patrickの回答を参照してください。
誤って/ usrを/ usr_oldに移動し、すべてが地獄に行きました。幸い、私はプロンプトにとどまり、次のコマンドを実行してusrフォルダーを復元できました。
LD_LIBRARY_PATH=/usr_old/lib64 /usr_old/lib64/ld-linux-x86-64.so.2 /usr_old/bin/mv /usr_old /usr