First I would like to thank the following people for their quick response.
alan_at_nabeth.cxo.dec.com
Chris Ruhnke
Miguel Fliguer
Dr. Tom Blinn
They basically all gave me ways to not only recreate the device special
files for
the tape libraries but some also helped me determine what the device names
should
be. The following a summary or their responses to my problem which is at
the end.
============================================================================
====
>From Chris Ruhnke
> [snip]
>
> Nov 6 09:44:26 shelly vmunix: tz25 at scsi3 target 1 lun 0 (LID=35)
> (EXABYTE EXB-85058SQANXR1 07T0)
> Nov 6 09:44:26 shelly vmunix: tz26 at scsi3 target 2 lun 0 (LID=36)
> (EXABYTE EXB-85058SQANXR1 0781)
> Nov 7 20:04:32 shelly vmunix: tz24 at scsi3 target 0 lun 0 (LID=35)
> (EXABYTE EXB-85058SQANXR1 07T0)
> Nov 7 20:04:32 shelly vmunix: tz26 at scsi3 target 2 lun 0 (LID=37)
> (EXABYTE EXB-85058SQANXR1 0781)
>
Calvin,
AHA! Comes the dawn... This is kinda what I meant about being "truthful"
about the SCSI addresses.
You've got to remember that within DUNIX the device address for a SCSI
unit is calculated from both the SCSI adapter index and the SCSI target
address of the device itself. The general formula is:
8 * <SCSI adapter index> + <device target address>
^ ^
| |
| +--- device SCSI address
|
+---- 0 = 1st SCSI adapter
1 = 2nd SCSI adapter
2 = 3rd SCSI adapter
... and so on.
>From the above it appears that you tape drives are connected to the
fourth SCSI adapter on your system (<adapter index> = 3, counting from 0).
Thus your "new" tape devices will be "tz24" (<device target> = 0) and
"tz26" (<device target> = 2).
One more time... "rm" the /dev/*mt* definitiions and then
MAKEDEV tz24 tz26
=========================================================================
>From Miguel Fliguer
>>>"./MAKEDEV tz1 tz2". The device special files were created but now I
still
>>>can not access the drives, even using tapex, "Cannot open /dev/rmt0h".
>>>The SCSI id's of the tape drive/libraries are [drive:0/lib:1] and
>>>[drive:2/lib:3].
>>>Doing a "file /dev/rmt0h" returns "/dev/rmt0h: character special
>>>(9/39938)".
Mmmmmmmhhhh....Please do a :
# grep tz /var/adm/messages
and look for your tape, i.e a line like :
Dec 1 12:11:57 zappa vmunix: tz13 at scsi1 target 5 lun 0 (LID=3) (DEC
TZ87 (C) DEC 9A28)
Since a 'file' command failed to identify the unit, chances are that you are
MAKEDEVing the wrong device....
==== Response #2 =====
# MAKEDEV tz24
# MAKEDEV tz25
# MAKEDEV tz26
instead of
# MAKEDEV tz1
# MAKEDEV tz2
Otherwise your major and minor numbers will be pointing
to non-existent devices.
Remove your rmt and nrmt devices from /dev before doing it,
to force it to begin at rmt0. Then do a
# file /dev/rmt0h
# file /dev/rmt1h
# file /dev/rmt2h
to see if the tapes are correctly identified. Let me know
how it went.
===============================================================================
>From Dr. Tom Blinn
Why do you believe that the drives are tz1 and tz2? That would imply that
they are SCSI ids 1 and 2 on the primary SCSI bus.
When you are at the console firmware prompt, and do a "show dev", what does
the console firmware report for the devices? It is often a useful tool for
diagnosing problems.
When you boot the /genvmunix kernel and do a "sizer -n testunix" what shows
up in /tmp/testunix.devs for the "tz" device IDs? That is a really good way
to find out what the kernel thinks the devices are called without running the
doconfig script to build a new kernel.
Once you have the RIGHT 'tz' SCSI ids, then you can do the MAKEDEV to create
the rmt names. If you have the right device names, then when you do the file
command, you'll see the tape devices. If you don't, something is broken.
===============================================================================
>From alan_at_nabeth.cxo.dec.com
First, you don't need to rebuild the kernel to add SCSI
devices to an existing, recognized controller.
Use the scu(8) command to see what devices are on each
bus of the system. The command:
scu show edt
will show all the devices the system currently knows
about. You can "scan edt" to look for new devices.
You can limit the search to tapes by using grep:
scu show edt | grep Seq
If the driver can see the tapes you're in good shape.
To create the special files for them, you need the
bus and target number:
# = (bus * 8) + target
Then you can confirm that you're using MAKEDEV correctly:
./MAKEDEV tz#
If scu(8) can't see the device, shut down the system
when convient and see what the system console has to
say about things. A "show device" should be enough
to find the tape drives.
In general be careful that you don't duplicate IDs on
a bus and properly terminated the bus.
============================================================================
======
Original Message:
I am currently having a problem accessing my tape drives most likely due to
some actions taken by me.
I have two Exabyte 10h tape libraries connected via an KZPAA to a 4100. These
drives were previously used on a 2100A running OpenVMS and worked fine. After
connecting them to the 4100 and rebuilding the kernel I could access the drives
but only use one successfully. I use vdump to do backups to this drive.
In preparing to install Digital NetWorker 5.2 I deleted the NSR (single server)
directory tree as was recommended in the installation doc. But before I could
install the NetWorker software it was discovered that the wrong license was
shipped (correction being worked).
Now I can't write to the drive that was working. I get the same error as the
other drive gives "[5] err". As they were now not working, I took this time
to change the SCSI id's of the drives/libraries, powered down the libraries,
removed the device special files rmt* and nrmt*, and then recreated them using
"./MAKEDEV tz1 tz2". The device special files were created but now I still
can not access the drives, even using tapex, "Cannot open /dev/rmt0h".
How should I recover from this mess I got myself into?
The SCSI id's of the tape drive/libraries are [drive:0/lib:1] and
[drive:2/lib:3].
Doing a "file /dev/rmt0h" returns "/dev/rmt0h: character special
(9/39938)".
The OS is DUNIX 4.0D with jumbo patch #2.
Did I delete some required files when I deleted the Single Server directory?
===============================================================================
Thanks to all again,
-Calvin
Out the 10Base-T, through the router, down the T1, over the leased line,
off the bridge, past the firewall...nothing but Net.
-unknown
::::::::::::::::::::::::::::::::::::::::::::::::::::::
: Calvin J. Meadows : UNIX/VMS :
: : Systems Administrator :
: : Information Systems :
:----------------------------------------------------:
: E-Mail: cmeadows_at_smith.edu :
::::::::::::::::::::::::::::::::::::::::::::::::::::::
Received on Tue Dec 15 1998 - 13:49:31 NZDT