Red Hat Bugzilla – Bug 447692
Wrong changer command: mtx vs mtx-changer
Last modified: 2012-07-19 11:13:47 EDT
Description of problem:
File /etc/bacula/bacula-sd.conf has:
Name = Autochanger
Device = Drive-1
Changer Command = "/usr/sbin/mtx %c %o %S %a %d"
Changer Device = /dev/sg1
While the 'Changer Command' as such doesn't work in most
installations and should be bacula's own:
Changer Command = "/usr/libexec/bacula/mtx-changer %c %o %S %a %d"
Once I changed to this with HP MSL2024 library, things started
If the plain mtx is still preferred for some reason, bacula's
own script should be there at least as commented option to easy
switch. Now I had to spend some time googling and studying the
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Buy a HP MSL2024
2. Hook it into system and configure it
3. Default configuration doesn't work.
Give console command:
and it fails to 'slots' mtx command. (it's the first command run,
returns number of library slots).
Autolabeling should work with default configs.
I'm not sure where that plain mtx came from, docs claim to this
script too and everybody seems to use the script, not the binary directly.
EPEL contains 2.4.4-2.el5 and I'm about to push 2.4.4-5.el5. I'm doing some housekeeping in Bacula bugs, please reopen this bug if it's still present in Bacula for RHEL 5 with the new update.
You're too dumb or lazy to maintain packages if you can't make that check yourself. Too arrogant if you *close* bugs if you're that lazy.
Thanks, I'm not going to report any more bugs for bacula, do it yourself.
I've done the check myself, and I'm not able to reproduce the bug.
You might notice that the Bacula version the bug is opened on has been updated many times already, the default configuration uses mtx-changer and works fine as is without touching anything.
Do you prefer having the bug opened and left to rot?
> Steps to Reproduce:
> 1. Buy a HP MSL2024
> 2. Hook it into system and configure it
What's more I'm using a few different libraries; so if you don't want be lazy yourself, check if the bug is still present, otherwise go out, buy the library for me and send me one along with a supported system.
It's the absolute location of that script that is wrong in default configuration file. You're too dumb indeed. No, I don't care what you do with that report, reporting it was just waste of time anyway.
The script *is and has always been* in that location: