Very strange.... How many drives are in your robot? The changer itself is not really a device that would be seen by a scsi lun probe, you should see three luns if you have 2 drives for instance. We have an HP MSL5026 here, along with a 5052, and with the 5026, I see the robot as /dev/sg1 and the drives individually as /dev/sg2, and sg3. The 5052 is the same way, but two more drives as /dev/sg4 and sg5 What brand/model of robot are you using, and if possible, can you give me the output of lssg (part of fibreutils package) or /proc/scsi/scsi?? I'm pretty sure this should work out of the box. I've never had problems otherwise..... Thanks, Tom Callahan TESSCO Technologies (443)-506-6216 callahant@xxxxxxxxxx A real engineer only resorts to documentation when the keyboard dents on the forehead get too noticeable. Simon wrote: > > On Dec 20, 2005, at 6:25 AM, Tom Callahan wrote: > >> First off, this will void your support contract. But to get the kernel >> sources, read the RHEL4 release notes available on redhat's site. >> >> As far as your tape changer issue, verify that sg5 is indeed your >> changer and not an individual tape device. Once you have verified that, >> create a symlink /dev/changer -> /dev/sg5 >> >> `mtx status` should then show you stats about your changer. > > > The problem is that both robot and changer are set to /dev/sg5 - the > device uses different LUNs to distinguish and RHEL is set up to not > scan for different LUNs per SCSI device by default :-( > > I get an ok response from the command: > > mtx -f /dev/sg5 inquiry > > ... but > > mtx -f /dev/sg5 status > > ... fails miserably. > >> NOTE: /dev/st0 will rewind the tape after each write, /dev/nst0 will >> not, I recommend if using a tape for backup, that you use /dev/ nst0, >> and >> then manually issue a rewind at the end of the backup functions. This >> prevents you from inadvertantly overwriting previously backup up data. > > > Yeah, I know - the tape is ~400GB (an Ultrium-3), so the backup > (~250GB) fits on fine, and there are 8 tapes in the device. At the > moment, the service people are using the front-panel controls to > manually switch tapes on a day-by-day basis. This gives us a rolling > backup for a week. When I get the tape robot working properly, I'll > start writing scripts to do both full and incremental backups and > load/unload tapes on-demand... > > A new (clone) server will appear in the next few days, so I'm going > to wait until that arrives before fiddling with kernel parameters > (I'd rather test hardware on the machine that *isn't* serving a few > hundred websites [grin]) > > Thanks for the help though :-) > > ATB, > Simon > > -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
