Hi Kern,
15.10.2009 11:43, Kern Sibbald wrote:
> Hello Arno,
>
> Please open a bug report. There are two things that I would like to see:
That's gonna be a problem (as outlined in the original mail):
> 1. The exact sequence of commands that lead to the problem
I can not reproduce the problem
Hello Arno,
Please open a bug report. There are two things that I would like to see:
1. The exact sequence of commands that lead to the problem
2. Debug output set at say 400 on the SD during the period that mtx misbehaves
up to the point the SD blows it self up.
3. a traceback (stack dump) p
Hi Eric,
15.10.2009 09:40, Eric Bollengier wrote:
> Hello Arno,
>
> Le Thursday 15 October 2009 09:33:21 Arno Lehmann, vous avez écrit :
>> Hi,
>>
>> I just was presented with a SD failure in an assert.
>>
>> Backups were running, and I changed volumes on an autochanger. After
>> the new tapes we
Hello Arno,
Le Thursday 15 October 2009 09:33:21 Arno Lehmann, vous avez écrit :
> Hi,
>
> I just was presented with a SD failure in an assert.
>
> Backups were running, and I changed volumes on an autochanger. After
> the new tapes were loaded, I did the usualy 'update slots' ceremony:
>
> *updat
Hi,
I just was presented with a SD failure in an assert.
Backups were running, and I changed volumes on an autochanger. After
the new tapes were loaded, I did the usualy 'update slots' ceremony:
*update slots scan storage=QuantumDLT drive=0
Connecting to Storage daemon QuantumDLT at gnom:9103 .
