Accidentally removed /bin. How do I restore it?












90















I was working on a directory named bin. After I was finished, because of the ownership of bin and some files within it I accidentally ran:



sudo rm -r /bin


Instead of:



sudo rm -r bin


It seems that my hands used to add a / in front of everything I type.



How can I restore my /bin directory?



I want the same files that belong to my Ubuntu, I don't like to copy and paste them from a live disk or another running system.










share|improve this question




















  • 3





    Isn't /bin on Ubuntu just a symlink to /usr/bin these days? So all you'd need to do is put the symlink back?

    – Muzer
    Apr 20 '17 at 12:56






  • 3





    @Muzer I'm running 16.04, and /bin is not a symbolic link to /usr/bin here, I think that would be against the FHS. also if we check a trivial package like coreutils in zesty (here). we can see a lot of things will be installed in /bin alongside the /usr/bin, but still it can be a link, I'm not aware of.

    – Ravexina
    Apr 20 '17 at 13:11








  • 2





    @Ravexina Arch Linux already symlinks /bin to /usr/bin

    – Dmitry Kudriavtsev
    Apr 20 '17 at 16:07








  • 1





    I thought that people will realize that it's a made up situation, I didn't actually removed my /bin, I considered something that could happen to anyone else (Based on another question which I answered to), Then I wrote an instruction to share my knowledge with others :), although I appreciate all comments, they are also helpful to other people who come to read this question. Thank you all ;)

    – Ravexina
    Apr 22 '17 at 4:35








  • 1





    I have gotten in the habit of whenever I use an "rm -r" command, or any other command that could have significant consequences, I type in the command and then take my hands away from the keyboard for about 3 seconds at least before hitting ENTER. That gives me a chance to look it over and make sure I have everything typed in correctly and that I know what it will do what I am planning to do. On rare occasions, during that pause, I do decide that I need to erase the command--not always because it's the wrong command, but sometimes because I need to do some verification first.

    – ajb
    Apr 23 '17 at 22:16
















90















I was working on a directory named bin. After I was finished, because of the ownership of bin and some files within it I accidentally ran:



sudo rm -r /bin


Instead of:



sudo rm -r bin


It seems that my hands used to add a / in front of everything I type.



How can I restore my /bin directory?



I want the same files that belong to my Ubuntu, I don't like to copy and paste them from a live disk or another running system.










share|improve this question




















  • 3





    Isn't /bin on Ubuntu just a symlink to /usr/bin these days? So all you'd need to do is put the symlink back?

    – Muzer
    Apr 20 '17 at 12:56






  • 3





    @Muzer I'm running 16.04, and /bin is not a symbolic link to /usr/bin here, I think that would be against the FHS. also if we check a trivial package like coreutils in zesty (here). we can see a lot of things will be installed in /bin alongside the /usr/bin, but still it can be a link, I'm not aware of.

    – Ravexina
    Apr 20 '17 at 13:11








  • 2





    @Ravexina Arch Linux already symlinks /bin to /usr/bin

    – Dmitry Kudriavtsev
    Apr 20 '17 at 16:07








  • 1





    I thought that people will realize that it's a made up situation, I didn't actually removed my /bin, I considered something that could happen to anyone else (Based on another question which I answered to), Then I wrote an instruction to share my knowledge with others :), although I appreciate all comments, they are also helpful to other people who come to read this question. Thank you all ;)

    – Ravexina
    Apr 22 '17 at 4:35








  • 1





    I have gotten in the habit of whenever I use an "rm -r" command, or any other command that could have significant consequences, I type in the command and then take my hands away from the keyboard for about 3 seconds at least before hitting ENTER. That gives me a chance to look it over and make sure I have everything typed in correctly and that I know what it will do what I am planning to do. On rare occasions, during that pause, I do decide that I need to erase the command--not always because it's the wrong command, but sometimes because I need to do some verification first.

    – ajb
    Apr 23 '17 at 22:16














90












90








90


45






I was working on a directory named bin. After I was finished, because of the ownership of bin and some files within it I accidentally ran:



sudo rm -r /bin


Instead of:



sudo rm -r bin


It seems that my hands used to add a / in front of everything I type.



How can I restore my /bin directory?



I want the same files that belong to my Ubuntu, I don't like to copy and paste them from a live disk or another running system.










share|improve this question
















I was working on a directory named bin. After I was finished, because of the ownership of bin and some files within it I accidentally ran:



sudo rm -r /bin


Instead of:



sudo rm -r bin


It seems that my hands used to add a / in front of everything I type.



How can I restore my /bin directory?



I want the same files that belong to my Ubuntu, I don't like to copy and paste them from a live disk or another running system.







command-line restore






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Apr 21 '17 at 20:11









Cyclic3

14116




14116










asked Apr 19 '17 at 15:02









RavexinaRavexina

32.3k1483113




32.3k1483113








  • 3





    Isn't /bin on Ubuntu just a symlink to /usr/bin these days? So all you'd need to do is put the symlink back?

    – Muzer
    Apr 20 '17 at 12:56






  • 3





    @Muzer I'm running 16.04, and /bin is not a symbolic link to /usr/bin here, I think that would be against the FHS. also if we check a trivial package like coreutils in zesty (here). we can see a lot of things will be installed in /bin alongside the /usr/bin, but still it can be a link, I'm not aware of.

    – Ravexina
    Apr 20 '17 at 13:11








  • 2





    @Ravexina Arch Linux already symlinks /bin to /usr/bin

    – Dmitry Kudriavtsev
    Apr 20 '17 at 16:07








  • 1





    I thought that people will realize that it's a made up situation, I didn't actually removed my /bin, I considered something that could happen to anyone else (Based on another question which I answered to), Then I wrote an instruction to share my knowledge with others :), although I appreciate all comments, they are also helpful to other people who come to read this question. Thank you all ;)

    – Ravexina
    Apr 22 '17 at 4:35








  • 1





    I have gotten in the habit of whenever I use an "rm -r" command, or any other command that could have significant consequences, I type in the command and then take my hands away from the keyboard for about 3 seconds at least before hitting ENTER. That gives me a chance to look it over and make sure I have everything typed in correctly and that I know what it will do what I am planning to do. On rare occasions, during that pause, I do decide that I need to erase the command--not always because it's the wrong command, but sometimes because I need to do some verification first.

    – ajb
    Apr 23 '17 at 22:16














  • 3





    Isn't /bin on Ubuntu just a symlink to /usr/bin these days? So all you'd need to do is put the symlink back?

    – Muzer
    Apr 20 '17 at 12:56






  • 3





    @Muzer I'm running 16.04, and /bin is not a symbolic link to /usr/bin here, I think that would be against the FHS. also if we check a trivial package like coreutils in zesty (here). we can see a lot of things will be installed in /bin alongside the /usr/bin, but still it can be a link, I'm not aware of.

    – Ravexina
    Apr 20 '17 at 13:11








  • 2





    @Ravexina Arch Linux already symlinks /bin to /usr/bin

    – Dmitry Kudriavtsev
    Apr 20 '17 at 16:07








  • 1





    I thought that people will realize that it's a made up situation, I didn't actually removed my /bin, I considered something that could happen to anyone else (Based on another question which I answered to), Then I wrote an instruction to share my knowledge with others :), although I appreciate all comments, they are also helpful to other people who come to read this question. Thank you all ;)

    – Ravexina
    Apr 22 '17 at 4:35








  • 1





    I have gotten in the habit of whenever I use an "rm -r" command, or any other command that could have significant consequences, I type in the command and then take my hands away from the keyboard for about 3 seconds at least before hitting ENTER. That gives me a chance to look it over and make sure I have everything typed in correctly and that I know what it will do what I am planning to do. On rare occasions, during that pause, I do decide that I need to erase the command--not always because it's the wrong command, but sometimes because I need to do some verification first.

    – ajb
    Apr 23 '17 at 22:16








3




3





Isn't /bin on Ubuntu just a symlink to /usr/bin these days? So all you'd need to do is put the symlink back?

– Muzer
Apr 20 '17 at 12:56





Isn't /bin on Ubuntu just a symlink to /usr/bin these days? So all you'd need to do is put the symlink back?

– Muzer
Apr 20 '17 at 12:56




3




3





@Muzer I'm running 16.04, and /bin is not a symbolic link to /usr/bin here, I think that would be against the FHS. also if we check a trivial package like coreutils in zesty (here). we can see a lot of things will be installed in /bin alongside the /usr/bin, but still it can be a link, I'm not aware of.

– Ravexina
Apr 20 '17 at 13:11







@Muzer I'm running 16.04, and /bin is not a symbolic link to /usr/bin here, I think that would be against the FHS. also if we check a trivial package like coreutils in zesty (here). we can see a lot of things will be installed in /bin alongside the /usr/bin, but still it can be a link, I'm not aware of.

– Ravexina
Apr 20 '17 at 13:11






2




2





@Ravexina Arch Linux already symlinks /bin to /usr/bin

– Dmitry Kudriavtsev
Apr 20 '17 at 16:07







@Ravexina Arch Linux already symlinks /bin to /usr/bin

– Dmitry Kudriavtsev
Apr 20 '17 at 16:07






1




1





I thought that people will realize that it's a made up situation, I didn't actually removed my /bin, I considered something that could happen to anyone else (Based on another question which I answered to), Then I wrote an instruction to share my knowledge with others :), although I appreciate all comments, they are also helpful to other people who come to read this question. Thank you all ;)

– Ravexina
Apr 22 '17 at 4:35







I thought that people will realize that it's a made up situation, I didn't actually removed my /bin, I considered something that could happen to anyone else (Based on another question which I answered to), Then I wrote an instruction to share my knowledge with others :), although I appreciate all comments, they are also helpful to other people who come to read this question. Thank you all ;)

– Ravexina
Apr 22 '17 at 4:35






1




1





I have gotten in the habit of whenever I use an "rm -r" command, or any other command that could have significant consequences, I type in the command and then take my hands away from the keyboard for about 3 seconds at least before hitting ENTER. That gives me a chance to look it over and make sure I have everything typed in correctly and that I know what it will do what I am planning to do. On rare occasions, during that pause, I do decide that I need to erase the command--not always because it's the wrong command, but sometimes because I need to do some verification first.

– ajb
Apr 23 '17 at 22:16





I have gotten in the habit of whenever I use an "rm -r" command, or any other command that could have significant consequences, I type in the command and then take my hands away from the keyboard for about 3 seconds at least before hitting ENTER. That gives me a chance to look it over and make sure I have everything typed in correctly and that I know what it will do what I am planning to do. On rare occasions, during that pause, I do decide that I need to erase the command--not always because it's the wrong command, but sometimes because I need to do some verification first.

– ajb
Apr 23 '17 at 22:16










4 Answers
4






active

oldest

votes


















179














Is it possible?



Well, most trivial and important utilities are installed in /bin, and now you lost access to all of them. In fact, if you reboot, your system will not be able to boot-up anymore.



Anyway, we are going to fix the issue and make /bin's contents as close as is possible to where it was. The only difference would be some symbolic links which we will fix too.





How?



First, we should chroot into your broken system, but with a minor difference! After that we will get a list of installed packages on your system which have any installed file in /bin directory, then we are going to only download the needed packages and extract the necessary files into /bin. Then we'll be done.



For example, after chroot, we can get a list of packages which have installed files in /bin using:



dpkg --search /bin | cut -f1 -d: | tr ',' 'n'


And we can also use:



dpkg --listfiles PACKAGE-NAME | grep "^/bin/" # or awk '$0 ~ "^/bin/


to list installed files by these packages in /bin.



Then we simply create a list of all packages that are necessary to us, then download them and extract them to /bin with something like:



xargs apt download < list-packages
dpkg-deb -x PACKAGE .
mv ./bin/* /bin


However we must use a script to check all installed packages on our system, because doing it manually is just madness.



So I wrote a script which does everything we need. It finds all necessary packages for us to restore /bin, shows us the name of each package and their related files that belongs to /bin. Here is a screenshot:



Screenshot of <code>/bin</code> package list as output by my script



At the end we choose to reinstall all packages or only download and extract the necessary files to /bin (which is the recommended option):



Screenshot of options given by my script



You can grab a copy of this script or download it directly.





Lets start



chroot



Boot your system with a live disk which has same architecture as your installed Ubuntu, open a terminal and get root access:



sudo -i


Mount your root file system (for me it's /dev/sda1):



mount /dev/sda1 /mnt


We will need connectivity to the Internet, so copy resolv.conf from live Ubuntu to your mounted root partition:



cp /etc/resolv.conf /mnt/etc/resolv.conf


Now copy the script to somewhere on the mounted partition, e.g:



cp /media/ubuntu/usb/restore-bin.sh /mnt/restore-bin.sh


or you can download it using wget, etc. like:



wget https://git.io/v9fRm -O /mnt/restore-bin.sh


Mount other necessary paths:



mount --bind /dev /mnt/dev
mount --bind /sys /mnt/sys
mount -t proc /proc /mnt/proc


And here is the minor difference: how can we chroot to a broken system when there is no /bin directory in there? Which shell should we run?



So create a temporary bin directory. e.g: named bintmp within your broken system root:



mkdir /mnt/bintmp


Then bind the live /bin into that:



mount --bind /bin /mnt/bintmp


Chroot into the system while setting the /bintmp/bash as your login shell:



chroot /mnt /bintmp/bash


Export the /bintmp as your PATH environment variable:



export PATH=/bintmp:$PATH


Give the script the executable bit:



chmod +x restore-bin.sh


Run the script:



./restore-bin.sh


Wait for the search to be completed then answer the question we saw in the screenshot. It will start to restore the /bin and we are almost done.



After it's done, use CTRL+D to get out of chroot environment and unmount the mounted paths:



umount -R /mnt


Reboot the system.



Restoring the links within /bin



Now almost all of files within /bin directory are back, except around 5 symbolic links which are managed by update-alternatives.



In your running system, run:



sudo update-alternatives --all


It asks you some questions; you can simply press ENTER to accept them all.



And now we are done.






share|improve this answer





















  • 30





    This is, without a doubt, the best answer I've seen on Ask Ubuntu. It's extremely kind of you to go to so much work knowing the OP is in an inconvenient situation.

    – Nonny Moose
    Apr 20 '17 at 0:46






  • 15





    Oh wait tl;dr. I should have realized that you did that.

    – Nonny Moose
    Apr 20 '17 at 1:27











  • This is amazing. I love how SE design does not give any hint at all that this is a self-answered question.

    – Pedro A
    Apr 23 '17 at 16:43






  • 5





    @Hamsteriffic it does: see the rectangle containing answerer's name (signature): it has a darker background, which the posts not by the OP don't. This applies to comments, answers and questions.

    – Ruslan
    Apr 23 '17 at 18:44





















27














If your current system still has a running shell and internet access, this can be done using tools existing elsewhere on the system. I'm assuming you only deleted /bin. /bin of course has the most convenient utility that you could use in such a situation (busybox), but without that, we'll have to get a little creative.





Since you already have a running shell, and since sudo is in /usr/bin, let's get ourselves a running root shell before we do further damage. But /bin/bash and most other shells are gone! Luckily, Linux still has an in-memory copy of the shell you're using. So:



sudo /proc/$$/exe


Strictly speaking we don't need a root shell for much of what follows. But anyway.



Now, dpkg still works, at least for finding which packages have files in /bin:



dpkg -S /bin


We can use awk to process it and get the package names, and xargs and apt-get to download the packages (all in /usr/bin). If you have a temporary directory that you can use, cd there, because your current directory is going to get a bit messy:



dpkg -S /bin | awk -F '[, :]' '{NF--}1' | xargs apt-get download


Now, the biggest problem we have is that /bin/tar is missing, and without it, dpkg can't extract the archives. We can get two-thirds of the way there, because:





  1. .deb files are actually ar archives (again in /usr/bin):



    ar x tar_*.deb



  2. Consisting of two .tar.* archives, data and control:



    $ echo *.tar.*
    control.tar.gz data.tar.xz



  3. While the gzip utilities are in /bin, unxz is in /usr/bin:



    unxz data.tar.xz



Now we have a data.tar file without tar to extract tar from it.



Python to the rescue! This is where sudo is really needed:



$ sudo python -c 'import tarfile; tarfile.open("data.tar").extractall("/")'
$ echo /bin/*
/bin/tar


Now we can use dpkg to extract the remaining deb files to get a reasonably complete /bin:



for i in *.deb; do dpkg-deb -x "$i" /; done


However, we should still do a proper installation of the deb files, so that symlinks etc. that would be created by packages are re-created:



sudo apt install --reinstall ./*.deb


Or:



sudo dpkg -i *.deb
sudo apt-get install -f




Notes:





  1. We can't use Python 2 to directly extract the data.tar.xz file, since Python 2 only supports gzip and bzip2 compression. Python 3, however, does support it, so you can use Python 3 directly without unxz:



    sudo python3 -c 'import tarfile; tarfile.open("data.tar.xz").extractall("/")'


  2. After getting back /bin/tar, you still need to extract some of the deb files before you can use apt-get: the shells, coreutils, etc. Easier to just extract all of them and re-install later.






share|improve this answer


























  • I didn't test it, But I almost read it completely, it was awesome, actually I tried to find a copy of bash in memory, I searched a little bit, I didn't found anything intresting and after I saw that tar is not in /usr/bin, I said whatever I go with chroot... Awesome.

    – Ravexina
    Apr 19 '17 at 16:00








  • 1





    A question, isn't /proc/$$/exe a link to /bin/bash? how does it work when /bin is removed? (It's working, but how), I thought it should be a broken link... that was why I leaved this Idea behind.

    – Ravexina
    Apr 19 '17 at 16:13








  • 3





    @Ravexina didn't get a complete answer, but: How does the /proc/<pid>/exe symlink differ from ordinary symlinks?

    – muru
    Apr 19 '17 at 16:14








  • 1





    PATH=/usr/lib/klibc/bin:$PATH will put cat and sh back in your path

    – Joshua
    Apr 21 '17 at 3:05











  • @Joshua And every one of them statically linked! Nice!

    – muru
    Apr 21 '17 at 3:51



















7














You could temporarily put files from a live CD or another system into your /bin to make your system usable, then replace them with files from your Ubuntu installation by running apt-get install --reinstall for packages which have stuff in /bin.






share|improve this answer
























  • This is what I would do. The live DVD being the same version number will be almost the same if not exactly the same as current installed. If I had a disc or USB Live version I could compare them and post an answer like yours. This thread is more a theory if OP never deleted /bin in the first place which is a possibility as he wrote the answer the same time as the question in all likelihood. Still very nice thought experiment and excellent writing style.

    – WinEunuuchs2Unix
    Apr 21 '17 at 22:12











  • I recommend to edit this answer to expand it with specific details about how to do this. (See also How do I write a good answer? for general advice about what sorts of answers are considered most valuable on AskUbuntu.)

    – David Foerster
    May 7 '17 at 14:36



















1














Some additions to this excellent answer, after I encountered this issue (along with deleting /boot, /etc, /lib and /lib64):





  • chroot requires /lib and /lib64 to be present; otherwise you will get the following error:
    failed to run command ‘/bin/bash’: No such file or directory

    I copied these from the LiveCD OS and didn't have any problems restoring. YMMV depending on the packages you have installed on the system

  • I cannot edit the answer referenced above, but there is a typo:
    cp /etc/resolv.conf /mnt/etc/resolv.cof

    should be
    cp /etc/resolv.conf /mnt/etc/resolv.conf


  • /boot can easily be restored using grub tools. See here.

  • As this answer recommends, apt install --reinstall <package> is a great way to restore missing files in /bin, /lib and /lib64.


    • Some packages that required reinstallation: libaio1, mysql-server, openvpn, vsftpd




Note to self:
rm -rf folder /* is not the same as rm -rf folder/*






share|improve this answer
























    protected by Ravexina Sep 2 '18 at 13:39



    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?














    4 Answers
    4






    active

    oldest

    votes








    4 Answers
    4






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    179














    Is it possible?



    Well, most trivial and important utilities are installed in /bin, and now you lost access to all of them. In fact, if you reboot, your system will not be able to boot-up anymore.



    Anyway, we are going to fix the issue and make /bin's contents as close as is possible to where it was. The only difference would be some symbolic links which we will fix too.





    How?



    First, we should chroot into your broken system, but with a minor difference! After that we will get a list of installed packages on your system which have any installed file in /bin directory, then we are going to only download the needed packages and extract the necessary files into /bin. Then we'll be done.



    For example, after chroot, we can get a list of packages which have installed files in /bin using:



    dpkg --search /bin | cut -f1 -d: | tr ',' 'n'


    And we can also use:



    dpkg --listfiles PACKAGE-NAME | grep "^/bin/" # or awk '$0 ~ "^/bin/


    to list installed files by these packages in /bin.



    Then we simply create a list of all packages that are necessary to us, then download them and extract them to /bin with something like:



    xargs apt download < list-packages
    dpkg-deb -x PACKAGE .
    mv ./bin/* /bin


    However we must use a script to check all installed packages on our system, because doing it manually is just madness.



    So I wrote a script which does everything we need. It finds all necessary packages for us to restore /bin, shows us the name of each package and their related files that belongs to /bin. Here is a screenshot:



    Screenshot of <code>/bin</code> package list as output by my script



    At the end we choose to reinstall all packages or only download and extract the necessary files to /bin (which is the recommended option):



    Screenshot of options given by my script



    You can grab a copy of this script or download it directly.





    Lets start



    chroot



    Boot your system with a live disk which has same architecture as your installed Ubuntu, open a terminal and get root access:



    sudo -i


    Mount your root file system (for me it's /dev/sda1):



    mount /dev/sda1 /mnt


    We will need connectivity to the Internet, so copy resolv.conf from live Ubuntu to your mounted root partition:



    cp /etc/resolv.conf /mnt/etc/resolv.conf


    Now copy the script to somewhere on the mounted partition, e.g:



    cp /media/ubuntu/usb/restore-bin.sh /mnt/restore-bin.sh


    or you can download it using wget, etc. like:



    wget https://git.io/v9fRm -O /mnt/restore-bin.sh


    Mount other necessary paths:



    mount --bind /dev /mnt/dev
    mount --bind /sys /mnt/sys
    mount -t proc /proc /mnt/proc


    And here is the minor difference: how can we chroot to a broken system when there is no /bin directory in there? Which shell should we run?



    So create a temporary bin directory. e.g: named bintmp within your broken system root:



    mkdir /mnt/bintmp


    Then bind the live /bin into that:



    mount --bind /bin /mnt/bintmp


    Chroot into the system while setting the /bintmp/bash as your login shell:



    chroot /mnt /bintmp/bash


    Export the /bintmp as your PATH environment variable:



    export PATH=/bintmp:$PATH


    Give the script the executable bit:



    chmod +x restore-bin.sh


    Run the script:



    ./restore-bin.sh


    Wait for the search to be completed then answer the question we saw in the screenshot. It will start to restore the /bin and we are almost done.



    After it's done, use CTRL+D to get out of chroot environment and unmount the mounted paths:



    umount -R /mnt


    Reboot the system.



    Restoring the links within /bin



    Now almost all of files within /bin directory are back, except around 5 symbolic links which are managed by update-alternatives.



    In your running system, run:



    sudo update-alternatives --all


    It asks you some questions; you can simply press ENTER to accept them all.



    And now we are done.






    share|improve this answer





















    • 30





      This is, without a doubt, the best answer I've seen on Ask Ubuntu. It's extremely kind of you to go to so much work knowing the OP is in an inconvenient situation.

      – Nonny Moose
      Apr 20 '17 at 0:46






    • 15





      Oh wait tl;dr. I should have realized that you did that.

      – Nonny Moose
      Apr 20 '17 at 1:27











    • This is amazing. I love how SE design does not give any hint at all that this is a self-answered question.

      – Pedro A
      Apr 23 '17 at 16:43






    • 5





      @Hamsteriffic it does: see the rectangle containing answerer's name (signature): it has a darker background, which the posts not by the OP don't. This applies to comments, answers and questions.

      – Ruslan
      Apr 23 '17 at 18:44


















    179














    Is it possible?



    Well, most trivial and important utilities are installed in /bin, and now you lost access to all of them. In fact, if you reboot, your system will not be able to boot-up anymore.



    Anyway, we are going to fix the issue and make /bin's contents as close as is possible to where it was. The only difference would be some symbolic links which we will fix too.





    How?



    First, we should chroot into your broken system, but with a minor difference! After that we will get a list of installed packages on your system which have any installed file in /bin directory, then we are going to only download the needed packages and extract the necessary files into /bin. Then we'll be done.



    For example, after chroot, we can get a list of packages which have installed files in /bin using:



    dpkg --search /bin | cut -f1 -d: | tr ',' 'n'


    And we can also use:



    dpkg --listfiles PACKAGE-NAME | grep "^/bin/" # or awk '$0 ~ "^/bin/


    to list installed files by these packages in /bin.



    Then we simply create a list of all packages that are necessary to us, then download them and extract them to /bin with something like:



    xargs apt download < list-packages
    dpkg-deb -x PACKAGE .
    mv ./bin/* /bin


    However we must use a script to check all installed packages on our system, because doing it manually is just madness.



    So I wrote a script which does everything we need. It finds all necessary packages for us to restore /bin, shows us the name of each package and their related files that belongs to /bin. Here is a screenshot:



    Screenshot of <code>/bin</code> package list as output by my script



    At the end we choose to reinstall all packages or only download and extract the necessary files to /bin (which is the recommended option):



    Screenshot of options given by my script



    You can grab a copy of this script or download it directly.





    Lets start



    chroot



    Boot your system with a live disk which has same architecture as your installed Ubuntu, open a terminal and get root access:



    sudo -i


    Mount your root file system (for me it's /dev/sda1):



    mount /dev/sda1 /mnt


    We will need connectivity to the Internet, so copy resolv.conf from live Ubuntu to your mounted root partition:



    cp /etc/resolv.conf /mnt/etc/resolv.conf


    Now copy the script to somewhere on the mounted partition, e.g:



    cp /media/ubuntu/usb/restore-bin.sh /mnt/restore-bin.sh


    or you can download it using wget, etc. like:



    wget https://git.io/v9fRm -O /mnt/restore-bin.sh


    Mount other necessary paths:



    mount --bind /dev /mnt/dev
    mount --bind /sys /mnt/sys
    mount -t proc /proc /mnt/proc


    And here is the minor difference: how can we chroot to a broken system when there is no /bin directory in there? Which shell should we run?



    So create a temporary bin directory. e.g: named bintmp within your broken system root:



    mkdir /mnt/bintmp


    Then bind the live /bin into that:



    mount --bind /bin /mnt/bintmp


    Chroot into the system while setting the /bintmp/bash as your login shell:



    chroot /mnt /bintmp/bash


    Export the /bintmp as your PATH environment variable:



    export PATH=/bintmp:$PATH


    Give the script the executable bit:



    chmod +x restore-bin.sh


    Run the script:



    ./restore-bin.sh


    Wait for the search to be completed then answer the question we saw in the screenshot. It will start to restore the /bin and we are almost done.



    After it's done, use CTRL+D to get out of chroot environment and unmount the mounted paths:



    umount -R /mnt


    Reboot the system.



    Restoring the links within /bin



    Now almost all of files within /bin directory are back, except around 5 symbolic links which are managed by update-alternatives.



    In your running system, run:



    sudo update-alternatives --all


    It asks you some questions; you can simply press ENTER to accept them all.



    And now we are done.






    share|improve this answer





















    • 30





      This is, without a doubt, the best answer I've seen on Ask Ubuntu. It's extremely kind of you to go to so much work knowing the OP is in an inconvenient situation.

      – Nonny Moose
      Apr 20 '17 at 0:46






    • 15





      Oh wait tl;dr. I should have realized that you did that.

      – Nonny Moose
      Apr 20 '17 at 1:27











    • This is amazing. I love how SE design does not give any hint at all that this is a self-answered question.

      – Pedro A
      Apr 23 '17 at 16:43






    • 5





      @Hamsteriffic it does: see the rectangle containing answerer's name (signature): it has a darker background, which the posts not by the OP don't. This applies to comments, answers and questions.

      – Ruslan
      Apr 23 '17 at 18:44
















    179












    179








    179







    Is it possible?



    Well, most trivial and important utilities are installed in /bin, and now you lost access to all of them. In fact, if you reboot, your system will not be able to boot-up anymore.



    Anyway, we are going to fix the issue and make /bin's contents as close as is possible to where it was. The only difference would be some symbolic links which we will fix too.





    How?



    First, we should chroot into your broken system, but with a minor difference! After that we will get a list of installed packages on your system which have any installed file in /bin directory, then we are going to only download the needed packages and extract the necessary files into /bin. Then we'll be done.



    For example, after chroot, we can get a list of packages which have installed files in /bin using:



    dpkg --search /bin | cut -f1 -d: | tr ',' 'n'


    And we can also use:



    dpkg --listfiles PACKAGE-NAME | grep "^/bin/" # or awk '$0 ~ "^/bin/


    to list installed files by these packages in /bin.



    Then we simply create a list of all packages that are necessary to us, then download them and extract them to /bin with something like:



    xargs apt download < list-packages
    dpkg-deb -x PACKAGE .
    mv ./bin/* /bin


    However we must use a script to check all installed packages on our system, because doing it manually is just madness.



    So I wrote a script which does everything we need. It finds all necessary packages for us to restore /bin, shows us the name of each package and their related files that belongs to /bin. Here is a screenshot:



    Screenshot of <code>/bin</code> package list as output by my script



    At the end we choose to reinstall all packages or only download and extract the necessary files to /bin (which is the recommended option):



    Screenshot of options given by my script



    You can grab a copy of this script or download it directly.





    Lets start



    chroot



    Boot your system with a live disk which has same architecture as your installed Ubuntu, open a terminal and get root access:



    sudo -i


    Mount your root file system (for me it's /dev/sda1):



    mount /dev/sda1 /mnt


    We will need connectivity to the Internet, so copy resolv.conf from live Ubuntu to your mounted root partition:



    cp /etc/resolv.conf /mnt/etc/resolv.conf


    Now copy the script to somewhere on the mounted partition, e.g:



    cp /media/ubuntu/usb/restore-bin.sh /mnt/restore-bin.sh


    or you can download it using wget, etc. like:



    wget https://git.io/v9fRm -O /mnt/restore-bin.sh


    Mount other necessary paths:



    mount --bind /dev /mnt/dev
    mount --bind /sys /mnt/sys
    mount -t proc /proc /mnt/proc


    And here is the minor difference: how can we chroot to a broken system when there is no /bin directory in there? Which shell should we run?



    So create a temporary bin directory. e.g: named bintmp within your broken system root:



    mkdir /mnt/bintmp


    Then bind the live /bin into that:



    mount --bind /bin /mnt/bintmp


    Chroot into the system while setting the /bintmp/bash as your login shell:



    chroot /mnt /bintmp/bash


    Export the /bintmp as your PATH environment variable:



    export PATH=/bintmp:$PATH


    Give the script the executable bit:



    chmod +x restore-bin.sh


    Run the script:



    ./restore-bin.sh


    Wait for the search to be completed then answer the question we saw in the screenshot. It will start to restore the /bin and we are almost done.



    After it's done, use CTRL+D to get out of chroot environment and unmount the mounted paths:



    umount -R /mnt


    Reboot the system.



    Restoring the links within /bin



    Now almost all of files within /bin directory are back, except around 5 symbolic links which are managed by update-alternatives.



    In your running system, run:



    sudo update-alternatives --all


    It asks you some questions; you can simply press ENTER to accept them all.



    And now we are done.






    share|improve this answer















    Is it possible?



    Well, most trivial and important utilities are installed in /bin, and now you lost access to all of them. In fact, if you reboot, your system will not be able to boot-up anymore.



    Anyway, we are going to fix the issue and make /bin's contents as close as is possible to where it was. The only difference would be some symbolic links which we will fix too.





    How?



    First, we should chroot into your broken system, but with a minor difference! After that we will get a list of installed packages on your system which have any installed file in /bin directory, then we are going to only download the needed packages and extract the necessary files into /bin. Then we'll be done.



    For example, after chroot, we can get a list of packages which have installed files in /bin using:



    dpkg --search /bin | cut -f1 -d: | tr ',' 'n'


    And we can also use:



    dpkg --listfiles PACKAGE-NAME | grep "^/bin/" # or awk '$0 ~ "^/bin/


    to list installed files by these packages in /bin.



    Then we simply create a list of all packages that are necessary to us, then download them and extract them to /bin with something like:



    xargs apt download < list-packages
    dpkg-deb -x PACKAGE .
    mv ./bin/* /bin


    However we must use a script to check all installed packages on our system, because doing it manually is just madness.



    So I wrote a script which does everything we need. It finds all necessary packages for us to restore /bin, shows us the name of each package and their related files that belongs to /bin. Here is a screenshot:



    Screenshot of <code>/bin</code> package list as output by my script



    At the end we choose to reinstall all packages or only download and extract the necessary files to /bin (which is the recommended option):



    Screenshot of options given by my script



    You can grab a copy of this script or download it directly.





    Lets start



    chroot



    Boot your system with a live disk which has same architecture as your installed Ubuntu, open a terminal and get root access:



    sudo -i


    Mount your root file system (for me it's /dev/sda1):



    mount /dev/sda1 /mnt


    We will need connectivity to the Internet, so copy resolv.conf from live Ubuntu to your mounted root partition:



    cp /etc/resolv.conf /mnt/etc/resolv.conf


    Now copy the script to somewhere on the mounted partition, e.g:



    cp /media/ubuntu/usb/restore-bin.sh /mnt/restore-bin.sh


    or you can download it using wget, etc. like:



    wget https://git.io/v9fRm -O /mnt/restore-bin.sh


    Mount other necessary paths:



    mount --bind /dev /mnt/dev
    mount --bind /sys /mnt/sys
    mount -t proc /proc /mnt/proc


    And here is the minor difference: how can we chroot to a broken system when there is no /bin directory in there? Which shell should we run?



    So create a temporary bin directory. e.g: named bintmp within your broken system root:



    mkdir /mnt/bintmp


    Then bind the live /bin into that:



    mount --bind /bin /mnt/bintmp


    Chroot into the system while setting the /bintmp/bash as your login shell:



    chroot /mnt /bintmp/bash


    Export the /bintmp as your PATH environment variable:



    export PATH=/bintmp:$PATH


    Give the script the executable bit:



    chmod +x restore-bin.sh


    Run the script:



    ./restore-bin.sh


    Wait for the search to be completed then answer the question we saw in the screenshot. It will start to restore the /bin and we are almost done.



    After it's done, use CTRL+D to get out of chroot environment and unmount the mounted paths:



    umount -R /mnt


    Reboot the system.



    Restoring the links within /bin



    Now almost all of files within /bin directory are back, except around 5 symbolic links which are managed by update-alternatives.



    In your running system, run:



    sudo update-alternatives --all


    It asks you some questions; you can simply press ENTER to accept them all.



    And now we are done.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited 10 hours ago









    mature

    2,0031726




    2,0031726










    answered Apr 19 '17 at 15:02









    RavexinaRavexina

    32.3k1483113




    32.3k1483113








    • 30





      This is, without a doubt, the best answer I've seen on Ask Ubuntu. It's extremely kind of you to go to so much work knowing the OP is in an inconvenient situation.

      – Nonny Moose
      Apr 20 '17 at 0:46






    • 15





      Oh wait tl;dr. I should have realized that you did that.

      – Nonny Moose
      Apr 20 '17 at 1:27











    • This is amazing. I love how SE design does not give any hint at all that this is a self-answered question.

      – Pedro A
      Apr 23 '17 at 16:43






    • 5





      @Hamsteriffic it does: see the rectangle containing answerer's name (signature): it has a darker background, which the posts not by the OP don't. This applies to comments, answers and questions.

      – Ruslan
      Apr 23 '17 at 18:44
















    • 30





      This is, without a doubt, the best answer I've seen on Ask Ubuntu. It's extremely kind of you to go to so much work knowing the OP is in an inconvenient situation.

      – Nonny Moose
      Apr 20 '17 at 0:46






    • 15





      Oh wait tl;dr. I should have realized that you did that.

      – Nonny Moose
      Apr 20 '17 at 1:27











    • This is amazing. I love how SE design does not give any hint at all that this is a self-answered question.

      – Pedro A
      Apr 23 '17 at 16:43






    • 5





      @Hamsteriffic it does: see the rectangle containing answerer's name (signature): it has a darker background, which the posts not by the OP don't. This applies to comments, answers and questions.

      – Ruslan
      Apr 23 '17 at 18:44










    30




    30





    This is, without a doubt, the best answer I've seen on Ask Ubuntu. It's extremely kind of you to go to so much work knowing the OP is in an inconvenient situation.

    – Nonny Moose
    Apr 20 '17 at 0:46





    This is, without a doubt, the best answer I've seen on Ask Ubuntu. It's extremely kind of you to go to so much work knowing the OP is in an inconvenient situation.

    – Nonny Moose
    Apr 20 '17 at 0:46




    15




    15





    Oh wait tl;dr. I should have realized that you did that.

    – Nonny Moose
    Apr 20 '17 at 1:27





    Oh wait tl;dr. I should have realized that you did that.

    – Nonny Moose
    Apr 20 '17 at 1:27













    This is amazing. I love how SE design does not give any hint at all that this is a self-answered question.

    – Pedro A
    Apr 23 '17 at 16:43





    This is amazing. I love how SE design does not give any hint at all that this is a self-answered question.

    – Pedro A
    Apr 23 '17 at 16:43




    5




    5





    @Hamsteriffic it does: see the rectangle containing answerer's name (signature): it has a darker background, which the posts not by the OP don't. This applies to comments, answers and questions.

    – Ruslan
    Apr 23 '17 at 18:44







    @Hamsteriffic it does: see the rectangle containing answerer's name (signature): it has a darker background, which the posts not by the OP don't. This applies to comments, answers and questions.

    – Ruslan
    Apr 23 '17 at 18:44















    27














    If your current system still has a running shell and internet access, this can be done using tools existing elsewhere on the system. I'm assuming you only deleted /bin. /bin of course has the most convenient utility that you could use in such a situation (busybox), but without that, we'll have to get a little creative.





    Since you already have a running shell, and since sudo is in /usr/bin, let's get ourselves a running root shell before we do further damage. But /bin/bash and most other shells are gone! Luckily, Linux still has an in-memory copy of the shell you're using. So:



    sudo /proc/$$/exe


    Strictly speaking we don't need a root shell for much of what follows. But anyway.



    Now, dpkg still works, at least for finding which packages have files in /bin:



    dpkg -S /bin


    We can use awk to process it and get the package names, and xargs and apt-get to download the packages (all in /usr/bin). If you have a temporary directory that you can use, cd there, because your current directory is going to get a bit messy:



    dpkg -S /bin | awk -F '[, :]' '{NF--}1' | xargs apt-get download


    Now, the biggest problem we have is that /bin/tar is missing, and without it, dpkg can't extract the archives. We can get two-thirds of the way there, because:





    1. .deb files are actually ar archives (again in /usr/bin):



      ar x tar_*.deb



    2. Consisting of two .tar.* archives, data and control:



      $ echo *.tar.*
      control.tar.gz data.tar.xz



    3. While the gzip utilities are in /bin, unxz is in /usr/bin:



      unxz data.tar.xz



    Now we have a data.tar file without tar to extract tar from it.



    Python to the rescue! This is where sudo is really needed:



    $ sudo python -c 'import tarfile; tarfile.open("data.tar").extractall("/")'
    $ echo /bin/*
    /bin/tar


    Now we can use dpkg to extract the remaining deb files to get a reasonably complete /bin:



    for i in *.deb; do dpkg-deb -x "$i" /; done


    However, we should still do a proper installation of the deb files, so that symlinks etc. that would be created by packages are re-created:



    sudo apt install --reinstall ./*.deb


    Or:



    sudo dpkg -i *.deb
    sudo apt-get install -f




    Notes:





    1. We can't use Python 2 to directly extract the data.tar.xz file, since Python 2 only supports gzip and bzip2 compression. Python 3, however, does support it, so you can use Python 3 directly without unxz:



      sudo python3 -c 'import tarfile; tarfile.open("data.tar.xz").extractall("/")'


    2. After getting back /bin/tar, you still need to extract some of the deb files before you can use apt-get: the shells, coreutils, etc. Easier to just extract all of them and re-install later.






    share|improve this answer


























    • I didn't test it, But I almost read it completely, it was awesome, actually I tried to find a copy of bash in memory, I searched a little bit, I didn't found anything intresting and after I saw that tar is not in /usr/bin, I said whatever I go with chroot... Awesome.

      – Ravexina
      Apr 19 '17 at 16:00








    • 1





      A question, isn't /proc/$$/exe a link to /bin/bash? how does it work when /bin is removed? (It's working, but how), I thought it should be a broken link... that was why I leaved this Idea behind.

      – Ravexina
      Apr 19 '17 at 16:13








    • 3





      @Ravexina didn't get a complete answer, but: How does the /proc/<pid>/exe symlink differ from ordinary symlinks?

      – muru
      Apr 19 '17 at 16:14








    • 1





      PATH=/usr/lib/klibc/bin:$PATH will put cat and sh back in your path

      – Joshua
      Apr 21 '17 at 3:05











    • @Joshua And every one of them statically linked! Nice!

      – muru
      Apr 21 '17 at 3:51
















    27














    If your current system still has a running shell and internet access, this can be done using tools existing elsewhere on the system. I'm assuming you only deleted /bin. /bin of course has the most convenient utility that you could use in such a situation (busybox), but without that, we'll have to get a little creative.





    Since you already have a running shell, and since sudo is in /usr/bin, let's get ourselves a running root shell before we do further damage. But /bin/bash and most other shells are gone! Luckily, Linux still has an in-memory copy of the shell you're using. So:



    sudo /proc/$$/exe


    Strictly speaking we don't need a root shell for much of what follows. But anyway.



    Now, dpkg still works, at least for finding which packages have files in /bin:



    dpkg -S /bin


    We can use awk to process it and get the package names, and xargs and apt-get to download the packages (all in /usr/bin). If you have a temporary directory that you can use, cd there, because your current directory is going to get a bit messy:



    dpkg -S /bin | awk -F '[, :]' '{NF--}1' | xargs apt-get download


    Now, the biggest problem we have is that /bin/tar is missing, and without it, dpkg can't extract the archives. We can get two-thirds of the way there, because:





    1. .deb files are actually ar archives (again in /usr/bin):



      ar x tar_*.deb



    2. Consisting of two .tar.* archives, data and control:



      $ echo *.tar.*
      control.tar.gz data.tar.xz



    3. While the gzip utilities are in /bin, unxz is in /usr/bin:



      unxz data.tar.xz



    Now we have a data.tar file without tar to extract tar from it.



    Python to the rescue! This is where sudo is really needed:



    $ sudo python -c 'import tarfile; tarfile.open("data.tar").extractall("/")'
    $ echo /bin/*
    /bin/tar


    Now we can use dpkg to extract the remaining deb files to get a reasonably complete /bin:



    for i in *.deb; do dpkg-deb -x "$i" /; done


    However, we should still do a proper installation of the deb files, so that symlinks etc. that would be created by packages are re-created:



    sudo apt install --reinstall ./*.deb


    Or:



    sudo dpkg -i *.deb
    sudo apt-get install -f




    Notes:





    1. We can't use Python 2 to directly extract the data.tar.xz file, since Python 2 only supports gzip and bzip2 compression. Python 3, however, does support it, so you can use Python 3 directly without unxz:



      sudo python3 -c 'import tarfile; tarfile.open("data.tar.xz").extractall("/")'


    2. After getting back /bin/tar, you still need to extract some of the deb files before you can use apt-get: the shells, coreutils, etc. Easier to just extract all of them and re-install later.






    share|improve this answer


























    • I didn't test it, But I almost read it completely, it was awesome, actually I tried to find a copy of bash in memory, I searched a little bit, I didn't found anything intresting and after I saw that tar is not in /usr/bin, I said whatever I go with chroot... Awesome.

      – Ravexina
      Apr 19 '17 at 16:00








    • 1





      A question, isn't /proc/$$/exe a link to /bin/bash? how does it work when /bin is removed? (It's working, but how), I thought it should be a broken link... that was why I leaved this Idea behind.

      – Ravexina
      Apr 19 '17 at 16:13








    • 3





      @Ravexina didn't get a complete answer, but: How does the /proc/<pid>/exe symlink differ from ordinary symlinks?

      – muru
      Apr 19 '17 at 16:14








    • 1





      PATH=/usr/lib/klibc/bin:$PATH will put cat and sh back in your path

      – Joshua
      Apr 21 '17 at 3:05











    • @Joshua And every one of them statically linked! Nice!

      – muru
      Apr 21 '17 at 3:51














    27












    27








    27







    If your current system still has a running shell and internet access, this can be done using tools existing elsewhere on the system. I'm assuming you only deleted /bin. /bin of course has the most convenient utility that you could use in such a situation (busybox), but without that, we'll have to get a little creative.





    Since you already have a running shell, and since sudo is in /usr/bin, let's get ourselves a running root shell before we do further damage. But /bin/bash and most other shells are gone! Luckily, Linux still has an in-memory copy of the shell you're using. So:



    sudo /proc/$$/exe


    Strictly speaking we don't need a root shell for much of what follows. But anyway.



    Now, dpkg still works, at least for finding which packages have files in /bin:



    dpkg -S /bin


    We can use awk to process it and get the package names, and xargs and apt-get to download the packages (all in /usr/bin). If you have a temporary directory that you can use, cd there, because your current directory is going to get a bit messy:



    dpkg -S /bin | awk -F '[, :]' '{NF--}1' | xargs apt-get download


    Now, the biggest problem we have is that /bin/tar is missing, and without it, dpkg can't extract the archives. We can get two-thirds of the way there, because:





    1. .deb files are actually ar archives (again in /usr/bin):



      ar x tar_*.deb



    2. Consisting of two .tar.* archives, data and control:



      $ echo *.tar.*
      control.tar.gz data.tar.xz



    3. While the gzip utilities are in /bin, unxz is in /usr/bin:



      unxz data.tar.xz



    Now we have a data.tar file without tar to extract tar from it.



    Python to the rescue! This is where sudo is really needed:



    $ sudo python -c 'import tarfile; tarfile.open("data.tar").extractall("/")'
    $ echo /bin/*
    /bin/tar


    Now we can use dpkg to extract the remaining deb files to get a reasonably complete /bin:



    for i in *.deb; do dpkg-deb -x "$i" /; done


    However, we should still do a proper installation of the deb files, so that symlinks etc. that would be created by packages are re-created:



    sudo apt install --reinstall ./*.deb


    Or:



    sudo dpkg -i *.deb
    sudo apt-get install -f




    Notes:





    1. We can't use Python 2 to directly extract the data.tar.xz file, since Python 2 only supports gzip and bzip2 compression. Python 3, however, does support it, so you can use Python 3 directly without unxz:



      sudo python3 -c 'import tarfile; tarfile.open("data.tar.xz").extractall("/")'


    2. After getting back /bin/tar, you still need to extract some of the deb files before you can use apt-get: the shells, coreutils, etc. Easier to just extract all of them and re-install later.






    share|improve this answer















    If your current system still has a running shell and internet access, this can be done using tools existing elsewhere on the system. I'm assuming you only deleted /bin. /bin of course has the most convenient utility that you could use in such a situation (busybox), but without that, we'll have to get a little creative.





    Since you already have a running shell, and since sudo is in /usr/bin, let's get ourselves a running root shell before we do further damage. But /bin/bash and most other shells are gone! Luckily, Linux still has an in-memory copy of the shell you're using. So:



    sudo /proc/$$/exe


    Strictly speaking we don't need a root shell for much of what follows. But anyway.



    Now, dpkg still works, at least for finding which packages have files in /bin:



    dpkg -S /bin


    We can use awk to process it and get the package names, and xargs and apt-get to download the packages (all in /usr/bin). If you have a temporary directory that you can use, cd there, because your current directory is going to get a bit messy:



    dpkg -S /bin | awk -F '[, :]' '{NF--}1' | xargs apt-get download


    Now, the biggest problem we have is that /bin/tar is missing, and without it, dpkg can't extract the archives. We can get two-thirds of the way there, because:





    1. .deb files are actually ar archives (again in /usr/bin):



      ar x tar_*.deb



    2. Consisting of two .tar.* archives, data and control:



      $ echo *.tar.*
      control.tar.gz data.tar.xz



    3. While the gzip utilities are in /bin, unxz is in /usr/bin:



      unxz data.tar.xz



    Now we have a data.tar file without tar to extract tar from it.



    Python to the rescue! This is where sudo is really needed:



    $ sudo python -c 'import tarfile; tarfile.open("data.tar").extractall("/")'
    $ echo /bin/*
    /bin/tar


    Now we can use dpkg to extract the remaining deb files to get a reasonably complete /bin:



    for i in *.deb; do dpkg-deb -x "$i" /; done


    However, we should still do a proper installation of the deb files, so that symlinks etc. that would be created by packages are re-created:



    sudo apt install --reinstall ./*.deb


    Or:



    sudo dpkg -i *.deb
    sudo apt-get install -f




    Notes:





    1. We can't use Python 2 to directly extract the data.tar.xz file, since Python 2 only supports gzip and bzip2 compression. Python 3, however, does support it, so you can use Python 3 directly without unxz:



      sudo python3 -c 'import tarfile; tarfile.open("data.tar.xz").extractall("/")'


    2. After getting back /bin/tar, you still need to extract some of the deb files before you can use apt-get: the shells, coreutils, etc. Easier to just extract all of them and re-install later.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Apr 19 '17 at 16:04

























    answered Apr 19 '17 at 15:49









    murumuru

    1




    1













    • I didn't test it, But I almost read it completely, it was awesome, actually I tried to find a copy of bash in memory, I searched a little bit, I didn't found anything intresting and after I saw that tar is not in /usr/bin, I said whatever I go with chroot... Awesome.

      – Ravexina
      Apr 19 '17 at 16:00








    • 1





      A question, isn't /proc/$$/exe a link to /bin/bash? how does it work when /bin is removed? (It's working, but how), I thought it should be a broken link... that was why I leaved this Idea behind.

      – Ravexina
      Apr 19 '17 at 16:13








    • 3





      @Ravexina didn't get a complete answer, but: How does the /proc/<pid>/exe symlink differ from ordinary symlinks?

      – muru
      Apr 19 '17 at 16:14








    • 1





      PATH=/usr/lib/klibc/bin:$PATH will put cat and sh back in your path

      – Joshua
      Apr 21 '17 at 3:05











    • @Joshua And every one of them statically linked! Nice!

      – muru
      Apr 21 '17 at 3:51



















    • I didn't test it, But I almost read it completely, it was awesome, actually I tried to find a copy of bash in memory, I searched a little bit, I didn't found anything intresting and after I saw that tar is not in /usr/bin, I said whatever I go with chroot... Awesome.

      – Ravexina
      Apr 19 '17 at 16:00








    • 1





      A question, isn't /proc/$$/exe a link to /bin/bash? how does it work when /bin is removed? (It's working, but how), I thought it should be a broken link... that was why I leaved this Idea behind.

      – Ravexina
      Apr 19 '17 at 16:13








    • 3





      @Ravexina didn't get a complete answer, but: How does the /proc/<pid>/exe symlink differ from ordinary symlinks?

      – muru
      Apr 19 '17 at 16:14








    • 1





      PATH=/usr/lib/klibc/bin:$PATH will put cat and sh back in your path

      – Joshua
      Apr 21 '17 at 3:05











    • @Joshua And every one of them statically linked! Nice!

      – muru
      Apr 21 '17 at 3:51

















    I didn't test it, But I almost read it completely, it was awesome, actually I tried to find a copy of bash in memory, I searched a little bit, I didn't found anything intresting and after I saw that tar is not in /usr/bin, I said whatever I go with chroot... Awesome.

    – Ravexina
    Apr 19 '17 at 16:00







    I didn't test it, But I almost read it completely, it was awesome, actually I tried to find a copy of bash in memory, I searched a little bit, I didn't found anything intresting and after I saw that tar is not in /usr/bin, I said whatever I go with chroot... Awesome.

    – Ravexina
    Apr 19 '17 at 16:00






    1




    1





    A question, isn't /proc/$$/exe a link to /bin/bash? how does it work when /bin is removed? (It's working, but how), I thought it should be a broken link... that was why I leaved this Idea behind.

    – Ravexina
    Apr 19 '17 at 16:13







    A question, isn't /proc/$$/exe a link to /bin/bash? how does it work when /bin is removed? (It's working, but how), I thought it should be a broken link... that was why I leaved this Idea behind.

    – Ravexina
    Apr 19 '17 at 16:13






    3




    3





    @Ravexina didn't get a complete answer, but: How does the /proc/<pid>/exe symlink differ from ordinary symlinks?

    – muru
    Apr 19 '17 at 16:14







    @Ravexina didn't get a complete answer, but: How does the /proc/<pid>/exe symlink differ from ordinary symlinks?

    – muru
    Apr 19 '17 at 16:14






    1




    1





    PATH=/usr/lib/klibc/bin:$PATH will put cat and sh back in your path

    – Joshua
    Apr 21 '17 at 3:05





    PATH=/usr/lib/klibc/bin:$PATH will put cat and sh back in your path

    – Joshua
    Apr 21 '17 at 3:05













    @Joshua And every one of them statically linked! Nice!

    – muru
    Apr 21 '17 at 3:51





    @Joshua And every one of them statically linked! Nice!

    – muru
    Apr 21 '17 at 3:51











    7














    You could temporarily put files from a live CD or another system into your /bin to make your system usable, then replace them with files from your Ubuntu installation by running apt-get install --reinstall for packages which have stuff in /bin.






    share|improve this answer
























    • This is what I would do. The live DVD being the same version number will be almost the same if not exactly the same as current installed. If I had a disc or USB Live version I could compare them and post an answer like yours. This thread is more a theory if OP never deleted /bin in the first place which is a possibility as he wrote the answer the same time as the question in all likelihood. Still very nice thought experiment and excellent writing style.

      – WinEunuuchs2Unix
      Apr 21 '17 at 22:12











    • I recommend to edit this answer to expand it with specific details about how to do this. (See also How do I write a good answer? for general advice about what sorts of answers are considered most valuable on AskUbuntu.)

      – David Foerster
      May 7 '17 at 14:36
















    7














    You could temporarily put files from a live CD or another system into your /bin to make your system usable, then replace them with files from your Ubuntu installation by running apt-get install --reinstall for packages which have stuff in /bin.






    share|improve this answer
























    • This is what I would do. The live DVD being the same version number will be almost the same if not exactly the same as current installed. If I had a disc or USB Live version I could compare them and post an answer like yours. This thread is more a theory if OP never deleted /bin in the first place which is a possibility as he wrote the answer the same time as the question in all likelihood. Still very nice thought experiment and excellent writing style.

      – WinEunuuchs2Unix
      Apr 21 '17 at 22:12











    • I recommend to edit this answer to expand it with specific details about how to do this. (See also How do I write a good answer? for general advice about what sorts of answers are considered most valuable on AskUbuntu.)

      – David Foerster
      May 7 '17 at 14:36














    7












    7








    7







    You could temporarily put files from a live CD or another system into your /bin to make your system usable, then replace them with files from your Ubuntu installation by running apt-get install --reinstall for packages which have stuff in /bin.






    share|improve this answer













    You could temporarily put files from a live CD or another system into your /bin to make your system usable, then replace them with files from your Ubuntu installation by running apt-get install --reinstall for packages which have stuff in /bin.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Apr 20 '17 at 11:21









    Dmitry GrigoryevDmitry Grigoryev

    1,586619




    1,586619













    • This is what I would do. The live DVD being the same version number will be almost the same if not exactly the same as current installed. If I had a disc or USB Live version I could compare them and post an answer like yours. This thread is more a theory if OP never deleted /bin in the first place which is a possibility as he wrote the answer the same time as the question in all likelihood. Still very nice thought experiment and excellent writing style.

      – WinEunuuchs2Unix
      Apr 21 '17 at 22:12











    • I recommend to edit this answer to expand it with specific details about how to do this. (See also How do I write a good answer? for general advice about what sorts of answers are considered most valuable on AskUbuntu.)

      – David Foerster
      May 7 '17 at 14:36



















    • This is what I would do. The live DVD being the same version number will be almost the same if not exactly the same as current installed. If I had a disc or USB Live version I could compare them and post an answer like yours. This thread is more a theory if OP never deleted /bin in the first place which is a possibility as he wrote the answer the same time as the question in all likelihood. Still very nice thought experiment and excellent writing style.

      – WinEunuuchs2Unix
      Apr 21 '17 at 22:12











    • I recommend to edit this answer to expand it with specific details about how to do this. (See also How do I write a good answer? for general advice about what sorts of answers are considered most valuable on AskUbuntu.)

      – David Foerster
      May 7 '17 at 14:36

















    This is what I would do. The live DVD being the same version number will be almost the same if not exactly the same as current installed. If I had a disc or USB Live version I could compare them and post an answer like yours. This thread is more a theory if OP never deleted /bin in the first place which is a possibility as he wrote the answer the same time as the question in all likelihood. Still very nice thought experiment and excellent writing style.

    – WinEunuuchs2Unix
    Apr 21 '17 at 22:12





    This is what I would do. The live DVD being the same version number will be almost the same if not exactly the same as current installed. If I had a disc or USB Live version I could compare them and post an answer like yours. This thread is more a theory if OP never deleted /bin in the first place which is a possibility as he wrote the answer the same time as the question in all likelihood. Still very nice thought experiment and excellent writing style.

    – WinEunuuchs2Unix
    Apr 21 '17 at 22:12













    I recommend to edit this answer to expand it with specific details about how to do this. (See also How do I write a good answer? for general advice about what sorts of answers are considered most valuable on AskUbuntu.)

    – David Foerster
    May 7 '17 at 14:36





    I recommend to edit this answer to expand it with specific details about how to do this. (See also How do I write a good answer? for general advice about what sorts of answers are considered most valuable on AskUbuntu.)

    – David Foerster
    May 7 '17 at 14:36











    1














    Some additions to this excellent answer, after I encountered this issue (along with deleting /boot, /etc, /lib and /lib64):





    • chroot requires /lib and /lib64 to be present; otherwise you will get the following error:
      failed to run command ‘/bin/bash’: No such file or directory

      I copied these from the LiveCD OS and didn't have any problems restoring. YMMV depending on the packages you have installed on the system

    • I cannot edit the answer referenced above, but there is a typo:
      cp /etc/resolv.conf /mnt/etc/resolv.cof

      should be
      cp /etc/resolv.conf /mnt/etc/resolv.conf


    • /boot can easily be restored using grub tools. See here.

    • As this answer recommends, apt install --reinstall <package> is a great way to restore missing files in /bin, /lib and /lib64.


      • Some packages that required reinstallation: libaio1, mysql-server, openvpn, vsftpd




    Note to self:
    rm -rf folder /* is not the same as rm -rf folder/*






    share|improve this answer






























      1














      Some additions to this excellent answer, after I encountered this issue (along with deleting /boot, /etc, /lib and /lib64):





      • chroot requires /lib and /lib64 to be present; otherwise you will get the following error:
        failed to run command ‘/bin/bash’: No such file or directory

        I copied these from the LiveCD OS and didn't have any problems restoring. YMMV depending on the packages you have installed on the system

      • I cannot edit the answer referenced above, but there is a typo:
        cp /etc/resolv.conf /mnt/etc/resolv.cof

        should be
        cp /etc/resolv.conf /mnt/etc/resolv.conf


      • /boot can easily be restored using grub tools. See here.

      • As this answer recommends, apt install --reinstall <package> is a great way to restore missing files in /bin, /lib and /lib64.


        • Some packages that required reinstallation: libaio1, mysql-server, openvpn, vsftpd




      Note to self:
      rm -rf folder /* is not the same as rm -rf folder/*






      share|improve this answer




























        1












        1








        1







        Some additions to this excellent answer, after I encountered this issue (along with deleting /boot, /etc, /lib and /lib64):





        • chroot requires /lib and /lib64 to be present; otherwise you will get the following error:
          failed to run command ‘/bin/bash’: No such file or directory

          I copied these from the LiveCD OS and didn't have any problems restoring. YMMV depending on the packages you have installed on the system

        • I cannot edit the answer referenced above, but there is a typo:
          cp /etc/resolv.conf /mnt/etc/resolv.cof

          should be
          cp /etc/resolv.conf /mnt/etc/resolv.conf


        • /boot can easily be restored using grub tools. See here.

        • As this answer recommends, apt install --reinstall <package> is a great way to restore missing files in /bin, /lib and /lib64.


          • Some packages that required reinstallation: libaio1, mysql-server, openvpn, vsftpd




        Note to self:
        rm -rf folder /* is not the same as rm -rf folder/*






        share|improve this answer















        Some additions to this excellent answer, after I encountered this issue (along with deleting /boot, /etc, /lib and /lib64):





        • chroot requires /lib and /lib64 to be present; otherwise you will get the following error:
          failed to run command ‘/bin/bash’: No such file or directory

          I copied these from the LiveCD OS and didn't have any problems restoring. YMMV depending on the packages you have installed on the system

        • I cannot edit the answer referenced above, but there is a typo:
          cp /etc/resolv.conf /mnt/etc/resolv.cof

          should be
          cp /etc/resolv.conf /mnt/etc/resolv.conf


        • /boot can easily be restored using grub tools. See here.

        • As this answer recommends, apt install --reinstall <package> is a great way to restore missing files in /bin, /lib and /lib64.


          • Some packages that required reinstallation: libaio1, mysql-server, openvpn, vsftpd




        Note to self:
        rm -rf folder /* is not the same as rm -rf folder/*







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Jul 5 '18 at 14:36

























        answered Jul 5 '18 at 14:29









        mrtumnusmrtumnus

        515




        515

















            protected by Ravexina Sep 2 '18 at 13:39



            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?



            Popular posts from this blog

            How did Captain America manage to do this?

            迪纳利

            南乌拉尔铁路局