Tony wrote:
That all sounds pretty straight forward. I turned dip switches 1
& 2 OFF so that HW compression is disabled and can't be turned
on again by the software.
But from the description of the problem, it is not the compression
that needs to be disabled. There was the possibility that
you had blocksize problem, but we were not sure.
Because blocksize and compression have to do with the setup of
the drive, there was the explanation of how to disable hardware
compression and set the blocksize to variable. And then try again.
But from the beginning, I was not convinced it was a blocksize
problem. It was only because the "strange" header was 9 bytes long.
And that is a really weird length for a blocksize.
But it did not hurt to set the compression off anyway, and, you
had indeed a problem with compression in the first place. That's
probably corrected now.
But then there is the problem that when you migrated the drive
to another computer, amanda has some undefined trouble when
reading the header. Somehow it breaks off after 9 bytes.
But not always, only in about 95% of the cases. And that's
really weird. Software or configuration problems should be 100%
repeatable, given the correct environment.
When you "amcheck" the tape 22 times in a row, is the error, if
any consistent, and then suddenly it works? Or did you execute
another command inbetween, or did you want a little longer just
before executing the succesful amcheck?
I try to label a tape and it works fine. I then run an amcheck
Strange, because amlabel verifies the label too. So there is
at least one program that can successfully read the label
at least once.
and still receive the same error:
amcheck-server: strange amanda header: "AMANDA: T"
ERROR: /dev/nst0: not an amanda tape
If I do "dd bs=1k if=/dev/st0 of=stuff" and then look at the
file "stuff" the first line is:
AMANDA: TAPESTART DATE X TAPE daily02fri
Now you specified to use 1k blocks. dd tells also how many block
in needed to read the "file". It should be 32+0 (unless you changed
the default blocksize of amanda).
Maybe there are some invisible characters inbetween. Try:
hexdump -C stuff
or
dd bs=32k if=/dev/st0 | hexdump -C
followed by a ^L char on the next line and then lots of ^@ chars
(does this matter, or is it just padding ?)
Yes, actually is does matter. It should be padded to exactly 32Kbytes.
I tried amcheck multiple times and again, it appears to be
succesful about 5% or less of the time (took me 22 tries to get
one successful).
Unless there is some subtle change in the conditions, these kind of
random errors point to a hardware problem. IMO.
--
Paul Bijnens, Xplanation Tel +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUM Fax +32 16 397.512
http://www.xplanation.com/ email: Paul.Bijnens AT xplanation DOT com
***********************************************************************
* I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, F6, *
* quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, *
* PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, *
* kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... *
* ... "Are you sure?" ... YES ... Phew ... I'm out *
***********************************************************************
|
