I just ran (not on purpose!) rm -rf /bin.

I've booted down the computer and am using Finnix to try to recover from it. I have succeeded in mounting the drive, and confirmed that, yes, the entire /bin folder is deleted.

Is it possible to recover from this without reinstalling the OS?

I'm thinking that I could setup a VM with the same OS and architecture (Ubuntu Server 11.10 alpha release, x86) and install all the packages I had installed on the server, then just copy the /bin folder.

Will this work? Am I better off just starting over?


In general, I'd lean towards a reinstall (from the backups you are absolutely supposed to have). But I'm feeling hackish, so here's another way (assuming that your system is mounted under /target):

  1. Get a list of all the installed packages that have files in /bin:

    grep ^/bin/ /target/var/lib/dpkg/info/*.list | sed 's%^.*/\([^/\.]*\).list%\1%' >/tmp/pkglist

    (On my Debian Squeeze system that's a total of 34 packages, pretty much all of which are core)

  2. Download each of those packages (I couldn't be bothered to script this bit, so just hit up packages.ubuntu.com and download them into somewhere under /target). If you're lucky some of the packages might still be floating around in /target/var/cache/apt/archives.

  3. For each package, run /target/usr/bin/dpkg -x <package> /target. I'm fairly certain dpkg is all self-contained these days, and shouldn't call out to anything in /bin itself.

Once you've got the system back on it's feet, you should make sure and run an apt-get --reinstall install <all the packages from step 1>, because (since you're running a pre-release, which Sysadmin Cat says is a no-no on production systems) the versions of the packages you just extracted are likely to be different from those that were on the system before, and you'll want to make sure the system knows exactly what's what.

  • Nice answer, but am I missing something? Wouldn't dpkg-query -S /bin do the same than your grep .. | sed stanza? If the list needs to be cleaned up to list one package name per line, then dpkg-query -S /bin | sed 's/\,\ /\n/g' works (though having extra :/bin on the last line). – Janne Pikkarainen Aug 4 '11 at 7:55
  • 1
    Yes, it would -- I was trying to minimise the amount of stuff run in the target system in case whatever was run needed something in /bin, and I didn't want to rely on anything Debian-specific in the rescue system to make it as general as possible for future finders. – womble Aug 4 '11 at 8:20
  • It seems like this is a list of only the essential system utilities—aren't there also other packages which have files in /bin? Should I reinstall every package on my system, or just the ones generated as the result of the list? (Also: thanks, I love you!) – Tom Marthenal Aug 4 '11 at 9:05
  • 1
    Typically, only essential packages will have files in /bin -- most packages should put all their data under /usr. On my system, only a couple of non-essential packages (eg. zsh) are in the "has stuff in /bin" list. Upvotes are a great way to show love, by the way... – womble Aug 4 '11 at 9:24
  • 1
    I followed your instructions and they worked perfectly—my server is back up and running. Thanks a ton for the help! – Tom Marthenal Aug 4 '11 at 9:31

While your strategy may work (there are good chances for it, more if once you copy back the bin directory, you do an apt-get reinstall of all the packages in you system), it can yield problems in the future because you may get an unstable server.

If that would have happened to me, I would reinstall and restore from the daily backup. You have a daily backup - a disaster recovery plan - don't you?

In case you didn't have a disaster recovery plan, I would suggest to backup all the config files and the data you want to preserve and go ahead with a reinstall. That way you'll be sure that you'll end with a stable server again.

  • 1
    guessing since he posted here how to recover the /bin folder he doesn't have a backup. – Goez Aug 4 '11 at 6:26
  • Unfortunately, I have no daily backup. The bash script I was writing at the time was, ironically, a daily backup script. Looks like I'll be reinstalling—thanks for the advice. – Tom Marthenal Aug 4 '11 at 7:09
  • No need to reinstall; see my answer. – womble Aug 4 '11 at 7:27
  • File system snapshots are extremely useful for recovering from things like this. Unfortunately ext2/3/4 file systems do not implement them and doing it with LVM has a big performance penalty. If I accidentally delete /bin on my FreeBSD box, I just mount an earlier snapshot and copy the files back to the live version of the file system. OS X supposedly also has this (it is called "time machine" there). – snap Aug 4 '11 at 7:47

I would try creating a VM then copying the contents of /bin to your damaged machine. That should get you up and running. Then run

dpkg --get-selections  | awk '{print $1}' | xargs -l1 aptitude reinstall

which should reinstall all the packages that were on your system.


The easiest way, if you have access to the machine, is to mount the filesystem, take a backup of all your data (just as a precaution).

Then you can re-install ubuntu like a normal install; in principle all your data (home dir, etc and var) should still be there.

There is a way to reinstall all packages so that /bin is repopulated, but that's fairly complicated.


The files are gone. While you can attempt to "undelete" files - I wouldn't recommend it.

Note: I do not run Ubuntu (and haven't used Debian distros for a while). However I have done various distros recoveries in the past all following similar scenario.

Your best course of action:

  • boot from liveCD
  • using liveCD mount your system somplace (say, /mnt/mint)
  • using dpkg query all installed packages:
# dpkg --admindir=/mnt/mint/var/lib/dpkg -l
  • install all those packages into your /mnt/mint destination using apt-get using:
# apt-get -o RootDir=/mnt/mint .... 
  • (alternative #1) You may have to deboostrap /mnt/mint - not sure
  • (alternative #2) You may copy /bin contents of liveCD over to /mnt/mint/bin but I do not know whether liveCD for mint uses busybox which may complicate matters - alternative #1 in that case seems safer.

generally this should return your files by "brute-reinstall" of everything you have. You can do bit more "clever" tricks and query for all packages that dropped binaries in /bin

protected by Community Mar 21 '16 at 16:12

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.