Author: Gene Heskett <gene.heskett AT verizon DOT net>
Date: Fri, 10 Apr 2009 13:54:31 -0400
Dustin; It is looking like its catching up, after several runs with intervening versions, it has caught up with whatever change made that made it think everything was new. I don't believe it was devi
Author: "Dustin J. Mitchell" <dustin AT zmanda DOT com>
Date: Fri, 10 Apr 2009 14:07:36 -0400
On Fri, Apr 10, 2009 at 1:54 PM, Gene Heskett <gene.heskett AT verizon DOT net> wrote: As in the past, this problem really exists between tar and the kernel, so Amanda versions aren't relevant. The o
Author: Gene Heskett <gene.heskett AT verizon DOT net>
Date: Fri, 10 Apr 2009 15:26:49 -0400
wrote: You recall that when I went from 0319 to 0331, it wasn't this, it was a total, all results missing failure, and reverting to 0319 fixed that, so I believe I am looking at 2 distinct problems.
Author: "Dustin J. Mitchell" <dustin AT zmanda DOT com>
Date: Fri, 10 Apr 2009 15:49:49 -0400
On Fri, Apr 10, 2009 at 3:26 PM, Gene Heskett <gene.heskett AT verizon DOT net> wrote: OK, I'm glad you see the option in htop -- that's enough evidence for me. I know it's scripted, but there's not
If I'm following at all, for amgtar, you should be setting this as a property field in your amgtar application section (in my case "yes") property "CHECK-DEVICE" "yes" and it should be showing up in
Author: Gene Heskett <gene.heskett AT verizon DOT net>
Date: Fri, 10 Apr 2009 21:03:12 -0400
wrote: It was, maybe is. After verifying that 0319 worked after 0331 failed, I put 0331 back and it failed again. That is when I started trying to play catchup, running every version in order. I'm gl
Author: Gene Heskett <gene.heskett AT verizon DOT net>
Date: Fri, 10 Apr 2009 21:20:15 -0400
Oh its in amgtar.*.debug alright, as CHECK-DEVICE yes. This is NOT what it has been ordered to do. Since the debug is small, I'll include it: 1239390447.316901: amgtar: pid 24248 ruid 500 euid 500 ve
Author: Gene Heskett <gene.heskett AT verizon DOT net>
Date: Fri, 10 Apr 2009 15:31:39 -0400
wrote: I just found the string "--check-device no" in the sendbackup logs. amgtars logs say simply "--device " -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, ju
Author: Gene Heskett <gene.heskett AT verizon DOT net>
Date: Sat, 11 Apr 2009 22:41:04 -0400
I assume that's fixable, but that is the 2nd problem. The 1st is 'driver: WARNING: got empty schedule from planner' in any version newer than 0327. -- Cheers, Gene "There are four boxes to be used in
Author: "Dustin J. Mitchell" <dustin AT zmanda DOT com>
Date: Sun, 12 Apr 2009 10:38:03 -0400
On Sat, Apr 11, 2009 at 10:41 PM, Gene Heskett <gene.heskett AT verizon DOT Send along the planner debug file, please. Dustin -- Open Source Storage Engineer http://www.zmanda.com
Author: Gene Heskett <gene.heskett AT verizon DOT net>
Date: Sun, 12 Apr 2009 10:55:10 -0400
1239515105.612261: planner: pid 11858 ruid 500 euid 500 version 2.6.2alpha: start at Sun Apr 12 01:45:05 2009 1239515105.620545: planner: pid 11858 ruid 500 euid 500 version 2.6.2alpha: rename at Sun
Author: "Dustin J. Mitchell" <dustin AT zmanda DOT com>
Date: Sun, 12 Apr 2009 11:59:23 -0400
On Sun, Apr 12, 2009 at 10:55 AM, Gene Heskett <gene.heskett AT verizon DOT Hmm, no red flags here, either. How about the amdump.1 debug log? Dustin -- Open Source Storage Engineer http://www.zmanda.
Author: "Dustin J. Mitchell" <dustin AT zmanda DOT com>
Date: Sun, 12 Apr 2009 18:44:31 -0400
On Sun, Apr 12, 2009 at 4:53 PM, Gene Heskett <gene.heskett AT verizon DOT net> wrote: Jean-Louis, there were some nearby changes around 3/30/09: http://github.com/zmanda/amanda/commit/b3e8036688ebda
Author: Gene Heskett <gene.heskett AT verizon DOT net>
Date: Sun, 12 Apr 2009 22:20:35 -0400
wrote: Slim possibility I suppose, although up to 0319 seemed ok other than the symptoms of tar ignoring '--no-device-check' may have snuck in a bit earlier. But I was all caught up by the time I'd t
Author: Jean-Louis Martineau <martineau AT zmanda DOT com>
Date: Mon, 13 Apr 2009 09:17:30 -0400
Gene, Knowing which release failed is useful, but it is more useful if we can find why it failed, can you post all debug files generated by a failed run? From both amanda client and server. From the
Author: "Dustin J. Mitchell" <dustin AT zmanda DOT com>
Date: Mon, 13 Apr 2009 10:08:14 -0400
And, to pile on, please do *not* change things after this -- let's get a repeatable failure with the same variables. Dustin -- Open Source Storage Engineer http://www.zmanda.com
Author: Gene Heskett <gene.heskett AT verizon DOT net>
Date: Mon, 13 Apr 2009 11:14:13 -0400
The only thing I've changed in months (other than the data being backed up) is the version running. And that was a 'make install' by root, after unpacking the tarball as amanda, in /home/amanda, and
Author: "Dustin J. Mitchell" <dustin AT zmanda DOT com>
Date: Mon, 13 Apr 2009 18:17:01 -0400
OK, after some logfile exchange off-list, I think we're onto something here. The planner examines all DLEs to decide which incremental to promote, and selects coyote:/root. It finishes its loop, and
Author: Gene Heskett <gene.heskett AT verizon DOT net>
Date: Mon, 13 Apr 2009 20:54:06 -0400
I'm not an expert but that does look as if it makes sense. Where is the closing '}' ? Well, it did take several posts of the failure to get everybody's attention. Now to top that off, I'm getting ema
Author: Jean-Louis Martineau <martineau AT zmanda DOT com>
Date: Tue, 14 Apr 2009 07:42:34 -0400
I committed a fix, thank for finding the bug. CHECK-DEVICE is correct, properties are sent send to the 'support' application command because they are not needed, the script just log the default value