> 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]
