Description of problem: Veritas Netbackup 4.5 is broken by upgrading from RHAS2.1 to RHAS3.0. The binaries when run report: Incorrectly built binary which accesses errno or h_errno directly. Needs to be fixed. This is presumably similar to bug 90002 for RH9. Also another problem (probably requiring another bug) is that RHAS3 does not provide libXm.so.2 and a symbolic link to 3.0.1 does not work (at least not with netbackup's xbp). This can be resolved by installing the version of openmotif shipped with 2.1 rather than the one shipped with 3.0 but this isn't ideal. I appreciate that there is no obligation for Red Hat to support Veritas products, but this is a total show-stopper as the tape library on the machine is now a paper weight. I can't believe other people are not facing this issue and it's a month or more before Netbackup 5.0 is released. Version-Release number of selected component (if applicable): glibc-2.3.2-95.3 or glibc-2.3.2-95.5 which I installed from ftp://people.redhat.com/jakub/glibc/errata/2.3.2-95.5 How reproducible: Always Steps to Reproduce: 1. Just try to run the binaries. 2. 3. Actual results: Incorrectly built binary which accesses errno or h_errno directly. Needs to be fixed. Expected results: Additional info:
That means there is a bug in Veritas software, which means you should talk to them so that they get it fixed. In the mean time you can work around it, citing from Taroon RELEASE-NOTES: " Note that software using errno, h_errno, and _res must #include the appropriate header file (errno.h, netdb.h, and resolv.h respectively) before they are used. However, LD_ASSUME_KERNEL=2.4.19 can be used as a workaround until the software can be fixed." As for the second question, have you installed openmotif21 package?
Yep. openmotif-2.1.30-11 I also have this problem with java now :( Error occurred during initialization of VM Unable to load native library: /usr/openv/java/jre/lib/i386/libjava.so: symbol __libc_wait, version GLIBC_2.0 not defined in file libc.so.6 with link time reference As far as I can make out specifying LD_PRELOAD=/lib/libc.so.6 (or any such change of LD_LIBRARY_PATH) does not fix this. However, I think I shall resolve this by reverting to my backup of 2.1 until a supported product comes out.
That's certainly not what is included in Taroon, which should have: ls openmotif*.i386.rpm openmotif21-2.1.30-8.i386.rpm openmotif-2.2.2-16.i386.rpm openmotif-devel-2.2.2-16.i386.rpm openmotif21-2.1.30-8 includes libXm.so.2, while openmotif-2.2.2-16 includes libXm.so.3 As for Java, you surely aren't using the JDK included in the distribution. Older JDKs are very buggy and this is just one of the symptoms. You can work around it, e.g. with: gcc -O2 -shared -o ~/libcwait.so -fpic -xc - <<EOF #include <errno.h> #include <sys/syscall.h> #include <sys/types.h> #include <sys/wait.h> pid_t __libc_wait (int *status) { int res; asm volatile ("pushl %%ebx\n\t" "movl %2, %%ebx\n\t" "movl %1, %%eax\n\t" "int \$0x80\n\t" "popl %%ebx" : "=a" (res) : "i" (__NR_wait4), "0" (WAIT_ANY), "c" (status), "d" (0), "S" (0)); return res; } EOF and using LD_ASSUME_KERNEL=2.4.19 LD_PRELOAD=~/libcwait.so when you need to load the buggy JDK. Or better just use the JDK which is included in the distro.
How is it that Red Hat has no obligation to fix this problem??? One of the major features advertised by RH is that RHEL is a "Key Certification Platform": Red Hat actively works to certify leading industry ISVs and OEMs for comprehensive application and hardware support for Red Hat Enterprise Linux products. Here are just some of the vendors supporting Red Hat Enterprise Linux: blah blah VERITAS
I'm having the problem with Java as well. It is not a java bug, it is a libc bug. Works well on WS2.x It is obviously the compat librairies that are broken.
The code snippet above did fix the problem I posted but there were still others... After many, many hours of trying to get this to work I gave up, took my tape of AS2.1 and downgraded the machine. I am hoping that Veritas Netbackup 5.0 will be certified to run on AS3.0 because otherwise it's not really an option to upgrade. The disappointing thing about this is not that the problem can't be fixed in-situ but the fact that no one thought to find out whether Netbackup 4.5 worked (or would be supported by Veritas) on AS 3 before it was released. This is not some minor inconveniance. Anyone who has even quite mediocre storage requirements is going to need tape autoloaders unless they want to spend all day feeding tapes into single drives. Releasing an OS without a supported product from arguably /the/ major vendor of software that can do this job and without native tools in the OS is not what I would describe as 'comprehensive application support'.
Thanks for the heads up. Actually, the JDKs from Sun, 1.3.1_10 and 1.4.2_03 both work on WS3.0 and are compatible with most jave apps. The IBM JDK that is bundled with WS3.0 seems buggy. So switching the Sun JDK solved that problem. But I agree, a lot of other software, written in C is still failing so WS2.1 is still the way to go in those cases. Thanks again, Balazs
Use LD_ASSUME_KERNEL=2.2.5 instead, it solved the issue for me. The software was Veritas Nebackup 4.5 FP3. OS: Fedora Core 2 I made a bpjava-wrapper script: #!/bin/sh export LD_ASSUME_KERNEL=2.2.5 ${0}_org $* And I did the following: mv bpjava-msvc bpjava-msvc_org ln -s bpjava-wrapper bpjava-msvc Do the same with all files starting with "bp" in /usr/openv/netbackup/bin. Regards, Martin
Correct, but a simplest way is to add env = LD_ASSUME_KERNEL=2.2.5 in the bpcd vnetd bpjava-msvc and vopied files in /etc/xinetd.d Regards, Cedric.