I accidentally executed sudo rm /* instead of sudo rm ./* inside a directory whose contents I wanted to delete, and I have basically messed up my system.

None of the basic commands like ls, grep etc. are working, and none of my applications are opening, like chromium, slack, image viewer etc.

I tried to look up my problem on the internet and found this question, but none of the solutions there work for me.

I am on an Arch Linux desktop, and I haven't logged out of my system since this happened, because I'm afraid I won't be able to log back in, as suggested here. Also, I don't have a live USB of an Arch Linux image file, if that helps.

Any help on how should I proceed further to make my system go back to normal, would be appreciated. Thanks!

EDIT: I'm attaching the outputs of some commands:

$ echo /*

/boot /dev /etc /home /lost+found /mnt /opt /proc /root /run /srv /sys /tmp /usr /var
$ echo /usr/*

/usr/bin /usr/include /usr/lib /usr/lib32 /usr/lib64 /usr/local /usr/sbin /usr/share /usr/src

Also, echo /usr/bin/* gives me a long list of directories in the format /usr/bin/{command} where {command} is any command that I could have run from the terminal had I not messed my system up.

Please let me know if any other information is needed!

  • 20
    Are you sure "rm /*" was the command you executed? On this system here, I don't have a single file in /, and "rm /*" wouldn't have removed directories. With the symptoms you describe, "rm -r /*" looks a more likely culprit. Your only option is recovery from backup. In the future, pay attention when executing as root. Commented Mar 21, 2021 at 14:14
  • @GerardH.Pille Yeah, I had executed rm /*, and the directories haven't been deleted in /, just the files. Hope that helps. Commented Mar 21, 2021 at 14:26
  • "ls" isn't working in the same session that executed the "rm"? Commented Mar 21, 2021 at 14:52
  • 9
    The only things that would be removed by that command in a modern Arch installation would be the /usr symlinks (bin -> usr/bin, lib -> usr/lib, lib64 -> usr/lib, sbin -> usr/bin). Not sure what difference those would make. Maybe the linker is assumed to be in /lib?
    – muru
    Commented Mar 21, 2021 at 15:56
  • 2
    Can you run /usr/bin/ls? Can you use /usr/bin/ln to create a symlink or does that complain about missing /lib?
    – terdon
    Commented Mar 21, 2021 at 16:01

2 Answers 2


Arch Linux has four symbolic links in /:

  • bin -> usr/bin
  • lib -> usr/lib
  • lib64 -> usr/lib
  • sbin -> usr/bin

You should be able to recreate them (using a Live-USB or an emergency shell) or by calling the linker (with root privileges and in / as working directory) directly:

/usr/lib/ld-linux-x86-64.so.2 /usr/bin/ln -s usr/lib lib64

This should restore basic functionality in your running system. Then restoring the other symbolic links should be easy.

If you don't have root privileges you can reboot into a recovery shell and fix the problems there.

Why does /usr/bin/ls and other commands fail?

Without the /lib64 symbolic link dynamically linked programs will not find the dynamic linker/loader because the path is hardcoded to /lib64/ld-linux-x86-64.so.2 (c.f. ldd /usr/bin/ln).

  • Running the command /usr/lib/ld-linux-x86-64.so.2 /usr/bin/ln -s usr/lib lib64 gives me /usr/bin/ln: failed to create symbolic link '/lib64': Permission Denied and running it with sudo gives me the same bash: /usr/bin/sudo: No such file or directory error. Is there any other alternative, since I don't currently have a live usb? Commented Mar 21, 2021 at 16:27
  • 5
    @ShreyTripathi reboot, you'll end up in an emergency root shell where you can mount the root partition and fix the problem. You can't run use this with sudo since the setuid binaries don't work that way, so you have no effective way of getting root now if you don't have a root shell open already.
    – muru
    Commented Mar 21, 2021 at 16:30
  • And this is why I used to keep a set of statically linked tools in /proc/1/fd/10/bin until systemd broke it. It only took up 2mb of RAM.
    – Joshua
    Commented Mar 21, 2021 at 22:48
  • @muru does that work? Can you use a /proc FD entry as a directory, if it's an open directory? Commented Mar 22, 2021 at 18:09
  • @user253751 Yeah. You can try it in the terminal with this: ruby -e 'Dir.open "/"; Process.kill :STOP, Process.pid'; ls -l /proc/$(pgrep -nP $$ ruby)/fd/*/; kill %
    – JoL
    Commented Mar 23, 2021 at 0:09

Correct your PATH variable, so that it points only to existing directories


Then recreate the symlinks as shown by terdon's answer.

Then try a login from another terminal.

  • 5
    I'm afraid that won't work. The system needs the /lib64 symlink so ln won't work even if you change your path or use the full path to the ln command. That's why I deleted my answer.
    – terdon
    Commented Mar 21, 2021 at 16:21
  • 1
    @terdon could you not work round that with LD_LIBRARY_PATH? Commented Mar 21, 2021 at 16:54
  • 5
    @PhilipCouling maybe, I don't really know. But that isn't what this answer suggests. This is the same as simply using the full path to the executable and that won't solve anything.
    – terdon
    Commented Mar 21, 2021 at 16:55
  • @terdon absolutely. I was more suggesting a way you might fix your own answer. I wasn't sure if you'd ruled it out though. Commented Mar 21, 2021 at 20:51
  • 2
    @Alfe: LD_LIBRARY_PATH can't help with the ELF interpreter (dynamic linker) itself; that comes straight from ELF metadata because the kernel has to load it as part of execve. From readelf -a /bin/ls on my Arch GNU/Linux system, Requesting program interpreter: /lib64/ld-linux-x86-64.so.2. And /lib64 is a symlink. (The ld-linux...so dynamic linker is what checks for an LD_LIBRARY_PATH env var in the first place.) So TL:DR: unless you have a statically linked busybox or ln, using absolute paths can't help you. Except for running ld-linux.so on an executable. Commented Mar 22, 2021 at 0:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .