Richard Scobie wrote:
Thanks for the followup, but after finding the thread referenced below
yesterday, I switch the SCSI HBA and library into another box (different
motherboard) and it is humming along fine using the same config files.
Granted this box is running Fedora 8, not Fedora 11
Humor me if you will. Go back to default. Make sure your tape drive is set
to variable blocks using mt -f /dev/nst0 setblk 0, then load a tape, and use
tapeinfo -f /dev/nst0 to verify it is set to zero. Now comment out the
Maximum Block Size from the sd. Test it with btape. Rewind it with mt,
Brian Debelius wrote:
Humor me if you will. Go back to default. Make sure your tape drive is
set to variable blocks using mt -f /dev/nst0 setblk 0, then load a tape,
and use tapeinfo -f /dev/nst0 to verify it is set to zero. Now comment
out the Maximum Block Size from the sd. Test it with
John Drescher wrote:
Have you tried to stop bacula-sd and then execute the mtx-changer
script directly from the shell? You will probably have to look at the
code for the parameters.
Hi John,
Yes, I have successfully been able to do this a number of times and also
run through the btape
Brian Debelius wrote:
Try turning on debug in mtx-changer. Modify the wait_for_drive()
function to add another debug statement to confirm that the device is
ready, and that the function did not just time out.
wait_for_drive() {
i=0
while [ $i -le 300 ]; do # Wait max 300 seconds
if mt -f
Thanks Brian, I added this and it seems to indicate things are working
OK without adding any sleep, so I need to keep looking.
The following is the sequence as I attempt to label a tape after having
deleted the Volume record, manually rewound the tape and done an mt -f
/dev/nst0 weof and
Hi Richard,
Anyone else running this library I can compare notes with?
Not anymore :) Used to use an SAS LTO3 based MSL2024 on a project I worked at
a while back. TBH it *just worked* and worked well too. Would recommend one to
anyone that needed an autochanger of this size. Was quick
Richard Scobie wrote:
You probably need to add a wait in the mtx-changer script just after
the load. This wait will make sure the tape is in the drive and has
completed the loading process. For some systems the script does not
wait long enough for the tape drive to finish.
John
ext-daniel.haw...@nokia.com wrote:
Hi Richard,
Anyone else running this library I can compare notes with?
Not anymore :) Used to use an SAS LTO3 based MSL2024 on a project I worked
at a while back. TBH it *just worked* and worked well too. Would recommend
one to anyone that needed an
Try turning on debug in mtx-changer. Modify the wait_for_drive()
function to add another debug statement to confirm that the device is
ready, and that the function did not just time out.
wait_for_drive() {
i=0
while [ $i -le 300 ]; do # Wait max 300 seconds
if mt -f $1 status 21 |
On Wed, Jan 6, 2010 at 5:16 PM, Richard Scobie rich...@sauce.co.nz wrote:
I have an MSL2024 library I have been battling to get running for the
last couple of days and am about out of ideas. It is the parallel SCSI
attached LTO-4 version, connected to an HP LSI based HBA.
I have bacula
You probably need to add a wait in the mtx-changer script just after
the load. This wait will make sure the tape is in the drive and has
completed the loading process. For some systems the script does not
wait long enough for the tape drive to finish.
John
Thanks John. I already have a 30
Richard Scobie wrote:
You probably need to add a wait in the mtx-changer script just after
the load. This wait will make sure the tape is in the drive and has
completed the loading process. For some systems the script does not
wait long enough for the tape drive to finish.
John
Thanks
13 matches
Mail list logo
