On Thu, 13 Feb 2003 at 6:14pm, Sean McGeever wrote
> > Tru64-client sendsize.debug:
> >
> > 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"
> > 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).
Hi Joshua,
thanks for the pointers...
> Does /dev/rdisk/dsk0a exist, and is it readable by
> amanda?
yes:
$ ls -al /dev/rdisk/dsk0*
crw-rw-r-- 1 root system 19, 34 Nov 6 15:52 /dev/rdisk/dsk0a
crw-rw-r-- 1 root system 19, 36 Nov 6 15:52 /dev/rdisk/dsk0b
crw-rw-r-- 1 root system 19, 38 Nov 6 15:52 /dev/rdisk/dsk0c
crw-rw-r-- 1 root system 19, 40 Nov 6 15:52 /dev/rdisk/dsk0d
crw-rw-r-- 1 root system 19, 42 Nov 6 15:52 /dev/rdisk/dsk0e
crw-rw-r-- 1 root system 19, 44 Nov 8 10:30 /dev/rdisk/dsk0f
crw-rw-r-- 1 root system 19, 46 Nov 6 15:52 /dev/rdisk/dsk0g
crw-rw-r-- 1 root system 19, 48 Nov 6 15:52 /dev/rdisk/dsk0h
(amanda user secondary group is 'system')
> Can you run the above dump command by hand?
No:
$ /sbin/dump 0Ssf 1048576 - /dev/rdisk/dsk0a
dump: NEEDS ATTENTION: Do you really wish to overwrite a file system ?: ("yes"
or "no") yes
dump: Dumping from host $Tru64-client
dump: Date of this level 0 dump: Fri Feb 14 11:36:22 2003 GMT
dump: Date of last level dump: Dumping /dev/rdisk/dsk0g to /dev/rdisk/dsk0a
dump: Mapping (Pass I) [regular files]
dump: Mapping (Pass II) [directories]
dump: Corrupted directory, i-node: 142572
dump: Corrupted directory, i-node: 142572
dump: Corrupted directory, i-node: 142572
dump: Corrupted directory, i-node: 142572
dump: Corrupted directory, i-node: 142572
dump: Corrupted directory, i-node: 142572
dump: Corrupted directory, i-node: 142572
dump: Corrupted directory, i-node: 142572
Unaligned access pid=273235 <dump> va=0x11ffeb297 pc=0x12000dad0 ra=0x12000db14
inst=0xa02f0004
Unaligned access pid=273235 <dump> va=0x11ffeb293 pc=0x12000dae4 ra=0x12000db14
inst=0xa04f0000
Unaligned access pid=273235 <dump> va=0x11ffeb293 pc=0x12000db24 ra=0x12000db14
inst=0xa18f0000
dump: SIGSEGV received -- ABORTING!
Resources lost
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...)?
Thanks again for your advice, Joshua,
Cheers,
Sean
|
