I have been running amanda-2.4.5 with app-arch/tar-1.15.1-r1 for some time on my clients w/o any issues. Recently I upgraded to tar 1.17. Since then all of my backups have been failing. Amanda is reporting, e.g. blackwidow /home RESULTS MISSING Although "amcheck" doesn't report any errors. I thought it may have something to do with my doing incrementals and the version of tar is different, so I tried to force a full backup, but I get segfaults when I run, e.g. amanda@ant ~ $ amadmin Daily force blackwidow amadmin: blackwidow:/ is set to a forced level 0 at next run. Segmentation fault The strace doesn't seem to reveal anything interesting. I'm sure I can downgrade tar and everything will work again (I recall doing just that about a year ago). But the question remains why doesn't amanda want to work with >tar-1.15.1-r1?
Created attachment 125961 [details] output of "strace amadmin Daily force blackwidow"
Try w/ >=amanda-2.5.1_p3-r4 please. If it still doesn't work, attach emerge --info output and backtrace. http://www.gentoo.org/proj/en/qa/backtraces.xml
Ok, here's what I have so far: I upgraded the server and (10) clients to amanda-2.5.2_p1-r1. The night's backups went fine with the exception of one client. Some of the incrementals worked on the client, but the majority of them failed with gtar: Unexpected field value in snapshot file But it was a ~x86 box running tar-1.18 so I'm theorizing that had to do with it. I downgraded tar to 1.17 no that box and ran "amadmin Daily force blackwidow" which this time did *not* segfault. I'll let you know the next night if the one client backs up. Do you know if there's anything holding back amanda 2.5* from being marked stable?
Well, thanks for testing. :)
I reported your problem to upstream, will see, if a fix follows.
Thansks for the heads-up, Stefan. The version of 'tar' on the Amanda server doesn't matter, particularly for 'amadmin', which doesn't invoke tar. During the Amanda *runs*, the version of tar *on the client* is important. There are known incompatibilities with old versions of Amanda and newer versions of tar. See http://wiki.zmanda.com/index.php/FAQ:What_versions_of_GNU_Tar_are_Amanda-compatible%3F for the whole story. The ebuilds don't respect those particular incompatibilities; this was reported in bug #175228, but that was closed as WONTFIX. If you could give the most recent versions of Amanda and tar for which you see this problem on both the client and the server, I would appreciate it. I will also try to replicate your error.
(In reply to comment #6) > If you could give the most recent versions of Amanda and tar for which you see > this problem on both the client and the server, I would appreciate it. I will > also try to replicate your error. I upgraded one of my clients to tar 1.17 and successfully performed a run, so at this point I can't replicate the error. If this problem does persist, it would be helpful if you could provide the debug logs for sendbackup, runtar, and sendsize. You will probably need to remerge Amanda with USE=debug. The files will appear in /var/spool/amanda/tmp.
Ok, here's an update and clarification: I was running amanda 2.4.5_p1 and tar 1.15.1-r1 on all (~10) machines. Backups ran fine. Then I upgraded tar to 1.17 on all machines (except one, will explain later). After the tar upgrade, (incremental) backups failed... "RESULTS MISSING". I looked on Google and thought it might have to do with incrementals and the new tar, so I tried to force a level 0 backup, but "amadmin <config> force ..." segfaults. The segfaults are likely completely independent of the tar issue. So then reported this bug. I was told to try amanda 2.5, so I upgraded to amanda 2.5.2_p1-r1 on all machines. On the next run all amanda dumps ran successfully except one host. On that host I got "/bin/tar returned 2" for most, but not all, incremental dumps. On that host I discovered it was running tar 1.18 (it was marked ~x86). So I then downgraded tar on that box to 1.17 and on the amanda host did "amadmin <config> force ...". This time amadmin did not segfault. Final result: last dumps ran a couple of hours ago. All dumps (level [012]) were successful. To summarize: amanda 2.4.5_p1 + tar 1.15.1-r1: GOOD (not sure about amadmin ... force) amanda 2.4.5_p1 + tar 1.17 : BAD (+ amadmin ... force segfaults) amanda 2.5.2_p1-r1 + tar 1.17 : GOOD (+ no segfaults with amadmin) The tar 1.18 problem i'm willing to forgive. It might have been due to the fact that the amanda server and client were running different versions of tar.
(In reply to comment #8) Thanks for the great description -- very helpful! > To summarize: > amanda 2.4.5_p1 + tar 1.15.1-r1: GOOD (not sure about amadmin ... force) > amanda 2.4.5_p1 + tar 1.17 : BAD (+ amadmin ... force segfaults) > amanda 2.5.2_p1-r1 + tar 1.17 : GOOD (+ no segfaults with amadmin) 2.4.5 is known not to work with tar >1.15.1-r1 (bug #175228), although I don't see how that would cause amadmin to segfault. That said, there have been hundreds of bugs fixed since then, so who knows. > The tar 1.18 problem i'm willing to forgive. It might have been due to the fact > that the amanda server and client were running different versions of tar. That's actually the one I'm concerned about. I just ran a dump of a machine with tar-1.18-r1 (I'll admit I'm using the development version of Amanda, but still..) at both level 0 and level 1 without difficulty. As I mentioned before, the version of tar on the server doesn't matter at all -- except for amverify, the Amanda server just treats the dumps as bytestreams. If you can duplicate the problem reliably, pls. post here. Otherwise, I think this bug can be closed as WORKSFORME?
Dustin, this issue leads again to my longstanding suggestion to add some checks to amanda: Whenever tar is to be used, amanda should check for the version of tar and compare against a list of good/bad releases of GNUtar, then WARN/STOP/continue/whatever is useful .... Additionally this could mean that amanda issues a general message like "Your release 1.18.xy has not yet been tested with Amanda - use with care", until someone has tested it successfully. This is backup/restore, no need for bleeding edge here. opinions welcome as always. Stefan
(In reply to comment #10) > Dustin, this issue leads again to my longstanding suggestion to add some checks > to amanda: Whenever tar is to be used, amanda should check for the version of > tar and compare against a list of good/bad releases of GNUtar, then > WARN/STOP/continue/whatever is useful .... > Additionally this could mean that amanda issues a general message like > "Your release 1.18.xy has not yet been tested with Amanda - use with care", > until someone has tested it successfully. > This is backup/restore, no need for bleeding edge here. > opinions welcome as always. I agree.. it's in my TODO list somewhere :)
We trust in you: You are one of the few getting paid for working through their todo-list here. ;) Stefan
Update: The host that was running tar 1.18, but then downgraded to 1.17 and had successful level 0 backups failed this morning on all it's level 1's: blackwidow /var lev 1 FAILED [/bin/tar returned 2] Upon further investigation it was discovered that it was running Amanda 2.4, *not* Amanda 2.5. Sorry for the confusion. If things run tonight then you can go ahead an close. But again, since most of my machines are stable x86 and it appears that the latest stable tar does not like the latest stable amanda, should amanda 2.5 be marked stable?
(In reply to comment #13) > But again, since most of my machines are stable x86 and it appears that the > latest stable tar does not like the latest stable amanda, should amanda 2.5 be > marked stable? Open another bug and, if you don't mind, copy me on it?
Since upgrading to 2.5 I've had no more issues. Closing. Thanks.
