------=_Part_1_6904426.1140216055338
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Hello All,
My apologies if this has been dealt with before; I am new to the list. I
could not find any references to a solution via google though.
For various reasons we cannot upgrade beyond Netbackup 4.5 MP6 at the
moment. Unfortunately, this leaves us with the error 174 issue when backin=
g
up an RHEL-3 Update 6 client. Veritas does not support backing up this OS
with any version prior to Netbackup 4.5 FP6, presumably for this reason.
The error comes from a change in glibc on RHEL that produces a runtime
error. This error interferes with the backup. In your job error log you
will see the following coming from bpbkar on the client:
bpbrm from client redhat-00: Incorrectly built binary which accesses errno
or h_errno directly. Needs to be fixed.
I have found two resolutions. Recompile one's binary against the latest
glibc package or set LD_ASSUME_KERNEL to 2.4.1 in the environment in which
one's program runs. The latter is the only viable option, since we lack
access to the Netbackup sources. So, I made two changes to the
default Netbackup client installation.
In /etc/xinetd.d I added:
env =3D LD_ASSUME_KERNEL=3D2.4.1
to the all of the backup client daemon files.
and I wrapped bpbkar in a shell script:
1) mv /usr/openv/netbackup/bin/bpbkar /usr/openv/netbackup/bin/bpbkar.real
2) cat > /usr/openv/netbackup/bin/bpbkar
#!/bin/sh
export LD_ASSUME_KERNEL=3D2.4.1
/usr/openv/netbackup/bin/bpbkar.real $*
3) chmod 555 /usr/openv/netbackup/bin/bpbkar
In preliminary testing this solution produced exit status 0 from the client
backup. I was able to restore the backed up data to the client as well.
This does, however put the RHEL3 clients in unsupported territory. But,
they were unsupported to begin with.
If the machine is mission critical you should probably make sure the risk o=
f
being unsupported by Veritas is acceptable with the powers that be.
--
-Adam
------=_Part_1_6904426.1140216055338
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
<div>Hello All,</div>
<div> </div>
<div>My apologies if this has been dealt with before; I am new to the list.=
I could not find any references to a solution via google though=
.</div>
<div> </div>
<div>For various reasons we cannot upgrade beyond Netbackup 4.5 MP6 at the =
moment. Unfortunately, this leaves us with the error 174 issue when b=
acking up an RHEL-3 Update 6 client. Veritas does not support backing=
up this OS with any version prior to Netbackup=20
4.5 FP6, presumably for this reason. The error comes from a change in=
glibc on RHEL that produces a runtime error. This error interferes w=
ith the backup. In your job error log you will see the following comi=
ng from bpbkar on the client:
</div>
<div> </div>
<div>bpbrm from client redhat-00: Incorrectly built binary which accesses e=
rrno or h_errno directly. Needs to be fixed.</div>
<div> </div>
<div>I have found two resolutions. Recompile one's binary against the=
latest glibc package or set LD_ASSUME_KERNEL to 2.4.1 in the environment i=
n which one's program runs. The latter is the only viable option, sin=
ce we lack access to the Netbackup sources. So, I made two chang=
es to the default Netbackup client installation.
<br clear=3D"all"></div>
<div>In /etc/xinetd.d I added:</div>
<div> </div>
<div>env &=
nbsp; =3D LD_ASSUME_KERNEL=3D2.4.1</div>
<div> </div>
<div>to the all of the backup client daemon files.</div>
<div> </div>
<div>and I wrapped bpbkar in a shell script:</div>
<div> </div>
<div>1) mv /usr/openv/netbackup/bin/bpbkar /usr/openv/netbackup/bin/bp=
bkar.real</div>
<div> </div>
<div>2) cat > /usr/openv/netbackup/bin/bpbkar</div>
<div>#!/bin/sh<br>export LD_ASSUME_KERNEL=3D2.4.1<br>/usr/openv/netbackup/b=
in/bpbkar.real $*<br> </div>
<div>3) chmod 555 /usr/openv/netbackup/bin/bpbkar </div>
<div> </div>
<div>In preliminary testing this solution produced exit status 0 from the c=
lient backup. I was able to restore the backed up data to t=
he client as well. This does, however put the RHEL3 clients in u=
nsupported territory. But, they were unsupported to begin with. =
=20
</div>
<div> </div>
<div>If the machine is mission critical you should probably =
make sure the risk of being unsupported by Veritas is acceptable with the p=
owers that be.</div>
<div> </div>
<div>-- <br>-Adam </div>
------=_Part_1_6904426.1140216055338--
|
