vchanger-users Mailing List for vchanger

Brought to you by: jaybus2

vchanger-users — Vchanger User Discussion

You can subscribe to this list here.

2009	Jan	Feb	Mar	Apr (2)	May (6)	Jun (1)	Jul	Aug (6)	Sep (1)	Oct (1)	Nov (3)	Dec (2)
2010	Jan (3)	Feb (5)	Mar (20)	Apr (1)	May (1)	Jun	Jul	Aug (1)	Sep (1)	Oct	Nov	Dec (1)
2011	Jan (2)	Feb (2)	Mar (24)	Apr (34)	May (14)	Jun	Jul (31)	Aug (12)	Sep (5)	Oct	Nov	Dec
2013	Jan	Feb	Mar	Apr	May	Jun (6)	Jul	Aug (2)	Sep	Oct	Nov	Dec
2015	Jan	Feb	Mar (1)	Apr (3)	May (2)	Jun	Jul	Aug (10)	Sep (8)	Oct	Nov (6)	Dec (4)
2016	Jan	Feb (5)	Mar (1)	Apr	May (1)	Jun (6)	Jul (8)	Aug	Sep (1)	Oct	Nov (5)	Dec
2017	Jan	Feb	Mar	Apr (2)	May (3)	Jun (1)	Jul (8)	Aug	Sep (5)	Oct (9)	Nov	Dec
2018	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec (1)
2020	Jan	Feb	Mar	Apr	May (3)	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2022	Jan	Feb	Mar	Apr	May	Jun (4)	Jul (8)	Aug (4)	Sep (21)	Oct (3)	Nov	Dec
2023	Jan (24)	Feb (10)	Mar (13)	Apr (6)	May (14)	Jun	Jul	Aug (4)	Sep	Oct (1)	Nov	Dec
2025	Jan	Feb (2)	Mar (1)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

Flat | Threaded

1 2 3 .. 16 > >> (Page 1 of 16)

Re: [Vchanger-users] vchanger loading wrong volume

From: Justin C. <jus...@gm...> - 2025-03-24 13:04:14

vchanger is still not working any more for me, is there anyone who can help me solve this?

> On 23. Feb 2025, at 14:39, Justin Case <jus...@gm...> wrote:
> 
> Hi there,
> 
> I have a case of vchanger seemingly loading the wrong volume (see the attached director log)
> the director requests: usbdisk_0002_0016
> the vchanger loads: usbdisk_0001_0016 (notice the loaded volume is from magazine/disk 1, but requested was a volume from magazine/disk 2)
> 
> I have also checked the vchanger log and it is consistent with this observation. vchanger really does set the link to usbdisk_0001_0016 for drive 1
> 
> I have also checked ahandful of copy jobs preceding this job and there vchanger was loading the correct volumes.
> 
> 1) Why might this happen? 
> 2) Could this be a misconfiguration on my end? What might be wrongly configured?
> 3) Is there anything I can do about it?
> 
> <copy_job_log.txt>
> 
>

Re: [Vchanger-users] vchanger loading wrong volume

From: Marco G. <ga...@li...> - 2025-02-25 18:10:12

Mandi! Justin Case
  In chel di` si favelave...

> 1) Why might this happen? 

Because Bacula is 'greedy', and so (try to) backup on every media they
found; vchanger use a 'metaphore' of a changer, where every USB media is a
set of media (like a set of tapes) and every set of media have their device:
so if yo have three usb media, you have three set of media and three
devices.

If for any reason the current usb device exaust the media, bacula (try to)
mount volumes that are on other usb media.
Clearly cannot, so put the media on error state.


> 2) Could this be a misconfiguration on my end? What might be wrongly configured?

Mostly no; if you have followed the documentation, all will work; but this
sort of backup have some drawbacks, so if you lost or delay some usb media change
strange things can happen.


> 3) Is there anything I can do about it?

I've setup some scripts that (try to) fix this errors, and can run against
usb media. They are simple bash script full of italian sentences and
comments. sorry...

	https://wiki.lilliput.linux.it/files/bacula/

--

[Vchanger-users] vchanger loading wrong volume

From: Justin C. <jus...@gm...> - 2025-02-23 13:39:30

Attachments: copy_job_log.txt

Hi there,

I have a case of vchanger seemingly loading the wrong volume (see the attached director log)
the director requests: usbdisk_0002_0016
the vchanger loads: usbdisk_0001_0016 (notice the loaded volume is from magazine/disk 1, but requested was a volume from magazine/disk 2)

I have also checked the vchanger log and it is consistent with this observation. vchanger really does set the link to usbdisk_0001_0016 for drive 1

I have also checked ahandful of copy jobs preceding this job and there vchanger was loading the correct volumes.

1) Why might this happen? 
2) Could this be a misconfiguration on my end? What might be wrongly configured?
3) Is there anything I can do about it?

[Vchanger-users] Hidden limit of 600 volumes

From: Justin C. <jus...@gm...> - 2023-10-24 14:09:50

Hi there, there seems to be a hidden limit of vchanger being able to register more then 600 volumes with bacula’s Scratch pool.
My Scratch pool has MaximumVolumes set to 0 (and I also tried it with 1800), so that should not be the limit vchanger is running into.

Any ideas which limit is capping the number of volumes that vchanger can register in the Scratch pool to 600?

ATB
 JC

Re: [Vchanger-users] bacula requesting nonexistent slots

From: Josh F. <jf...@ja...> - 2023-08-11 13:04:49

On 8/10/23 14:05, Steven A. Falco wrote:
> On 8/10/23 11:19 AM, Josh Fisher wrote:
>> ...
>
> I've checked the log, and I had one instance of:
>
> Aug 09 09:49:09:  [12299]: WARNING! 'update slots' needed in bconsole
> Aug 09 09:49:09:  [12299]: bconsole update slots command success
>
> But after doing the manual "update slots", I don't see any more 
> warnings.  I don't know why bconsole couldn't be run that one time, 
> but I'll keep an eye on it.  Maybe I issued it as an unprivileged user 
> rather than as root.


Maybe. If it persists, then set leg_level = LOG_DEBUG, which will log 
much more detail about the bconsole calls and their return codes. It 
should help determine why the bconsole calls fail.


>
> As an aside, looking at bconsole.cpp I'm surprised that the "success" 
> message would be printed along with the WARNING line. It might be 
> clearer to have the "success" line in an else clause, like:
>
>    if (update_slots) {
>       tFormat(cmd, "update slots storage=\"%s\" drive=\"0\"", 
> conf.storage_name.c_str());
>       if(issue_bconsole_command(cmd.c_str())) {
>          vlog.Error("WARNING! 'update slots' needed in bconsole");
>       } else {
>          vlog.Info("bconsole update slots command success");
>       }
>    }
>
> The same would be true of the label_barcodes a few lines later in the 
> file.


It is supposed to be in an elf clause. That is a bug. Thanks. I'll fix it.


>
> I've also attached a trivial patch, because when reading the log I 
> noticed that there is a typo which I fixed via 
> s/preforming/performing/ in vchanger.cpp (around lines 638-672).
>
>     Thanks for the rapid response!
>     Steve


Thanks for the patch! I've never noticed. I guess my brain 
auto-corrected it.

Re: [Vchanger-users] bacula requesting nonexistent slots

From: Steven A. F. <ste...@gm...> - 2023-08-10 18:05:35

Attachments: commit-c0331b6

On 8/10/23 11:19 AM, Josh Fisher wrote:
> On 8/10/23 09:51, Steven A. Falco wrote:
>> I've had a working setup for years, but suddenly I'm getting errors:
>>
>> Fatal error: 3992 Bad autochanger "load Volume v1_0005_0197 Slot 412, Drive 0": ERR=Child exited with code 1.
>> Results=cannot load drive 0 from invalid slot 412
>>
>> bacula indeed thinks the volume is in slot 412, according to the "list media" command:
>>
>>  1,501 | v1_0005_0197 | Append    |       1 | 23,539,407,831 | 5 |    3,628,800 |       1 |  412 |         1 | File |       1 |        0 | 2023-08-09 00:54:13 | 3,511,018 |
>>
>> I tried doing "vchanger /etc/vchanger/v1.conf REFRESH" which I thought would update bacula's inventory of the slots, but that doesn't seem effective.
>>
>> If I ask vchanger what it has, using "vchanger /etc/vchanger/v1.conf LIST", I get:
>>
>> 198:v1_0005_0197
>>
>> so vchanger thinks the volume is in slot 198.
>>
>> I was able to get bacula to correct its slots via "update slots", and things are working again, but I'd like to understand how the slots/volumes might have gotten out of sync.  Any thoughts on that would be appreciated.
>>
>> Also, is the "update slots" command the right way to recover?
> 
> 
> Yes, 'update slots' is the right way. It gets out of sync every time a filesystem (virtual magazine), say a removable drive, is attached or detached from the system. Vchanger assigns that filesystem's volume files to slots in the order that they are attached. Once a filesystem is detached, the slots it occupied may be reused. Regardless, when it is again attached, it is likely to be assigned different to a different set of slots.
> 
> Ordinarily, vchanger calls out to Bacula via its bconsole command when it detects a change in occupied slots. The REFRESH command simply triggers vchanger to check for slot changes and initiate a sync if needed. The sync is simply a call to bconsole to issue an 'update slots' command.
> 
> So, you need to somehow initiate an 'update slots' command whenever a filesystem is attached or detached. You can call vchanger with the REFRESH command, you can go into bconsole and issue it directly, or you can use udev rules to cause udev to automatically launch vchanger with the REFRESH command whenever a filesystem assigned to vchanger is physically attached or detached.
> 
> To use udev, there is a script (usually) installed at /usr/bin/vchanger-genudevrules that can be used to generate the udev rules by scanning the magazine= lines in the vchanger config file. Whenever a new filesystem is added or removed from the vchanger config file, those udev rules need to be regenerated  It should be used to update a udev rules file, usually in /etc/udev/rules.d. I have mine in /etc/udev/rules.d/96-vchanger.rules.
> 
> If the REFRESH command does not seem to actually change the slot number in Bacula, then something is preventing vchanger from launching the bconsole command. Check the vchanger config file. There is a bconsole= parameter that defaults to "bconsole". If the bconsole parameter is empty/blank, then vchanger will log that the update slots is needed, but will not actually call bconsole. Otherwise, if bconsole is not installed in a directory in the PATH environment variable, then it won't find the bconsole binary. Otherwise, there could be a permissions problem. Set log_level = LOG_DEBUG in the vchanger config to get very detailed logging of the process, which should show where it is failing.
> 
> 

I've checked the log, and I had one instance of:

Aug 09 09:49:09:  [12299]: WARNING! 'update slots' needed in bconsole
Aug 09 09:49:09:  [12299]: bconsole update slots command success

But after doing the manual "update slots", I don't see any more warnings.  I don't know why bconsole couldn't be run that one time, but I'll keep an eye on it.  Maybe I issued it as an unprivileged user rather than as root.

As an aside, looking at bconsole.cpp I'm surprised that the "success" message would be printed along with the WARNING line.  It might be clearer to have the "success" line in an else clause, like:

    if (update_slots) {
       tFormat(cmd, "update slots storage=\"%s\" drive=\"0\"", conf.storage_name.c_str());
       if(issue_bconsole_command(cmd.c_str())) {
          vlog.Error("WARNING! 'update slots' needed in bconsole");
       } else {
          vlog.Info("bconsole update slots command success");
       }
    }

The same would be true of the label_barcodes a few lines later in the file.

I've also attached a trivial patch, because when reading the log I noticed that there is a typo which I fixed via s/preforming/performing/ in vchanger.cpp (around lines 638-672).

	Thanks for the rapid response!
	Steve

Re: [Vchanger-users] bacula requesting nonexistent slots

From: Josh F. <jf...@ja...> - 2023-08-10 15:36:06

On 8/10/23 09:51, Steven A. Falco wrote:
> I've had a working setup for years, but suddenly I'm getting errors:
>
> Fatal error: 3992 Bad autochanger "load Volume v1_0005_0197 Slot 412, 
> Drive 0": ERR=Child exited with code 1.
> Results=cannot load drive 0 from invalid slot 412
>
> bacula indeed thinks the volume is in slot 412, according to the "list 
> media" command:
>
>  1,501 | v1_0005_0197 | Append    |       1 | 23,539,407,831 |        
> 5 |    3,628,800 |       1 |  412 |         1 | File |       1 
> |        0 | 2023-08-09 00:54:13 | 3,511,018 |
>
> I tried doing "vchanger /etc/vchanger/v1.conf REFRESH" which I thought 
> would update bacula's inventory of the slots, but that doesn't seem 
> effective.
>
> If I ask vchanger what it has, using "vchanger /etc/vchanger/v1.conf 
> LIST", I get:
>
> 198:v1_0005_0197
>
> so vchanger thinks the volume is in slot 198.
>
> I was able to get bacula to correct its slots via "update slots", and 
> things are working again, but I'd like to understand how the 
> slots/volumes might have gotten out of sync.  Any thoughts on that 
> would be appreciated.
>
> Also, is the "update slots" command the right way to recover?

Yes, 'update slots' is the right way. It gets out of sync every time a 
filesystem (virtual magazine), say a removable drive, is attached or 
detached from the system. Vchanger assigns that filesystem's volume 
files to slots in the order that they are attached. Once a filesystem is 
detached, the slots it occupied may be reused. Regardless, when it is 
again attached, it is likely to be assigned different to a different set 
of slots.

Ordinarily, vchanger calls out to Bacula via its bconsole command when 
it detects a change in occupied slots. The REFRESH command simply 
triggers vchanger to check for slot changes and initiate a sync if 
needed. The sync is simply a call to bconsole to issue an 'update slots' 
command.

So, you need to somehow initiate an 'update slots' command whenever a 
filesystem is attached or detached. You can call vchanger with the 
REFRESH command, you can go into bconsole and issue it directly, or you 
can use udev rules to cause udev to automatically launch vchanger with 
the REFRESH command whenever a filesystem assigned to vchanger is 
physically attached or detached.

To use udev, there is a script (usually) installed at 
/usr/bin/vchanger-genudevrules that can be used to generate the udev 
rules by scanning the magazine= lines in the vchanger config file. 
Whenever a new filesystem is added or removed from the vchanger config 
file, those udev rules need to be regenerated  It should be used to 
update a udev rules file, usually in /etc/udev/rules.d. I have mine in 
/etc/udev/rules.d/96-vchanger.rules.

If the REFRESH command does not seem to actually change the slot number 
in Bacula, then something is preventing vchanger from launching the 
bconsole command. Check the vchanger config file. There is a bconsole= 
parameter that defaults to "bconsole". If the bconsole parameter is 
empty/blank, then vchanger will log that the update slots is needed, but 
will not actually call bconsole. Otherwise, if bconsole is not installed 
in a directory in the PATH environment variable, then it won't find the 
bconsole binary. Otherwise, there could be a permissions problem. Set 
log_level = LOG_DEBUG in the vchanger config to get very detailed 
logging of the process, which should show where it is failing.

[Vchanger-users] bacula requesting nonexistent slots

From: Steven A. F. <ste...@gm...> - 2023-08-10 14:02:35

I've had a working setup for years, but suddenly I'm getting errors:

Fatal error: 3992 Bad autochanger "load Volume v1_0005_0197 Slot 412, Drive 0": ERR=Child exited with code 1.
Results=cannot load drive 0 from invalid slot 412

bacula indeed thinks the volume is in slot 412, according to the "list media" command:

  1,501 | v1_0005_0197 | Append    |       1 | 23,539,407,831 |        5 |    3,628,800 |       1 |  412 |         1 | File      |       1 |        0 | 2023-08-09 00:54:13 | 3,511,018 |

I tried doing "vchanger /etc/vchanger/v1.conf REFRESH" which I thought would update bacula's inventory of the slots, but that doesn't seem effective.

If I ask vchanger what it has, using "vchanger /etc/vchanger/v1.conf LIST", I get:

198:v1_0005_0197

so vchanger thinks the volume is in slot 198.

I was able to get bacula to correct its slots via "update slots", and things are working again, but I'd like to understand how the slots/volumes might have gotten out of sync.  Any thoughts on that would be appreciated.

Also, is the "update slots" command the right way to recover?

     Steve