Trouble with bash

Hi! I'm trying to connect to a remote host through SSH and getting such an error:
Code:
/libexec/ld-elf.so.1: Shared object "libintl.so.9" not found, required by "bash"

Tried to see dependencies:
Code:
ldd /usr/local/bin/bash
/usr/local/bin/bash:
        libncurses.so.8 => /lib/libncurses.so.8 (0x8006e3000)
        libintl.so.9 => not found (0x0)
        libiconv.so.3 => not found (0x0)
        libc.so.7 => /lib/libc.so.7 (0x80082f000)[/cmd]

[cmd]locate libintl.so.9
/backup/usr/local/lib/libintl.so.9
/usr/local/lib/libintl.so.9
locate libiconv.so.3
/backup/usr/local/lib/libiconv.so.3
/usr/local/ispmgr/lib/external/libiconv.so.3
/usr/local/lib/libiconv.so.3

What do I need to do? I can't connect as root - default shell is /bin/bash.
Just have ispmanager.
 
And that's why you should never change root's shell.

You will need to arrange console access, your issue can only be resolved in single user mode.
 
rado said:
What I need to do? I can't connect as root - default shell is /bin/bash.
Just have ispmanager.

My bash is located under /usr/local/bin, so I suppose your shell information in /etc/passwd might be wrong. Or is it just a typo?

I am using bash as login shell for root as well, but I never login as root over SSH. I have never had any issues with this. / and /usr/local are residing on the same partition on my machine. To be honest @SirDice's comment is not helpful for me without further information. Maybe it would be safer to use a static version of bash but I am currently using a dynamically linked one just like you do.

Regards,
Peter
 
Last edited by a moderator:
pvoigt said:
I am using bash as login shell for root as well, but I never login as root over SSH. I have never had any issues with this. / and /usr/local are residing on the same partition on my machine. To be honest SirDice's comment is not helpful for me without further information. Maybe it would be safer to use a static version of bash but I am currently using a dynamically linked one just like you do.
You're going to get the same issues as @rado next time you do a major upgrade.
 
Last edited by a moderator:
If you compile bash with
Code:
STATIC=on
it's going to be fine, although if /usr/local is in another slice, one has to copy /usr/local/bin to /bin. The same goes for shells/zsh.
 
SirDice said:
pvoigt said:
I am using bash as login shell for root as well, but I never login as root over SSH. I have never had any issues with this. / and /usr/local are residing on the same partition on my machine. To be honest SirDice's comment is not helpful for me without further information. Maybe it would be safer to use a static version of bash but I am currently using a dynamically linked one just like you do.
You're going to get the same issues as @rado next time you do a major upgrade.

I am going to believe you but could you please give me some more hints on this? I can currently only guess about the real problems with changing the default login shell away from /bin/csh? And if you are not going to write down your arguments, could you please give me a few links where I could get some more details on this. I am supposing that the "problem" arises for any account that is not using a static linked shell on the root file system. Is this right?

Regards,
Peter
 
Last edited by a moderator:
The problem is that bash is linked to certain libraries. When you do a major upgrade those libraries are usually upgraded too. You then get the problem of bash not being able to run because it can't find some of the libraries it needs (they've been replaced with newer versions). This is the reason why you need to reinstall/rebuilt all ports or packages after a major upgrade.

You can solve the issue by rebuilding shells/bash but because you can't login you can't rebuilt the port. Chicken-egg problem.
 
SirDice said:
The problem is that bash is linked to certain libraries. When you do a major upgrade those libraries are usually upgraded too. You then get the problem of bash not being able to run because it can't find some of the libraries it needs (they've been replaced with newer versions). This is the reason why you need to reinstall/rebuilt all ports or packages after a major upgrade.

You can solve the issue by rebuilding shells/bash but because you can't login you can't rebuilt the port. Chicken-egg problem.

But shouldn't it be sufficient to switch back to default login shell right before doing a major upgrade? Or are there other situations where on could run into problems?

By the way: Where can you conclude from that the thread starter did a major upgrade except it is the only known situation where you can run into such trouble :) ?

Regards,
Peter
 
pvoigt said:
But shouldn't it be sufficient to switch back to default login shell right before doing a major upgrade? Or are there other situations where on could run into problems?
That would be one way to prevent it. Also keep an eye on tools like security/sudo. It can fail after a major upgrade too.

By the way: Where can you conclude from that the thread starter did a major upgrade except it is the only known situation where you can run into such trouble :) ?
It's an extremely common error with new users.
 
Indeed. And not only with new. I'm with FreeBSD since 8.4 and was caught in the sudo trap yesterday: sudo died, remote root is blocked, my user not in wheel. §e
 
Well, have learned a lot. Thanks to all who contributed to this thread. I love those kind of discussions.

So I hope I will not run into trouble right before the next major upgrade :) .

Regards,
Peter
 
rado said:
So what I need to do except changing root shell to /bin/csh?
If you can login again you need to rebuild or reinstall all ports or packages.
 
Back
Top