11

I accidentally executed rm /* while logged in as root in a remote Ubuntu Server and deleted pretty much all binaries and currently I can neither log in via ssh or ftp to restore the files (and hope for the best).

Is there a way to somehow fix this mess, or should I call the datacenter and ask for a format?

Improve this question
1
  • 2
    Can you confirm whether this is a physical or virtual server? Also whether you ran the -r argument to rm or really just did the command you show. Does your hosting provider provide any way to access the disk images outside of that particular machine?
    – Caleb
    Commented Aug 9, 2011 at 16:37

4 Answers 4

Reset to default
29

rm /* should delete very little. There is no -r flag in there that would recursively delete anything, and without it directories will not be deleted (and even if directories were deleted, only empty ones can be deleted). This answer is predicated on the assumption that you did not run rm -rf /*.

The only files in the root filesystem of consequence may be the symlinks to the kernel and initrd (although on one Ubuntu system I'm looking at, they don't exist) or a /lib64 symlink on 64-bit systems.

The problem may just be that the /lib64 -> /lib symlink has been deleted. That's pretty nasty though, as just about every program will rely on that symlink:

$ ldd /bin/bash
...
    /lib64/ld-linux-x86-64.so.2 (0x00007f8946ab7000)

That ld-linux is the dynamic loader, and if it is not available, you cannot run any dynamic executables. This will make it extremely difficult to log in, and you may not be able to at all.

One saviour may be busybox. Run this to check:

$ ldd /bin/busybox
    not a dynamic executable

In this case, busybox should be runnable, but the question is how can you run it?

If you have access to the boot loader prompt, you may be able to boot with init=/bin/static-sh, where static-sh is a symlink to busybox (check that /bin/static-sh exists - it does on my system, but it's not standard Ubuntu. This bug suggests that is is available.)

Once you have a root shell, you can re-create the /lib64 symlink. You may need to first remount the root filesystem as read/write. busybox should have these tools built in, which you can run as follows:

# busybox mount -o remount,rw /
# busybox ln -s /lib /lib64
# /bin/bash
bash#

If bash works, the problem should be fixed.

Improve this answer
0
18

If you need to recover files from the current install, ask your host to help you. Assuming it's a VM, it takes about five minutes of their day to image your disk, reinstall your host from scratch and dump the old disk image in your new filesystem.

If you don't need anything, just get them to reinstall. Almost always the faster option when you bone things hard.

Improve this answer
1
  • 2
    Concur. If they're a reasonably competent VM hosting service, they should be able to do this. Contact them as quickly as possible to make sure they'll still have a pre-screwup backup.
    – Shadur-don't-feed-the-AI
    Commented Aug 9, 2011 at 11:03
3

If you just deleted the /lib64 symlink to /lib and you still have the console open, just do:

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

and you should be able to run commands normally again. Adjust the path to your actual ld library. You can also run any other command you want by just prefacing it with the full ld library path.

Improve this answer
1

Without having access to the physical server there isn't much you can do.

Improve this answer
2
  • So, should I ask for a format then, or is there a way to restore those files without whipping everything else?
    – Ant
    Commented Aug 8, 2011 at 23:50
  • You forget that there is a high probability that this is a virtual server in which case "physical server" doesn't mean much except having access to higher level remote tools.
    – Caleb
    Commented Aug 9, 2011 at 16:36

You must log in to answer this question.

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