Moved bin and other folders! How to get them back?
If you still have a root shell, you may have a chance to repair your system. Let's say that you moved all the common directories (/bin, /etc, /lib, /sbin, /usr — these are the ones that could make recovery difficult) under /oops.
You won't be able to issue the mv command directly, even if you specify the full path /oops/bin/mv. That's because mv is dynamically linked; because you've moved the /lib directory, mv can't run because it can't find the libraries that constitute part of its code. In fact, it's even worse than that: mv can't find the dynamic loader /lib/ld-linux.so.2 (the name may vary depending on your architecture and unix variant, and the directory could be a different name such as /lib32 or /lib64). Therefore, until you've moved the /lib directory back, you need to invoke the linker explicitly, and you need to specify the path to the moved libraries. Here's the command tested on Debian squeeze i386.
export LD_LIBRARY_PATH=/oops/lib:/oops/lib/i386-linux-gnu
/oops/lib/ld-linux.so.2 /oops/bin/mv /oops/* /
You may need to adjust this a little for other distributions or architectures. For example, for CentOS on x86_64:
export LD_LIBRARY_PATH=/oops/lib:/oops/lib64
/oops/lib64/ld-linux-x86-64.so.2 /oops/bin/mv /oops/* /
When you've screwed up something /lib, it helps to have a statically linked toolbox lying around. Some distributions (I don't know about CentOS) provide a statically-linked copy of Busybox. There's also sash, a standalone shell with many commands built-in. If you have one of these, you can do your recovery from there. If you haven't installed them before the fact, it's too late.
# mkdir /oops
# mv /lib /bin /oops
# sash
Stand-alone shell (version 3.7)
> -mv /oops/* /
> exit
If you don't have a root shell anymore, but you still have an SSH daemon listening and you can log in directly as root over ssh, and you have one of these statically-linked toolboxes, you might be able to ssh in. This can work if you've moved /lib and /bin, but not /etc.
ssh [email protected] /oops/bin/sash
[email protected]'s password:
Stand-alone shell (version 3.7)
> -mv /oops/* /
Some administrators set up an alternate account with a statically-linked shell, or make the root account use a statically-linked shell, just for this kind of trouble.
If you don't have a root shell and haven't taken precautions, you'll need to boot from a Linux live CD/USB (any will do as long as it's recent enough to be able to access your disks and filesystems) and move the files back.
You can probably recover without rebooting, so don't reboot until you've tried some other things because it will not boot up. If you still have your SSH session open try these:
Where programs get run from is set using the $PATH variable. You can add your new bin location to path by running
export PATH="$PATH:/newpath/to/bin:/newpath/to/usr/bin". You may need to add the corresponding sbin directories as well. You can also run programs manually via their full path/path/to/mv [from] [to]for example should work even if mv is in a diffeent location. The tricky part is that most commands are going to want to access common libraries and you say/libgot moved so you need to set a variable for where that is too.export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/newpath/to/lib/:/newpath/to/usr/libOnce you can execute some basic commands, move the stuff back!
mv /path/to/subfolder/* /would be in order! Once everything is back in place the system should behave normally.
If that fails, booting up ANY LiveCD and mounting the drive should allow you to move the folders back where they belong. You don't need to re-install or even use your distros livecd, you just need to mount the drive and move the folders back to the right location on the disk. Lots of linux based rescue disk specialize in giving you just a few basic console tools to do this kind of repair.
You should be able to reboot the computer with an installation CD in single user mode, mount the root filesystem and move the files back on Linux. I do not know much centos, but it is like RHEL, so this should work.