Hi John,
Thanks for the help and the invaluable tools. I managed to get the
amcheck to run successfully and it seemed that the last compile didn't
detect /sbin/dump. I re-ran the steps for cleaning and recompiling again and
it was ok after this. I must have slipped up somewhere with the second
rebuild after installing dump.
Again thanks for your help.
Matt
----- Original Message -----
From: "John R. Jackson" <[EMAIL PROTECTED]>
To: "Matthew Baker" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, July 20, 2001 6:17 PM
Subject: Re: [DUMP program not available]
> Tried this. When I first installed amanda on the client (yes I am
>talking about the client) dump wasn't present so I installed it using:
>apt-get install dump and recompiled amanda. I ran make distclean and
removed
>config.cache before running config again. ...
Oh, fine. So you're one of those annoying people who do the right
thing :-).
Any chance selfcheck (and maybe some other parts of Amanda) didn't get
updated when you rebuilt things? What does an "ls -l" have to say about
the modification time of (e.g.) amandad and selfcheck? Presumably they
would be very close to each other.
Run "strings .../selfcheck | grep dump". You should see /sbin/dump
listed in there someplace. If you don't, selfcheck was *not* compiled
with DUMP support (i.e. ./configure did not find dump when it was run).
Run amcheck again and look at /tmp/amanda/amandad*debug. You'll see a
"SERVICE selfcheck" line followed by an "OPTIONS ;" line and then some
other lines for each of the client disks. Take the lines starting *after*
the SERVICE one (i.e. start with OPTIONS) up to, but not including,
the "--------" line and put them in a temp file. For instance, here's
what I used a few minutes ago:
OPTIONS ;
DUMP /work 0 OPTIONS |;bsd-auth;index;
DUMP /var 0 OPTIONS |;bsd-auth;index;
DUMP /utdb 0 OPTIONS |;bsd-auth;index;
DUMP /unitree 0 OPTIONS |;bsd-auth;index;
DUMP /opt 0 OPTIONS |;bsd-auth;index;
DUMP /home/fortress/a 0 OPTIONS |;bsd-auth;index;
DUMP / 0 OPTIONS |;bsd-auth;index;
(actually, any one DUMP line would be sufficient to test your problem).
Then, **as the Amanda user**, run selfcheck by hand with that temp file
as stdin. When I tried it, here's what I got:
OPTIONS ;
OK /dev/rdsk/c1t2d0s6
OK /dev/md/rdsk/d3
OK /dev/rdsk/c1t3d0s3
OK /dev/rdsk/c1t2d0s5
OK /dev/md/rdsk/d4
OK /dev/md/rdsk/d5
OK /dev/md/rdsk/d0
OK /usr/sbin/ufsdump executable
OK /usr/sbin/ufsrestore executable
OK /etc/dumpdates read/writable
OK /dev/null read/writable
OK /var/amanda/tmp has more than 64 KB available.
OK /var/amanda/tmp has more than 64 KB available.
OK /etc has more than 64 KB available.
Presumably it will fail for you.
Now, run it again, but under control of your system call trace program
(e.g. "truss" or "strace", etc). Put the trace output in a file (it
will be reasonably large). Either send that to me, or look through it
for access() system calls, and make sure you a) see a call to look up
/sbin/dump and b) the call succeeds.
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
