cancel
Showing results for 
Search instead for 
Did you mean: 

Solaris patching issue

former_member84399
Participant
0 Kudos

Hello all,

We are running Solaris 10.

AS part of the Oracle upgrade from 10.2.0.4 to 11.2.0.1, we had to upgrade some OS patches, one of which was 119963-10

My Unix admin upgraded this to version 119963-20. A few days later, and while all was working ok until then, we realised

that a backup failed. Searching deeper, we found out that executables like sapxpg, tp etc were failing with messages

relating to libC.so

and so did showrev -p

showrev -p | grep 119963

ld.so.1: showrev: fatal: ./libC.so.5: unknown file type

sapxpg

ld.so.1: sapxpg: fatal: /usr/lib/64/libCrun.so.1: unknown file type

tp -v

ld.so.1: tp: fatal: /usr/lib/64/libCrun.so.1: unknown file type

My Unix admin backed out the patch (back to 10) and he was able to run showrev -p and commands like sapxpg, tp-v etc.

He then installed 119963-21 and again, things ran fine for a few days, until we hit the same issue

root@bwpda001 # showrev -p | grep 119963

ld.so.1: showrev: fatal: ./libC.so.5: unknown file type

Here is the output of ldd tp as well

bwpda001:bwpadm 3% ldd tp

libdl.so.1 => /lib/64/libdl.so.1

libnsl.so.1 => /lib/64/libnsl.so.1

libsocket.so.1 => /lib/64/libsocket.so.1

libCstd.so.1 => /usr/lib/64/libCstd.so.1

libCrun.so.1 => /usr/lib/64/libCrun.so.1

libCrun.so.1 (SUNW_1.1) => (version not found)

libm.so.1 => /lib/64/libm.so.1

libthread.so.1 => /lib/64/libthread.so.1

libw.so.1 => /lib/64/libw.so.1

libc.so.1 => /lib/64/libc.so.1

libmp.so.2 => /lib/64/libmp.so.2

libmd.so.1 => /lib/64/libmd.so.1

libscf.so.1 => /lib/64/libscf.so.1

libCrun.so.1 (SUNW_1.4) => (version not found)

libdoor.so.1 => /lib/64/libdoor.so.1

libuutil.so.1 => /lib/64/libuutil.so.1

libgen.so.1 => /lib/64/libgen.so.1

libm.so.2 => /lib/64/libm.so.2

/platform/SUNW,SPARC-Enterprise-T2000/lib/sparcv9/libc_psr.so.1

/platform/SUNW,SPARC-Enterprise-T2000/lib/sparcv9/libmd_psr.so.1

Any ideas what might be causing this?

Regards

Andreas

Accepted Solutions (1)

Accepted Solutions (1)

nelis
Active Contributor
0 Kudos

ld.so.1: tp: fatal: /usr/lib/64/libCrun.so.1: unknown file type

You'd probably be better off asking these sort of questions on a Sun/Solaris forum.

Anyway, what is the output of 'file /usr/lib/64/libCrun.so.1' ? Also, what is the size of the file so that someone here can make a comparison ? My guess is it is corrupted.

Nelis

former_member84399
Participant
0 Kudos

We updated the patch again to 119963-20 and it worked for a bit less that 16 hours, this time it fails with another library:

bwpda001:bwpadm 2% tp -v

ld.so.1: tp: fatal: /usr/lib/64/libCstd.so.1: unknown file type

Killed

bwpda001:bwpadm 7% ldd /usr/lib/64/libCstd.so.1

ldd: /usr/lib/64/libCstd.so.1: unsupported or unknown file type

bwpda001:bwpadm 8% file /usr/lib/64/libCstd.so.1

/usr/lib/64/libCstd.so.1: data

bwpda001:bwpadm 9%

The file is located under /usr/lib/64 which is a link to /usr/lib/sparcv9

It is strange that the file size is the same with before , please see below ls -l from the location of the library and from the location that has been copied from

root@bwpda001 # ls -l /usr/lib/sparcv9/libCstd.so.1

-rwxr-xr-x 1 root bin 3773400 Jan 20 2010 /usr/lib/sparcv9/libCstd.so.1

root@bwpda001 # ls -l /export/home/admin/FTP_Temp/119963-20/SUNWlibC/reloc/usr/lib/sparcv9/libCstd.so.1

-rwxr-xr-x 1 root root 3773400 Jan 20 2010 /export/home/admin/FTP_Temp/119963-20/SUNWlibC/reloc/usr/lib/sparcv9/libCstd.so.1

However, when I do file /usr/lib/64/libCstd.so.1, I get the output

/usr/lib/64/libCstd.so.1: data

while when I do file /export/home/admin/FTP_Temp/119963-20/SUNWlibC/reloc/usr/lib/sparcv9/libCstd.so.1

I get the output :

file /export/home/admin/FTP_Temp/119963-20/SUNWlibC/reloc/usr/lib/sparcv9/libCstd.so.1

/export/home/admin/FTP_Temp/119963-20/SUNWlibC/reloc/usr/lib/sparcv9/libCstd.so.1: ELF 64-bit MSB dynamic lib SPARCV9 Version 1, dynamically linked, not stripped, no debugging information available

Any suggestions please

many thanks

Andreas

Answers (1)

Answers (1)

former_member84399
Participant
0 Kudos

Update:

I noticed that while the file size remains the same, the result of the sum command for the file has changed

I copied the file again from its original location and it now appears to have the correct sum

root@bwpda001 # sum /usr/lib/sparcv9/libCstd.so.1

40372 7370 /usr/lib/sparcv9/libCstd.so.1

tp and the rest of the sap programs work now. I therefore believe that something is changing the sum of that file and corrupts it or at least makes it unusable for SAP executables? Any suggestions?

The file has 755 permissions and it is owned by root:bin. Its size is not changed (3773400).

Andreas

markus_doehr2
Active Contributor
0 Kudos

libCstd is part of the compiler runtime library, I suggest you contact Sun whether this patch is probably corrupt.

Markus