On Fri, 14 Feb 2003 at 1:19pm, Sean McGeever wrote

> > > Tru64-client sendsize.debug:

I know nothing of Tru64, but...

> > > sendsize: debug 1 pid 268247 ruid 203 euid 203 start time Thu Feb 13 
> 17:39:50 2003
> > > /usr/local/libexec/sendsize: version 2.4.2p2
> > > calculating for amname '/', dirname '/'
> > > sendsize: getting size via dump for / level 0
> > > sendsize: running "/sbin/dump 0Ssf 1048576 - /dev/rdisk/dsk0a"

At least on Linux, the "S" flag is used to get estimates (this is what 
amanda is trying to do here, not actually get a backup).  Obviously, for 
this dump, S means something else.

> > > running /usr/local/libexec/killpgrp
> > > dump: Cannot fopen /dev/tty for reading
> > > query(): fopen(): No such device or address
> > 
> > That would seem to be the problem (i.e. it can't seem to open
> > /dev/rdisk/dsk0a).  

Actually, it can't open /dev/tty to ask you the question it asks below.

> $ /sbin/dump 0Ssf 1048576 - /dev/rdisk/dsk0a
> dump: NEEDS ATTENTION: Do you really wish to overwrite a file system ?: 
> ("yes" or "no") yes

Agh that's scary.  Obviously the wrong flags.

> However, playing around with the options to dump on the client's command line 
> yields: 
> 
> $ /sbin/dump 0f - /dev/rdisk/dsk0d
> dump: Dumping from host $Tru64-client
> dump: Date of this level 0 dump: Fri Feb 14 11:50:16 2003 GMT
> dump: Date of last level dump: Dumping /dev/rdisk/dsk0d (/usr) to standard 
> output
> dump: Mapping (Pass I) [regular files]
> dump: Mapping (Pass II) [directories]
> dump: Estimate: 1270958 blocks being output to pipe
> 
> ... and this does indeed dump to stdout.  So, can you please advise where 
> I can alter the options to dump when called from amdump on the server
> (e.g., at build time on either server or client, at runtime...)?

Amanda "should" get the right options, or it's a bug.  Are you sure that's 
the right dump for your filesystems?  Also, you could try upgrading to 
2.4.3 or 2.4.4b1.

-- 
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University