upgrade problems..

[hardhead]

i just ran the upgrade from gentoo 1.3 to 1.4rc1 from the scripts on the front of gentoo's website. everything *seemed* to work fine, all the way through step 4 (even all the packages in step 4 built properly)...*but* when i rebooted the system won't boot. i'm getting the error message:

/bin/bash: error while loading shared libraries: libgcc_s.so.: cannot open shared object file: No such file or directory.

I get the error message right after the filesystems mount, then it says "freeing unused kernel memory" and "INIT: version 2.84 booting" then the error message...

I'm thinking maybe i didn't update a file correctly during the etc-update ? all the compiling seemed to work fine but i can't boot from any kernels that previously worked (all giving the same message)--i'm able to boot from a bootdisk and access all the files and the system though...

[dasbear]

I upgraded a system from 1.2 to 1.4rc1 using the same scripts.

I'm having the same problem. I can't reboot because of it. 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.