My report looks like this:

These dumps were to tape DailySet150.
The next tape Amanda expects to use is: DailySet150.

FAILURE AND STRANGE DUMP SUMMARY:
  pst        /pst lev 0 FAILED [Estimate timeout from pst]


STATISTICS:
                          Total       Full      Daily
                        --------   --------   --------
Estimate Time (hrs:min)    0:15
Run Time (hrs:min)         0:15
Dump Time (hrs:min)        0:00       0:00       0:00
Output Size (meg)           0.0        0.0        0.0
Original Size (meg)         0.0        0.0        0.0
Avg Compressed Size (%)     --         --         -- 
Filesystems Dumped            0          0          0
Avg Dump Rate (k/s)         --         --         -- 

Tape Time (hrs:min)        0:00       0:00       0:00
Tape Size (meg)             0.0        0.0        0.0
Tape Used (%)               0.0        0.0        0.0
Filesystems Taped             0          0          0
Avg Tp Write Rate (k/s)     --         --         -- 

USAGE BY TAPE:
  Label             Time      Size      %    Nb
  DailySet150       0:00       0.0    0.0     0



NOTES:
  planner: tapecycle (1) <= runspercycle (10)
  planner: Adding new disk pst:/pst.
  driver: WARNING: got empty schedule from planner
  taper: tape DailySet150 kb 0 fm 0 [OK]



DUMP SUMMARY:
                                     DUMPER STATS            TAPER STATS 
HOSTNAME     DISK        L ORIG-KB OUT-KB COMP% MMM:SS  KB/s MMM:SS  KB/s
-------------------------- --------------------------------- ------------
pst          /pst        0 FAILED ---------------------------------------

(brought to you by Amanda version 2.4.4p4)

Thats all. I tested with a seperate config. 
 

-----Ursprüngliche Nachricht-----
Von: Alexander Jolk [mailto:alexj AT buf DOT com] 
Gesendet: Mittwoch, 2. November 2005 13:36
An: Sebastian Kösters
Cc: amanda-users AT amanda DOT org
Betreff: Re: AW: AW: Estimate timeout from server

Sebastian Kösters wrote:
> It failes only doing amdump config

Would you happen to have a relevant error message to show from your 
amdump report?

> Amandad on client
[...]
> amandad: time 0.000: got packet:
> --------
> Amanda 2.4 REQ HANDLE 000-E0426409 SEQ 1130912894
> SECURITY USER amanda
> SERVICE sendsize
> OPTIONS features=fffffeff9ffe0f;maxdumps=1;hostname=pst;
> GNUTAR /pst 0 1970:1:1:0:0:0 -1 OPTIONS |;bsd-auth;compress-fast;index;
[...]
> amandad: time 3428.573: sending REP packet:
> ----
> Amanda 2.4 REP HANDLE 000-E0426409 SEQ 1130912894
> OPTIONS features=fffffeff9f00;
> /pst 0 SIZE 84404220
> ----
> 
> amandad: time 3438.570: dgram_recv: timeout after 10 seconds
> amandad: time 3438.570: waiting for ack: timeout, retrying

Sounds like a simple estimate timeout to me, 3500s for one partition is 
quite long.  Bump up your etimeout in amanda.conf to something like 
5000s and see whether that works.  Or try to find out why estimate on 
the pst:/pst takes so long, and do something about that.  You might for 
instance split it up in smaller chunks.  Or switch to server side 
estimates which are instant.

You should have got a clear message in amdump's report though, saying 
`estimate timeout', which is english for `estimate timeout'.

Alex

-- 
Alexander Jolk  * BUF Compagnie * alexj AT buf DOT com
Tel +33-1 42 68 18 28  *  Fax +33-1 42 68 18 29