Compiling a new RHEL-4 kernel

[Tom Callahan]

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 at tessco.com

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
>  
>