John R. Jackson wrote:
>
> >> This would be a more accurate test:
> >>
> >> dump 0sf 1048576 - /dev/sda5 | (restore -tvf - ; cat > /dev/null)
> >
> >Suprisingly that ran fine:
>
> Not terribly surprising, but it shows the dump -> restore pipeline is
> not the problem. Now try this:
>
> /sbin/dump 0sf 1048576 - /dev/sda5 | /bin/gzip -dc | cat > /dev/null
That command fails with
gzip: stdin: not in gzip format
Taking out the "d" from the gzip command:
/sbin/dump 0sf 1048576 - /dev/sda5 | /bin/gzip -c | cat > /dev/null
DUMP: Date of this level 0 dump: Fri Jan 18 16:19:31 2002
DUMP: Dumping /dev/sda5 (/usr) to standard output
DUMP: Added inode 7 to exclude list (resize inode)
DUMP: Label: none
DUMP: mapping (Pass I) [regular files]
DUMP: mapping (Pass II) [directories]
DUMP: estimated 3037697 tape blocks.
DUMP: Volume 1 started with block 1 at: Fri Jan 18 16:19:41 2002
DUMP: dumping (Pass III) [directories]
DUMP: dumping (Pass IV) [regular files]
DUMP: 17.00% done at 1720 kB/s, finished in 0:24
DUMP: 34.60% done at 1751 kB/s, finished in 0:18
DUMP: 52.80% done at 1782 kB/s, finished in 0:13
DUMP: 71.24% done at 1803 kB/s, finished in 0:08
DUMP: 89.07% done at 1803 kB/s, finished in 0:03
DUMP: 100.00% done at 1811 kB/s, finished in 0:00
DUMP: Volume 1 completed at: Fri Jan 18 16:49:41 2002
DUMP: Volume 1 3261670 tape blocks (3185.22MB)
DUMP: Volume 1 took 0:30:00
DUMP: Volume 1 transfer rate: 1812 kB/s
DUMP: 3261670 tape blocks (3185.22MB)
DUMP: finished in 1800 seconds, throughput 1812 kBytes/sec
DUMP: Date of this level 0 dump: Fri Jan 18 16:19:31 2002
DUMP: Date this dump completed: Fri Jan 18 16:49:41 2002
DUMP: Average transfer rate: 1812 kB/s
DUMP: DUMP IS DONE
> What's in a sendbackup*debug file corresponding to one of these errors?
sendbackup: debug 1 pid 7505 ruid 50 euid 50 start time Fri Jan 18 15:46:30 2002
/usr/local/pkg/amanda-2.4.2p2/libexec/sendbackup: version 2.4.2p2
sendbackup: got input request: DUMP /usr 0 1970:1:1:0:0:0 OPTIONS
|;bsd-auth;compress-fast;index;
parsed request as: program `DUMP'
disk `/usr'
lev 0
since 1970:1:1:0:0:0
opt `|;bsd-auth;compress-fast;index;'
sendbackup: try_socksize: send buffer size is 65536
sendbackup: stream_server: waiting for connection: 0.0.0.0.53073
sendbackup: stream_server: waiting for connection: 0.0.0.0.53074
sendbackup: stream_server: waiting for connection: 0.0.0.0.53075
waiting for connect on 53073, then 53074, then 53075
sendbackup: stream_accept: connection from 134.173.32.73.44160
sendbackup: stream_accept: connection from 134.173.32.73.44161
sendbackup: stream_accept: connection from 134.173.32.73.44162
got all connections
sendbackup: spawning /bin/gzip in pipeline
sendbackup: argument list: /bin/gzip --fast
sendbackup-gnutar: pid 7506: /bin/gzip --fast
sendbackup: spawning /sbin/dump in pipeline
sendbackup: argument list: dump 0usf 1048576 - /dev/sda5
sendbackup: started index creator: "/sbin/restore -tvf - 2>&1 | sed -e '
s/^leaf[ ]*[0-9]*[ ]*\.//
t
/^dir[ ]/ {
s/^dir[ ]*[0-9]*[ ]*\.//
s%$%/%
t
}
d
'"
index tee cannot write [Broken pipe]
sendbackup: pid 7507 finish time Fri Jan 18 15:59:03 2002
error [compress got signal 24, /sbin/dump returned 3]
sendbackup: pid 7505 finish time Fri Jan 18 15:59:03 2002
> >... I've got working large
> >partitions on some other systems - including the tape host:
>
> Are those other systems with large partitions the same type of OS as
> the problem client?
Yes, the tape host (Chris) and the problem client (Odin) are both RedHat
Linux boxes. kernel 2.4.12, dump 0.4b25, gzip 1.3.2.
The tape host is using libext2fs 1.22 of 22-Jun-2001
The client: libext2fs 1.19 of 13-Jul-2000
I also get the failure on the /usr partition on the same client. That's
a 4Gb partition with 3Gb used. That's the /dev/sda5 I dumped above.
> >> > runtar: error [must be invoked by operator]
> >> ...
> >My config.status file on the troublesome client says:
> >
> ># ./configure --prefix=/usr/local/pkg/amanda-2.4.2p2 --with-user=backup --wit
> >h-config=hmcis --with-group=sys
>
> That may be what it says (--with-user=backup), but it's not what's built
> into the runtar binary. The binary is running as though you had said
> --with-user=operator.
You're right. After "make distclean", reconfig and reinstall the gnutar works.
I can't believe I had a build lying around that wasn't what I'd installed.
Thanks so much. At least I can run backups with compression once again.
--
[EMAIL PROTECTED] - HMC UNIX Systems Manager
My opinions are my own and probably don't represent anything anyway.
