Thanks. That mount point was an old one I had forgotten to remove (restoring
a disk). Unmounting it seemed to have helped... for now - double-checking
with the vendor to see if there's something in vdump to be flushed out.
Regards,
James
-----Original Message-----
From: John R. Jackson [mailto:[EMAIL PROTECTED]]
Sent: Monday, November 13, 2000 7:57 PM
To: Tung, James
Cc: '[EMAIL PROTECTED]'
Subject: Re: FW: vdump returns 1
>> ... I'm getting an error with vdump - but I
>> can't seem to flush out the problem - it work fine manually, but I get an
>> error right at the very end of the dump at night.....
What do you mean by "it work fine manually"? Do you mean you ran the
dump command by hand (without the 'u' option, of course) and it worked
and you displayed $status (or $?, depending on your shell) immediately
afterward and it was zero?
>> | vdump: unable to get info for file <./orbit_root>; [70] Stale NFS file
>> handle
I'm guessing these messages are what triggers the eventual return code
of 1. This looks like a bug in dump and should be reported to your
vendor. The particular situation should probably be ignored (logged
maybe, but not produce an error exit code).
As to how to fix it (i.e. get rid of the stale NFS handle), I'm not
sure. One way would be to get "orbit" to answer role call again :-)
(I assume this was a mount of the root file system from that machine on
this machine). Another would be to reboot this machine.
There may be a "force" option to the unmount command to get this machine
to let go of the idea of the remote machine, but I've never had much luck
with that. You might also be able to remove the mount point, but again,
that's iffy.
> James Tung
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
