60

I accidentally renamed the directory /usr into /usr_bak.

I want to change it back, so I append the path /usr_bak/bin to $PATH to allow the system to find the command sudo.

But now sudo mv /usr_bak /usr gives me the error:

sudo: error while loading shared libraries: libsudo_util.so.0: cannot open shared object file: No such file or directory

Is there a way to rename the /usr_bak as /usr besides reinstalling the system?

  • 2
    Which OS is this? I wonder how sudo even got to library stage, it's usually in /usr/bin/ and should have failed with a command-not-found error. Also, do you have a root password set? – muru Mar 19 '18 at 3:24
  • 3
    @muru It's Ubuntu. You are right, I did get the error about not found before so I appended the new path /usr_bak/bin to $PATH and now I get the error in my post here... – Yves Mar 19 '18 at 3:27
  • 2
    @user1717828 it's complicated. I have to compile a project, developed on Ubuntu 16.04, on Ubuntu 17.10. So I'm thinking if I can simply copy the /usr of Ubuntu 16.04 to overwrite the /usr of Ubuntu 17.10... – Yves Mar 19 '18 at 17:55
  • 6
    Have you considered using a VM to compile the project instead of such drastic changes? – Kevin Mar 19 '18 at 23:50
  • 3
    You can run virtualbox in headless mode. It may be easiest to set up a guest on another machine, or get a pre-configured one. – Kevin Mar 20 '18 at 1:47
107

Since you have set a password for root, use su and busybox, installed by default in Ubuntu. All of su's required libraries are in /lib. Busybox is a collection of utilities that's statically linked, so missing libraries shouldn't be a problem. Do:

su -c '/bin/busybox mv /usr_bak /usr'

(While Busybox itself also has a su applet, the /bin/busybox binary is not setuid and so doesn't work unless ran as root.)

If you don't have a root password, you could probably use Gilles' solution here using LD_LIBRARY_PATH, or(Gilles says this won't work with setuid binaries like sudo) reboot and edit the GRUB menu to boot with init=/bin/busybox as a kernel parameter and move the folder back.

  • 71
    Now, don't accidentally rename /lib. – sleblanc Mar 19 '18 at 12:40
  • 2
    @sleblanc lol... Seriously, what if I accidentally rename /lib? Can I use the same method to repair it? – Yves Mar 19 '18 at 18:00
  • 2
    If your /lib is a symlink to /usr/lib, it get's more interesting :) LD_LIBRARY_PATH & PATH to save the day. [or busybox should still work too] – Mark K Cowan Mar 19 '18 at 20:14
  • 5
    LD_LIBRARY_PATH wouldn't help to run sudo since sudo is setuid. If its libraries aren't in the right place, sudo won't work until root repairs it. – Gilles Mar 19 '18 at 21:43
  • 8
    @Yves if you renamed /lib, then you'd probably have to reboot to init=/bin/busybox – muru Mar 19 '18 at 23:54
31

In addition to muru's answer:

  • you could have used some rescue boot USB key to repair your system; e.g. if your system is some Debian or Ubuntu, boot the installation USB key in rescue mode, and do the appropriate mount and mv and umount.

  • to be able to repair more easily such mistakes, I generally also install a static shell with several builtin commands (notably with some cp, rm, mv-like builtins) such as sash (it is packaged in Debian & Ubuntu, and also available as sash-3.8.tar.gz in source form) and boot with init=/bin/sash passed to Grub.

PS: sash is slightly buggy, and not entirely Posix compliant, but still very useful.

  • Could you please explain how to install a static shell with several builtin commands? Is there some manual? – Yves Mar 19 '18 at 17:59
  • 1
    On Debian or Ubuntu: apt-get install sash. But you could also download sash-3.8.tar.gz and compile it. – Basile Starynkevitch Mar 19 '18 at 18:00
  • I keep a liveiso on the hdd with a custom grub entry for problems like this. No need to get complicated, just boot a live os and manipulate files freely :) – FreeSoftwareServers Mar 22 '18 at 8:44
2

I think the best safest way is to reboot using a USB, CD or DVD booted OS (Debian, Ubuntu, Suse, etc). Then mount the drive containing the problems and do the rename.

Safer than booting into a minefield with /usr or /lib effectively missing.

  • 1
    You can boot an ISO directly from Grub/HDD no need for USB/DVD etc. Pretty nifty trick grub has call loopback. – FreeSoftwareServers Mar 22 '18 at 8:47
0

I ran into a similar problem where I renamed /usr/bin to /usr/bin_bkp for some test and then I wasn't able to rename (as the command didn't find the sudo in the standard directory which is /usr/bin) and then I went to the /usr/bin_bkp directory manually (using File manager) and most of the functions (including the rename) on the right click are disabled.

Then I tried the following command and it fixed the issue

$/usr/bin_bkp/sudo mv /usr/bin_bkp/ /usr/bin/

I invoked the sudo from the current path and it worked, now everything's back to normal.

OS: Xubuntu 14.04

-3

I can't try this right now (and am not sure I'd want to), but it seems like it ought to work to create yourself a new "/usr" as a hard link (not a soft link) to your "/usr_bak, then delete the "/usr_bak"

ln /usr_bak /usr
rm /usr_bak

The hard link created by "ln" (with no "-s" argument) in the file system should make both the usr and usr_bak directories equally valid links to the directories in question. "rm" just removes the one link you asked it to remove, not both of them. Since there's still a valid link to the contents, they should remain accessible through the remaining link at "/usr".

  • I suppose if the "rm" scares you, you could just skip it and leave the "/usr_bak" link there too. Its the "ln" command that gets you your "/usr" directory link back. – T.E.D. Mar 20 '18 at 20:11
  • 4
    I was under the impression that Linux (or at least Ubuntu) does not allow hard links to directories. E.g., askubuntu.com/questions/210741/… – Chris Bouchard Mar 20 '18 at 21:03
  • 3
    @Chris: Right, Linux does not allow directory hardlinks (other than . and .., so the link count on a directory tells you the number of first-level subdirs). Also, rm doesn't work on directories, you'd have to use rmdir. (ln and rm work on symlinks to directories, but we're talking about an actual directory). Also, this doesn't solve the problem, because it requires root just like mv, because of the permissions on /. If you could run this, you could run mv instead like a normal person. – Peter Cordes Mar 20 '18 at 22:59
  • 2
    Hardlinks to directories are not supported on most (all?) Unices because it's too difficult for software doing a recursive file system crawl to detect infinite loops. It's possible if the software keeps track of all inodes visited and it's crawling an inode aware filesystem (i.e. not FAT32/NTFS), but checking for symbolic links and not traversing them is much easier. All that's needed is a quick call to lstat(2) to check file type. – penguin359 Mar 21 '18 at 5:29
  • 1
    @Pryftan, my ln(1) on Debian says this for the the -d/-F/--directory option: "allow the superuser to attempt to hard link directories (note: will probably fail due to system restrictions, even for the superuser)". So you're free to try, but your filesystem probably won't let you. – Toby Speight Mar 21 '18 at 10:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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