bash linked erroneously to libraries in /usr

[dasbear]

I upgraded a system from 1.2 to 1.4rc1 using the scripts from the how to on the front page..

The probelm I'm having is that on boot up bash can't run because it can't find libgcc_s.so.1

I can't reboot because of this problem. I can bring my system up on "life support" by booting the install cd and putting together a suitable chroot enviornment. The system in question is my mail and web server and has several remote CVS users.

I'm not blaming Gentoo. I should not have done such a radical upgrade on a system that was stable and had no problems. But I'm going to have to leave the system on "life support" until the problem gets fixed.

The problem I see is this: bash is linked to a library that is not in the root filesystem, but is in the usr filesystem. This is a major problem for me, as I never have /usr in the root filesystem, I always have it seperate.

ldd $(which bash)
libncurses.so.5 => /lib/libncurses.so.5 (0x2aac4000)
libdl.so.2 => /lib/libdl.so.2 (0x2ab08000)
libc.so.6 => /lib/libc.so.6 (0x2ab0b000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x2ac26000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2aaab000)

Ok, the /usr/lib/libgcc_s.so.1 is not completely correct. That is due to a symlink I made when trying to fix the problem before I found the real source of the problem.

The symlink is as follows:

/usr/lib/libgcc_s.so.1 -> /usr/lib/gcc-lib/i586-pc-linux-gnu/3.2/libgcc_s.so.1

The symlink did not fix the problem, it was an attempt at a workaround.

From what I understood about traditional unix, everthing in /bin and /sbin should only be dynamically linked to libraries in /lib, and never require anything in /usr. It is this way in order to bring up a system in single user mode and be able to repair filesystems such as /var, /tmp, /home, and /usr which are not part of the / filesystem, but mounted under it.

(BTW, I replied with this post to one made by hardhead. My post showed up twice, as two replies, so I deleted the second erroneous reply. After that the entire thread was gone.)

[hardhead]

i am not able to work on my computer right now (it might be a couple days due to schoolwork)...but do you think recompilling bash after getting into the chrooted system would fix the problem? once i try this i will reply with my results, but i thought i would throw the idea out... (still would like to understand why exactly this problem is occuring?)

[elzbal]

You are correct in that the contents of /bin and /sbin should never be linked to things in /usr/... (By my preference, they should be statically compiled, and not linked to *anything*.)

I hope they get this fixed before release, or at least give us clear instructions to avoid this trap!

[rac]

[dasbear]

I was able to come up with the following workaround:

I copied
/usr/lib/libz.so.1
/usr/lib/gcc-lib/i586-pc-linux-gnu/3.2/libgcc_s.so.1
/usr/lib/libcrack.so.2

all into /lib
libz.so.1
libgcc_s.so.1
libcrack.so.2

I removed the sym-links I had made before that were an attempt to fix the problem, re-ran env-update, shut down all daemons, unmounted all filesystems, and rebooted.

After copying those libraries into /lib the system was able to boot successfully.