Description of problem: Using the new amanda-server, the disk becomes filled up, although I'm not positive that this was due to the new version. When trying to run amflush, I received the error message " A TAPE ERROR OCCURRED: [No acceptable volumes found]" sent in the AMFLUSH MAIL REPORT. When I downgraded to amanda-server-3.3.9-3.fc25.x86_64, everything worked perfectly. Version-Release number of selected component (if applicable): amanda-server-3.4.1-1.fc25.x86_64 How reproducible: Always Steps to Reproduce: 1.Use a hard disk properly configured for amanda backups 2.Generate backups that require amflush to finish up 3.Run amflush Actual results: Amflush fails with an error message: A TAPE ERROR OCCURRED: [No acceptable volumes found]. No files in the target slot were deleted. Expected results: Amflush should work properly. All of the previous saved backups should be deleted in the target slot (and were when using amanda-server-3.3.9-3.fc25.x86_64) Additional info: Also, backups failed for a system running Solaris 5.10 with the SFWamnda amanda package, with the error message: badly formatted response from machinename. This error never occurred with amanda-server-3.3.9-3.fc25.x86_64.
There have been several new versions since 3.4.1. Currently 3.4.5 is on its way to updates-testing. Please test these updates and let us know if the problem is still present. And please do attach the relevant debug logs so we have something to examine, since there isn't much we can do without them besides look for anything which might look to be related in the release notes. Also, please open a separate ticket for the second problem if it still exists. Reporting two problems in one ticket just leads to confusion.
How exactly do I get this 3.4.5 version?
At this point you just update your system. 3.4.5 is the current version of the amanda packages in Fedora 24, 25, 26 and rawhide.
I just install 3.4.5 and ran amcheck -s The result was: '/etc/amanda/ms/amanda.conf', line 73: warning: Keyword usetimestamps is deprecated. Amanda Tape Server Host Check ----------------------------- NOTE: Holding disk '/home/scratch/amanda': 127459328 KB disk space available, using 127356928 KB '/etc/amanda/ms/amanda.conf', line 73: warning: Keyword usetimestamps is deprecated. slot 1: Can't open tape device chg-disk: No such file or directory all slots have been loaded Taper scan algorithm did not find an acceptable volume. (expecting volume 'VOL16' or a new volume) ERROR: No acceptable volumes found Server check took 0.543 seconds (brought to you by Amanda 3.4.5) Needless to say, there are no problems at all with amanda 3.3.9 in backing up to my hard drive with using the file:// description for the tapedev.
Well, that output is far more than has been provided previously in this ticket. Obviously the 'usetimestamps' thing is merely a warning; it will be set to 'yes' regardless of what you specify. It should simply be removed from your config to quiet the complaint. I don't use vtapes myself, but I recall that the old chg-disk setting has been deprecated for some time and I believe it was finally removed in 3.4. I have no idea what you have in your configuration since you have not provided it, but have you read through amanda-changers and adapted to the new chg-disk:VTAPEROOT driver?
Created attachment 1292474 [details] amanda.conf file Here is my amanda.conf file
I changed the tpchanger setting so that I no longer get the "Can't open tape device chg-disk" error message. Here is the current error message that I get: '/etc/amanda/ms/amanda.conf', line 73: warning: Keyword usetimestamps is deprecated. Amanda Tape Server Host Check ----------------------------- NOTE: Holding disk '/home/scratch/amanda': 127459328 KB disk space available, using 127356928 KB '/etc/amanda/ms/amanda.conf', line 73: warning: Keyword usetimestamps is deprecated. Searching for label 'VOL16':Label 'VOL16' not found slot 0:Slot 0 not found slot ?:Slot not found ERROR: Slot not found
I really have no experience with vtapes but it appears that by using tapedev "file://backup/vtapes/ms/slots" You're telling everything to use one single vtape. I'm not sure the previous tpchanger line is even used at that point. You're generally supposed to define a changer that has multiple vtapes and then reference the defined changer in a tapedev line. But since my personal setup uses an actual tape drive and library, I'm just going by what I read at https://wiki.zmanda.com/index.php/How_To:Set_Up_Virtual_Tapes I'm still not seeing where there's an actual bug here, though; this still appears to me to be a configuration issue. You could argue that 3.4 should never been pushed to a stable release since it deprecated things which were working with older versions and I wouldn't disagree. However, I wasn't involved with that and in fact got involved partly to sort out the issues which I personally ran into when 3.4 was pushed. In any case, there's no way to go back now though you can of course use the dnf versionlock plugin to ensure that the amanda package is not updated on your machine(s). If we could isolate an actual bug then I would be happy to coordinate with upstream to get a fix to you in a format you could test. I would suggest at this point that you might have better luck with an email to the amanda-users list with your current config file and error output.
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.