Jon LaBadie <jon AT jgcomp DOT com> wrote in message
<20060304164617.GA12095 AT butch.jgcomp DOT com>

[snip]
> Clarification please.  Does it always seem corrupted on the first taped
> image? Is that the only corrupted image.  Is that first image always the
> same DLE.
> 
No, it is a specific directory (/boot). If I exclude it from the dump, all
is well. If I include something else (smaller, so it appears first) in the
dump, then that is verified, before things go awry.

> Reason I ask is to check if a manual dump of a DLE that consistantly
> corrupts could be used to confirm that it can be dumped successfully
> outside of amanda. Find the exact command line and try running it.  Don't
> forget to build an exclude file. :)
> 
Not sure how to go about finding the exact command. Fortunately, this DLE
has no exclusions.

I did a dump to the holding disk, without a tape mounted, to get the image.
I then stripped of the first 32k bytes to lose the tape header, and tried to
untar the rest. That gave a corrupt file error in the failing image, but a
valid output on non-failing images. I conclude that it is the dump that's
going wrong before it gets to the taper.

I then did a gtar on the failing directory, without amdump's involvement.
This was successful.

> BTW amverify may not be doing all that much.  The dump programs are
> specific to the clients and may not be available on the tapehost.  In that
> case all amverify can do is see that the tape is readable.
> 
In this case the tapehost and the client are one and the same. 
There is an instruction in amverify that reads
RESULT=`$AMRESTORE -h -p $DEVICE 2> $TEMP/amrestore.out \
                        | doonefile 2> $TEMP/onefile.errors`
amverify enters this, but doesn't exit. It seems to have hung in amrestore.
Unfortunately, I haven't been able to find my way around amrestore
sufficiently to find out exactly what's happening. 
Of course, this is a secondary problem, but I don't think it's very nice for
amrestore to die silently on a corupt image.

I then tried to find my way around amdump, to find the cause of the initial
problem, but I'm afraid I got totally lost, and life demanded that I turned
my attention elsewhere :(

-- 
Tony van der Hoff          | mailto:tony AT vanderhoff DOT org
Buckinghamshire, England