Quoting Paul Bijnens <[EMAIL PROTECTED]>: > Andreas Sundstrom wrote: > > > All went well and the backup finished successful. Then I switched to my > > identically compiled 2.6.6-rc2 kernel and it fails with the same error as > earlier: > > These dumps were to tape dflt10. > > The next tape Amanda expects to use is: dflt11. > > The next new tape already labelled is: dflt12. > > > > FAILURE AND STRANGE DUMP SUMMARY: > > zappa.zapp /imagelib lev 1 FAILED [bad CONNECT response] > > zappa.zapp /boot lev 0 FAILED 20040615[could not connect to > zappa.zappa.cx] > > zappa.zapp /home/sunkan lev 1 FAILED 20040615[could not connect to > zappa.zappa.cx] > > zappa.zapp /var lev 1 FAILED 20040615[could not connect to > zappa.zappa.cx] > > zappa.zapp / lev 0 FAILED 20040615[could not connect to zappa.zappa.cx] > > zappa.zapp /home/emelie lev 0 FAILED 20040615[could not connect to > zappa.zappa.cx] > > zappa.zapp /apps lev 0 FAILED [bad CONNECT response] > > > > So I tarred up the /tmp/amanda dir and put it at > > ftp://zappa.cx/pub/amanda-zappa.cx.tar.gz if anyone wants to take a look at > it. > > This is the complete failed session and nothing else. > > In /tmp/amanda are mostly client files. The debug files are all, as > far as I can see, from the succeeded session. When failing, the > client does not even get started somehow, or did I miss that file? > > I miss the amdump.1 and log.2004xxxx file, which are the server side > logs (in ~amanda/dflt ). > > But I don't expect something shocking in those files anyway. > As it seems to be network related, I'm still more interested to know > if the client had trouble sending the packets, or the server had trouble > receiving it. A tcpdump trace of the failing session would be really > helpful.
I have tarred them up to the file: ftp://zappa.cx/pub/amdump-zappa.cx.tar.gz have a look if you have time for it. Also what do you recommend as parameters to tcpdump, it's all running on the same host does that mean I can sniff on "lo"? /Andreas
