Uptime is about 5 days now, but this may be the beginning of the end.
Something made it think all data was new from the looks of this. This was the
first run of 20090323, 20090321 works fine. Another device mapper screwup?
It was updated by yum yesterday.
-- Forwarded Message
On Thursday 09 April 2009, Dustin J. Mitchell wrote:
On Thu, Apr 9, 2009 at 8:53 AM, Gene Heskett gene.hesk...@verizon.net
wrote:
Uptime is about 5 days now, but this may be the beginning of the end.
Something made it think all data was new from the looks of this. This was
the first run of
I ran another session after installing 0325, more of the same. Somewhat
different of course. Now I'm going to restart x to test a new radeonhd
driver, and will install 0326 do another session.
-- Forwarded Message --
Subject: The Coyote Den AMANDA MAIL REPORT FOR April 9,
On Thu, Apr 9, 2009 at 10:05 AM, Gene Heskett gene.hesk...@verizon.net wrote:
Yeas, but I thought we had worked out something that made amanda immune to
those little annoyances? Or was tar changed and the fix didn't work now?
Hard to say -- is there anything in the sendsize backup logs that
On Thu, Apr 9, 2009 at 8:53 AM, Gene Heskett gene.hesk...@verizon.net wrote:
Uptime is about 5 days now, but this may be the beginning of the end.
Something made it think all data was new from the looks of this. This was the
first run of 20090323, 20090321 works fine. Another device mapper
Gene Heskett wrote at 08:53 -0400 on Apr 9, 2009:
Uptime is about 5 days now, but this may be the beginning of the
end. Something made it think all data was new from the looks of
this. This was the first run of 20090323, 20090321 works fine.
Another device mapper screwup? It was
Gene Heskett wrote at 10:05 -0400 on Apr 9, 2009:
On Thursday 09 April 2009, Dustin J. Mitchell wrote:
On Thu, Apr 9, 2009 at 8:53 AM, Gene Heskett gene.hesk...@verizon.net
wrote:
Uptime is about 5 days now, but this may be the beginning of the end.
Something made it think all data
On Thu, Apr 9, 2009 at 10:47 AM, John Hein jh...@timing.com wrote:
This (snippet below from the gtar NEWS file) was added in 1.21
==
* New options --no-check-device, --check-device.
This was actually added in 1.19.90, according to amgtar(8), and Gene
is using the
John Hein wrote at 08:47 -0600 on Apr 9, 2009:
This (snippet below from the gtar NEWS file) was added in 1.21
Woops. Sorry --no-check-device was added for 1.20. I've never tested
it, however. If you can prove a device number change and use of this
option is causing the big incremental dump
On Thursday 09 April 2009, John Hein wrote:
Gene Heskett wrote at 10:05 -0400 on Apr 9, 2009:
On Thursday 09 April 2009, Dustin J. Mitchell wrote:
On Thu, Apr 9, 2009 at 8:53 AM, Gene Heskett gene.hesk...@verizon.net
wrote:
Uptime is about 5 days now, but this may be the beginning of
On Thursday 09 April 2009, Dustin J. Mitchell wrote:
On Thu, Apr 9, 2009 at 10:47 AM, John Hein jh...@timing.com wrote:
This (snippet below from the gtar NEWS file) was added in 1.21
==
* New options --no-check-device, --check-device.
This was actually added in
I'm trying to migrate an amanda client, SGI/IRIX with amanda 2.4.1p1
from server Solaris 9 with amanda 2.4.4 to a server Solaris 10 with
amanda 2.6.1.
I have an error, but don't see anything standing out in the client's
/tmp/amanda tree.
FAILURE DUMP SUMMARY:
everest /images3 lev 0 FAILED
On Thu, Apr 9, 2009 at 4:21 PM, Brian Cuttler br...@wadsworth.org wrote:
everest /images3 lev 0 FAILED [dumper1 died]
Check the dumper debug logs on the server, rather than the client.
Dustin
--
Open Source Storage Engineer
http://www.zmanda.com
As part of the effort to make development more visible, I've moved the
mirror of the Subversion repository from nikolasco on GitHub to zmanda
on GitHub. This will let me expose development branches on my nikolasco
account, the way dustin has with the perltaper branch
: start at Thu Apr 9 16:48:27 EDT 2009
amdump: datestamp 20090409
amdump: starttime 20090409164827
amdump: starttime-locale-independent 2009-04-09 16:48:27 EDT
planner: pid 22319 executable /usr/local/libexec/amanda/planner version
2.6.1-20090227
planner: build: VERSION=Amanda-2.6.1-20090227
planner
: pid 23052 finish time Thu Apr 9 16:48:47 2009
amdump.1
amdump: start at Thu Apr 9 16:48:27 EDT 2009
amdump: datestamp 20090409
amdump: starttime 20090409164827
amdump: starttime-locale-independent 2009-04-09 16:48:27 EDT
planner: pid 22319 executable /usr/local/libexec/amanda/planner
On Thu, Apr 9, 2009 at 4:55 PM, Brian Cuttler br...@wadsworth.org wrote:
# more chunker.20090409164847.debug
That's a chunker debug log -- do you have a dumper debug log?
dumper.20090409164847.debug or something similar? You may have
several -- see if you can find one that shows something
Brian,
Can you try this patch?
I need this path to connect to a 2.4.2p1 client, I was not able to
compile 2.4.1
Jean-Louis
Brian Cuttler wrote:
I'm trying to migrate an amanda client, SGI/IRIX with amanda 2.4.1p1
from server Solaris 9 with amanda 2.4.4 to a server Solaris 10 with
amanda
On Thu, Apr 9, 2009 at 7:20 PM, Jean-Louis Martineau
martin...@zmanda.com wrote:
Can you try this patch?
I need this path to connect to a 2.4.2p1 client, I was not able to compile
2.4.1
The patch looks good to me, whether it solves Brian's problem notwithstanding.
Dustin
--
Open Source
FAILED Script 'abas-stop' command 'PRE-HOST-ESTIMATE': sendsize: error [exec
/usr/libexec/amanda/application/abas-stop: Exec format error]
What does this means ? The pre/post scripts are not ran. Scripts run on
ll /usr/libexec/amanda/application/
4 -rwxr-xr-x 1 amandabackup disk96 Apr 8
20 matches
Mail list logo