Hi !

A patch I tried to install on Fedora (Core 1) erased the /etc/libcwait.so file.
Since then I can't run no binaries any more - at all. Rebooting results into kernel panic. Nice !

I corrected the error in the patch - gcc was not reachable - using the "linux rescue" feature of the boot cdrom. Problem is now that I can't have it recompiled because it looks for libraries into the /usr/lib directory. Which are not there in linux rescue because it is mounted as /mnt/sysimage/usr/lib. ld always comes up that it doesn't find "/usr/lib/libc_nonshared.a". Adding the /mnt/sysimage/usr/lib directory to the LD_LIBRARY_PATH variable has the same result.

Trying with chroot /mnt/sysimage doesn't work either ... because /etc/libcwait.so is missing !

So, before reinstalling Fedora completely for this one single missing file, I'm trying to find a copy of this file to put it there during rescue mode and reboot with it.

Is there somebody here who can help me with or recompiling this file or finding a copy somewhere ? Any clue and help is more then welcome ! Thanks !

Kind Regards,

Jan.

Something is ODD here, I've googled for a half hour now, and everything I've read....including this post @ LQ.............
http://www.linuxquestions.org/questi...336#post656336

says that the file your missing is located in /lib or /usr/lib..............

I finally made it work. In fact there was a file "ld.library.so" - or something like that - that was referencing to libcwait.so. Removing this file solved the problem.

So simple it was ...

Hi,

I am also having the same problem - a patch I installed led to kernel panic and I cannot load any libraries.
I get "error while loading shared libraries : /etc/libcwait.so : cannot open shared object file..."

Where can I find the ld.library.so file?

And one more question, why is this error happening? Is the patch linking some files wrongly?

Regards,
Rammya

Hi all,

I know that it's a bit too late but I reply to this post for thos who stuck again.

I have encoutered the same problem in a RHES 3 with Oracle 9i. After an electrical break down, I can't have this box boot again. It was complaining about a </usr/lib/libcwait.so>.
So I boot with "linux rescue", chroot /mnt/sysimage and I find that this library was corrupt. Instead of 4431 octets, it was 4438.
I pick up a new one in another box and reboot and it's work fine now.

Cheers

hello all,

I had the same issue last week (kernel panick! libcwait.so file missing or something like that!) on RHES V3. If I understood the early warning sign ("relocation error: GLIBC_2.0 not defined......." error when trying to use the Oracle report engine "runrep" command) after restoring production data on a test server, the issue would have been resolved a lot quicker - using scenario 1 below.

In my case, the program i was trying to execute "runrep" called /etc/ld.so.preload using glibc(see more about the ld.so files here). ld.so.preload in turn pointed to /etc/libcwait.so. The libcwait.so file was missing hence the issue.

It can be fundamentally resolved within the scope of two scenarios.

1. Scenario one - if detected before a shutdown/reboot (i.e with the relocation error) then recompile another libcwait.so file (instructions here) OR copy the libcwait.so file from another server (assumption is that there is a replicated environment) and paste in /etc/.

2. Scenario two - if in the event you reboot and have the "kernel panick" issue (which I had) then reboot in rescue mode (using the RH cd). Most likely, if you try 'chroot /mnt/sysimage', it would not work as the libcwait.so file is not in /mnt/sysimage/etc/ directory. Get the libcwait.so file from another node (or recompile as indicated in scenario 1) and drop in /mnt/sysimage/ which is actually the root directory of the OS (if it were not in rescue mode). Then edit the pointer in /mnt/sysimage/ld.so.preload from /etc/libcwait.so to /mnt/sysimage/libcwait.so. Now do 'chroot /mnt/sysimage' IT SHOULD WORK if the issue is with the link in the ld.so.preload file. Now place the libcwait.so in /etc/ and reboot. VOILA!!!

Cheers.

Olayemi