CentOS系統中，lib目錄下的庫對系統的正常執行起著非常關鍵的作用。一旦誤操作將導致系統癱瘓。

/lib64被重新命名
故障表現
由於操作失誤，把/usr/lib64重新命名成了/usr/lib64.bak，結果發現，在執行所有外接命令的時候報錯：

mv命令無法使用

-bash: /bin/mv: /lib64/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory

cp命令無法使用

-bash: /bin/cp: /lib64/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory

ls命令無法使用

-bash: /bin/ls: /lib64/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory

ssh命令無法使用

-bash: /usr/bin/ssh: /lib64/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory
想使用mv把檔案重新命名回來已經不行了，就連重新ssh遠端都遠端不了。

修復方法
方法一
光碟修復，安裝glibc，如果機器允許重啟的話

方法二
系統一般情況下會設定LD_LIBRARY_PATH， LD_PRELOAD這兩個環境變數，來改變應用程式所呼叫庫檔案的路徑。這兩個環境變數只對應用程式有效，可能會對shell命令不起作用

因為預設的庫檔案路徑/usr/lib64被改成了/usr/lib64.bak，因此嘗試：

export LD_LIBRARY_PATH=/usr/lib64.bak
export LD_PRELOAD=/usr/lib64.bak
cp /usr/lib64.bak /usr/lib64
方法三
在一個正常的作業系統上<我們可以發現/lib64/ld-linux-x86-64.so.2只是個軟鏈，真實檔案是/usr/lib64/ld-2.17.so，而且這個檔案本身並不是庫檔案，可以簡單的認為他是庫檔案的管理程式。

ld-linux-x86-64.so.2是作業系統的核心，並不受LD_LIBRARY_PATH環境變數的影響。如果想改變其呼叫方式，可以檢視man文件

根據使用幫助，我們手動指定庫路徑進行呼叫cp命令
/lib64/ld-linux-x86-64.so.2 --library-path /lib64.bak /bin/cp /lib64.bak /lib64 -afr
誤刪除/lib64/ld-linux-x86-64.so.2
解決方法同上，刪除的是軟連線檔案，連結回來即可

/lib64/ld-2.17.so --library-path /lib64/ld-2.17.so /bin/ln -sv /lib64/ld-2.17.so /lib64/ld-linux-x86-64.so.2
/lib64被誤刪
這個是致命的故障，趁沒有關閉ssh連線，趕緊使用內建命令while read把重要的配置檔案輸出到螢幕複製粘貼出來吧，然後嘗試光碟修復