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



## Manikandana Arumugam (Nov 16, 2018)

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.


----------



## ShelLuser (Nov 16, 2018)

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.


----------



## Manikandana Arumugam (Nov 16, 2018)

I used "pkg upgrade -f"
is this possible to restore? or fix the problem in root user login?


----------



## ShelLuser (Nov 16, 2018)

Impossible to say without knowing more about this situation. Things like your FreeBSD version for example. What's the output of `freebsd-version -urk`?


----------



## phoenix (Nov 16, 2018)

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.


----------



## Manikandana Arumugam (Nov 17, 2018)

Hi,
My BSD Version is 11.0. Yes, i understand.
but unable to login by root user? is there any other way to fix this?


----------



## ShelLuser (Nov 17, 2018)

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.


----------



## Manikandana Arumugam (Nov 19, 2018)

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?


----------



## DavidMarec (Nov 19, 2018)

Manikandana Arumugam said:


> Hi ShelLuser ,
> Root Access users was not login via putty/ssh.



You do allow  root access via ssh ? 
If yes, try to open a ssh connection on top of  another shell

`ssh root@remote /bin/sh`
Be aware that you may not see any prompt.



> only low level users only can login but they have restricted permissions. Any other solution?



Is security/sudo installed and able to give root rights to one user ?


----------



## Manikandana Arumugam (Nov 20, 2018)

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.


----------



## olli@ (Nov 20, 2018)

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.


----------



## Bobi B. (Nov 20, 2018)

Manikandana Arumugam said:


> Hi DavidMarec ,
> I tried from low level user to another shell,
> 
> `$ ssh root@remote bin/sh
> ...


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`.


----------



## olli@ (Nov 21, 2018)

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`.


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.


----------



## jordanch (Nov 23, 2018)

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.


----------



## xtaz (Nov 23, 2018)

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.


----------



## olli@ (Nov 23, 2018)

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.


----------



## jordanch (Nov 26, 2018)

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.
> 
> ...



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


----------

