0

The error might be a bit different than the one from the topic- I was translating it from my native language.

After everything failed, I tried doing as mjp pointed in this post: GLIBCXX_3.4.20 not found, how to fix this error?

But as a result every command- apt-get, mv, cp returns the error from the topic title. I cannot go back to the backup version of the file.

At the moment I can't even log into Ubuntu. I got lopped inside the login screen. Everytime I try to login, screen gets black and I get back to login. I can only use the comand via ctrl+alt+F3

What should I do?

Answer for steeldriver (please look at the comment):

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
Charles Green
  • 21,859
Kokos34
  • 3

1 Answers1

1

[I must admit I'm a bit puzzled why basic utilities like mv or cp would break because of libstdc++.so.6, however asssuming that's the reason, here's what I would try]

Your busybox ls output indicates that you have managed to recursively link /usr/lib/x86_64-linux-gnu/libstdc++.so.6 to itself. Thankfully, it appears that you have not deleted or overwritten the actual /usr/lib/x86_64-linux-gnu/libstdc++.so.6.19 library. So you should be able to recover by re-creating the symbolic link.

The gotcha will be if either sudo or ln or both rely on the libstdc++ library. (Presumably bash doesn't, since you are able to login with a shell at the Ctrl+Alt+F3 virtual terminal.)

If sudo is broken, then you should still be able to boot into a root shell from recovery mode, as described in How do I boot into a root shell?. You will then need to remount the root filesystem in read-write mode

mount -o remount,rw /

After that, you can attempt to fix the broken link

ln -sf libstdc++.so.6.19 /usr/lib/x86_64-linux-gnu/libstdc++.so.6

(this should create a relative symlink that is resolved relative to the target path /usr/lib/x86_64-linux-gnu/, similar to your .old link).

Assuming that fails because ln depends on libstdc++.so, you can try again using the statically-linked busybox executable, which has a built-in ln:

/bin/busybox ln -sf libstdc++.so.6.19 /usr/lib/x86_64-linux-gnu/libstdc++.so.6

If that works, you can exit the root shell to proceed with the normal boot.

steeldriver
  • 142,475