Shared object "libdl.so.1" not found, required by "bash"

M

Manikandana Arumugam

Hi
Yesterday, i was upgrade the package by below "pkg upgrade -f"
After that, loggedout from putty.

After few mints later, unable to login via putty. after successful login putty automatically closed. after checking from low permission user,below file was not found,

Shared object "libdl.so.1" not found, required by "bash"

any one please help me to fix this.
 
What FreeBSD version are you using? And what exact command did you use to upgrade the package?

For starters: don't use -f if you don't have to, you'll only risk breaking things.

My assumption is that you installed bash on an unsupported system, that would explain the missing dependency. The ports collection is fully tailored to be used on supported releases, and right now there's only one: 11.2.
 
Impossible to say without knowing more about this situation. Things like your FreeBSD version for example. What's the output of freebsd-version -urk?
 
Let me guess, you just did a binary upgrade to FreeBSD 11.2-RELEASE? If so, you probably didn't do the final freebsd-update install after rebooting.
 
Ok, so in another place I learned that you're using bash as the login shell for root. That's really not a good idea, and you just learned why that is so.

How to fix... Boot in single user mode (press 's' on the boot menu) and then the system will ask what shell to use, with the default being /bin/sh. Now you're logged on as root again. First you need to remount root read-write.

If you're using UFS: # mount -uw /.
On ZFS you'd use: # zfs set readonly=off zroot/DEFAULT/root.

Then fix your shell: # pw usermod root -s /bin/csh. Or use: # chsh.

But most of all consider upgrading to 11.2. Version 11.0 is no longer supported which means that some ports may no longer work after upgrading because they were build against FreeBSD 11.2 instead.
 
Hi ShelLuser ,
I tried chsh working fine. but unable to edit the file etc/passwd file.
Root Access users was not login via putty/ssh.
only low level users only can login but they have restricted permissions. Any other solution?
 
As has already been suggested: Reboot in single user mode. When asked for the shell, accept the default (/bin/sh). Then mount your file systems (mount -urw / && mount -at ufs) and fix your shell problem. Then boot normally (multi user).

Note that you should normally not login as root (via ssh or otherwise). That should be disabled. Login as normal user and use “su -m” (requires that you're in the wheel group) or “sudo” or “super” from ports (personally I prefer super because I don't trust sudo, but YMMV).
Also, do not change root's login shell. There is no reason to do that anyway, except maybe setting it to /usr/sbin/nologin.
 
Manikandana Arumugam said:
Hi DavidMarec ,
I tried from low level user to another shell,

$ ssh root@remote bin/sh
Password for root@bn-web01:
Shared object "libdl.so.1" not found, required by "bash"

showing above error message.
Click to expand...
You're not paying attention, your command lacks leading slash -- /bin/sh, not just bin/sh. Besides I believe -t is necessary, or a TTY will not be allocated. Try with ssh -t root@remote /bin/sh.
 
Bobi B. said:
You're not paying attention, your command lacks leading slash -- /bin/sh, not just bin/sh. Besides I believe -t is necessary, or a TTY will not be allocated. Try with ssh -t root@remote /bin/sh.
Click to expand...
Uhm … The problem is that the login shell doesn't work, because a library is missing. There is nothing he can type on the command line that could work around that. because the login shell is always executed first (otherwise, circumventing /usr/sbin/nologin would be trivial).

In other words: It doesn't matter if a slash is missing or if -t is specified or not. Since he is not in the wheel group so he cannot use su -m, he will have to boot single-user mode in order to fix the problem.
 
I wanted to chime in here since I had this exact problem very recently on a remote server running 11.1, on which the security settings were reasonably paranoid - no root login, key-only ssh, etc. I suddenly got kicked out of the server in the middle of a pkg update/upgrade. Then since the login shell, i.e. bash, was no longer functional, NOTHING worked.

So it wasn't possible to use a different shell or issue a command directly at ssh - since literally everything would have to go through the login shell. It wasn't even possible to scp something to the server to either add the missing file, or overwrite the sshd config file. Do note that had I been able to do any of the above, it might have been a security breach.

The underlying cause here is 1) a borked bash update on 11.1 2) using bash as the login shell, as ShelLuser already pointed out.

The only solution, for me, was to boot using a special "rescue mode" offered by the hosting company. Roughly, this meant booting off their network into a temporary unix-like shell with my server's hdd mounted as an external device. Copying the missing file from my local vm into the server's /usr/lib/ allowed me to login normally again.

Of course, after logging back in normally, the first step was to get rid of bash as the login shell, and revert to the default /bin/sh. Then upgrading to 11.2 fixed things.
 
Anything critical done remotely should probably be done inside sysutils/screen or sysutils/tmux where if the connection drops you can reattach where you left off. Much less dangerous then if you get kicked off.

Secondly using bash as a root shell isn't so bad as long as you completely understand the limitations. One reason is if /usr/local is on a different filesystem to / then you may find that it's not mounted in the case of any problems and thus can't be found. This isn't an issue if you have /usr/local on the / filesystem which quite a few people do. This also wouldn't be an issue with ZFS rather than UFS.

The other point is that by default bash uses shared libraries and if any of these are missing then you get the problems mentioned above. However there is a shells/bash-static port or a selectable option in shells/bash which will statically compile all the required libraries into a single binary. This will then work without fail.

I'm not saying everybody should do this. But I am saying it's not as dangerous as people make out as long as you understand the limitations and know what you are doing.
 
I have a habit to create a local “emergency user” when I install a system. It always gets /rescue/sh as login shell (which is statically linked, so it doesn't depend on shared libraries), it's a member of the wheel group (so it can use su -m to become root, even if root's shell is broken), and its home directory is on the root file system. That emergency user saved my ass a few times.
 
xtaz said:
Anything critical done remotely should probably be done inside sysutils/screen or sysutils/tmux where if the connection drops you can reattach where you left off. Much less dangerous then if you get kicked off.

Secondly using bash as a root shell isn't so bad as long as you completely understand the limitations. One reason is if /usr/local is on a different filesystem to / then you may find that it's not mounted in the case of any problems and thus can't be found. This isn't an issue if you have /usr/local on the / filesystem which quite a few people do. This also wouldn't be an issue with ZFS rather than UFS.

The other point is that by default bash uses shared libraries and if any of these are missing then you get the problems mentioned above. However there is a shells/bash-static port or a selectable option in shells/bash which will statically compile all the required libraries into a single binary. This will then work without fail.

I'm not saying everybody should do this. But I am saying it's not as dangerous as people make out as long as you understand the limitations and know what you are doing.
Click to expand...

Excellent point about tmux. But may I add that if one prefers bash (or another shell more advanced than sh), it is more practical to simply set it as default in the tmux conf. That way, the operating system retains its default (sh), and the user gets the benefit of bash for all practical purposes, since all practical work is done via tmux anyways. This is the setup I now have :)
 
You must log in or register to reply here.
Back
Top