SUMMARY: 10_Recommended Breaks Netbackup?

Further analysis showed that the 10_Recommended cluster
had not applied completely. There had been patches that
applied to the global zone, but died in a non-global zone.
The application for the non-global zones failed, but the
cluster install would continue... Until we hit a patch
that required one of those that had failed in the non-global
zones. Then we were stuck. We couldn't reapply the initial
failed patch since it was already installed in the global
zone, but if you tried to install it in the non-global zone,
patchadd would quit because it was a patch that only can
be applied to the global zone. Fun.

Anyway, we manually backed out some of the failed patches
and reapplied them and got the cluster install to run to
completion. After that, using the "sg.install" tool in
Netbackup was able to find and configure the "sg" devices.
The numbering changed, but with the "tpconfig" tool, we
told Netbackup where to look for it.

So in the end, this turned out to be some kind of patchadd
problem, not really something with Netbackup.

On 8/24/2009 at 11:46 AM, "Crist Clark" <Crist.Clark@globalstar.com> wrote:
> We just applied the 10_Recommended cluster to one of our
> Netbackup servers. The sg driver that comes with Netbackup
> to control the tape robot stopped working. Anyone else run
> into this?
>
> Here is what I'm seeing on the console,
>
>   Aug 24 11:43:18 fred tldcd[537]: TLD(0) [537] robotic path /dev/sg/c1t1l1
> does not exist
>   Aug 24 11:43:18 fred tldd[523]: TLD(0) unavailable: initialization
failed:
> Unable to open robotic path
>
> And it's right, the links in /dev were broken; pointing at
> nodes in /devices that no longer exist.
>
> The version of Netbackup,
>
>   # /usr/openv/netbackup
>   # cat version
>   HARDWARE SOLARIS
>   VERSION NetBackup 6.5.3
>   RELEASEDATE Fri Oct 31 00:23:11 CDT 2008
>   BUILDNUMBER 20081030
>
> And the patch cluster kernel patch is,
>
>   # uname -a
>   SunOS fred 5.10 Generic_127127-11 sun4u sparc SUNW,Sun-Fire-V245
>
> I should note that there was a little bit of work to get
> the patch cluster to apply. Problems with the permissions
> on one of the scripts in another patch. But the kernel
> patch itself, 127127-11, went on clean as far as I recall.
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers