這個錯誤可能與主題中的錯誤略有不同 - 我是從我的母語翻譯的。
一切都失敗後，我嘗試按照 mjp 在這篇文章中指出的那樣： 未找到 GLIBCXX_3.4.20，如何修復此錯誤？
但結果是每個指令 apt-get、mv、cp 都會從主題標題回傳錯誤。我無法返回到文件的備份版本。
目前我甚至無法登入Ubuntu。我被困在登入畫面裡了。每次我嘗試登入時，螢幕都會變黑，然後我會重新登入。我只能透過 ctrl+alt+F3 使用指令
我該怎麼辦？
Steeldriver 的回答（請看評論）：
lrwxrwxrwx 1 root root 40 Jun 17 21:37 /usr/lib/x86_64-linux-gnu/libstdc++.so.6 -> /usr/lib/x86_64-linux-gnu/libstdc++.so.6
-rw-r--r-- 1 root root 979056 May 7 2016 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.19
lrwxrwrwx 1 root root 19 May 7 2016 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.old -> libstdc++.so.6.0.19
答案1
[我必須承認我有點困惑為什麼基本實用程式喜歡mv或cp會因為 而中斷libstdc++.so.6，但是假設這就是原因，這就是我會嘗試的]
您的busybox ls輸出表明您已成功遞歸連結/usr/lib/x86_64-linux-gnu/libstdc++.so.6到自身。值得慶幸的是，您似乎沒有刪除或覆蓋實際的/usr/lib/x86_64-linux-gnu/libstdc++.so.6.19庫。因此，您應該能夠透過重新建立符號連結來恢復。
問題在於其中一個sudo或ln兩個都依賴該libstdc++庫。 （大概bash不會，因為您可以在Ctrl+ Alt+F3虛擬終端上使用 shell 登入。）
如果sudo損壞，那麼您應該仍然能夠從復原模式啟動到 root shell，如中所述如何啟動進入 root shell？。然後，您需要以讀寫模式重新掛載根檔案系統
mount -o remount,rw /
之後，您可以嘗試修復損壞的鏈接
ln -sf libstdc++.so.6.19 /usr/lib/x86_64-linux-gnu/libstdc++.so.6
（這應該創建一個相對符號連結這是相對於目標路徑解析的/usr/lib/x86_64-linux-gnu/，類似於您的.old連結）。
假設由於ln依賴而失敗libstdc++.so，您可以使用靜態連結的busybox可執行檔重試，它有一個內建的ln：
/bin/busybox ln -sf libstdc++.so.6.19 /usr/lib/x86_64-linux-gnu/libstdc++.so.6
如果有效，您可以使用exitroot shell 繼續正常啟動。