Anyone used an Ecrix Autopak?

[Chris St. Pierre]

The latest update: I've solved the hardware problems, but still can't
get a good dump.  (Keep your snide jokes to yourselves. :)  I can
manipulate the changer just fine, loading and unloading all day long.
However, I get "Invalid argument" errors when I try to run dump:

# dump -cj -f /dev/st0 -F '/usr/local/sbin/mtx -f /dev/sg1 next' /etc
  DUMP: Date of this level  dump: Tue Jun 14 07:39:16 2005
  DUMP: Dumping /dev/cciss/c0d0p1 (/ (dir etc)) to /dev/st0
  DUMP: Label: /
  DUMP: Writing 10 Kilobyte records
  DUMP: Compressing output at compression level 2 (bzlib)
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 14613 blocks on 0.84 tape(s).
  DUMP: Volume 1 started with block 1 at: Tue Jun 14 07:39:18 2005
  DUMP: write error 30 blocks into volume 1: Invalid argument
  DUMP: Do you want to rewrite this volume?: ("yes" or "no")

If I answer yes, it changes to the next tape and gives the same
error.  If I answer "no," it aborts the dump.  I tried erasing a tape
with 'mt -f /dev/st0 erase' and the process hung and wouldn't respond
to kill -9.  Basically, it seems that anything that manipulates
/dev/sg1 (the library device) works, but things that manipulate
/dev/st0 (the tape drive device) don't.  The status of the tape drive
seems fine, though:

# mt -f /dev/st0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 1024 bytes. Density code 0x80 (DLT 15GB uncomp. or
Ecrix).
Soft error count since last status=0
General status bits on (41010000):
 BOT ONLINE IM_REP_EN

Any ideas?

Chris St. Pierre
Unix Systems Administrator
Nebraska Wesleyan University

On Thu, 9 Jun 2005, Chris St. Pierre wrote:

>It turns out the SCSI ID of the changer was in conflict with something
>else, so it wasn't detecting it.  I changed the ID and it detected it,
>so that worked.  Running status on the drive, though, still didn't
>work, until I read this: 
>
>http://mtx.badtux.net/faq.html
>
>Apparently, 'status' is a robotic command, and can't be run on a
>drive, so it's a *good* thing it didn't work.
>
>I still haven't been able to do a successful dump, though, and now I'm
>having hardware problems with the drive.  Thanks for your help.  I may
>be resurrecting this thread when I get my hardware problems sorted out.
>
>Chris St. Pierre
>Unix Systems Administrator
>Nebraska Wesleyan University
>
>On Wed, 8 Jun 2005, Jay LaPrade wrote:
>
>>"That doesn't work, either.  All of the mtx commands
>>give the same
>>error as `mtx -f /dev/sg0 status` (below), including
>>load."
>>
>>A few things to check for:
>>
>>1)  Is the library Attached?
>>
>>dmesg | grep Attached
>>
>>This should return something like the following:
>>
>>Attached scsi tape st0 at scsi0, channel 0, id 1, lun
>>0
>>Attached scsi generic sg0 at scsi0, channel 0, id 0,
>>lun 0,  type 8
>>
>>Type 8 is a library device
>>
>>2)  Check your SCSI ID's
>>
>>In general I prefer to set the library to SCSI ID 0
>>and the tape drives to the next numbers,  so Tape
>>Drive 1 might be SCSI ID 1
>>
>>3)  Make sure you are not using luns.  Last time I
>>checked RH 3 does not have multiple lun support
>>compiled into the kernel
>>
>>4)  Do not have the tape library connected to a
>>MegaRAID or any other SCSI RAID adapter,  Use an
>>independant SCSI card
>>
>>5)  If for some reason 1) does not work,  you may be
>>able to modprobe sg and that will find it.  I have
>>seen cases where /etc/hotplug/scsi.agent has an
>>incorrect spelling for the MODULES name for sg.  I
>>believe it was spelled MOUDLES.  
>>
>> 
>>
>>__________________________________________________
>>Do You Yahoo!?
>>Tired of spam?  Yahoo! Mail has the best spam protection around 
>>http://mail.yahoo.com 
>>
>>-- 
>>redhat-list mailing list
>>unsubscribe mailto:redhat-list-request at redhat.com?subject=unsubscribe
>>https://www.redhat.com/mailman/listinfo/redhat-list
>>
>
>-- 
>redhat-list mailing list
>unsubscribe mailto:redhat-list-request at redhat.com?subject=unsubscribe
>https://www.redhat.com/mailman/listinfo/redhat-list
>