Problem in Internal tape Drive of Netra 20
hi everybody,
I am getting a problem with internal tape drive.
My Netra 20 Server having Solaris 8 in it is online and is busy, and I am unable to shutdown. When I tried to take a backup in tape, error message displayed
"No such Devices or Address"
I went to /dev/rmt directory and deleted everything then ran devfsadm but still get same error.
Can any one of you answer how can I debug what is the problem in tape without shutting down the system, nor taking it to OBP.
Here, is the work I had done.
uid=0(root) gid=1(other)
<a href="mailto:root@scp1" target="_blank">root@scp1</a> # devfsadm
<a href="mailto:root@scp1" target="_blank">root@scp1</a> # mt stat
/dev/rmt/0n: No such device or address
<a href="mailto:root@scp1" target="_blank">root@scp1</a> # exit
Thanking you
[944 byte] By [
Bikash] at [2007-11-25 22:46:27]
# 1
Your backup driver can have another target number. Have u check the files under /dev/rmt
first of all delete all the files under /dev/rmt then run devfsadm -vC
and check the files under /dev/rmt.
ls -l /dev/rmt/*
there if u see files such as 1n, 1, 1cbn this means that your backup drivers target 5 and u can access it as mt -f /dev/rmt/1n status.
hope this will solve your problem.
if u can not see any files check the cable.
orkut at 2007-7-5 17:01:49 >
# 2
Orkut:
This original post was eight months ago and they've never returned to any of the Sun-hosted forums, not hardware nor software.The system has probably been repaired.
--
I don't think your guess that tape drive 0 is target 4 and drive 1 is target 5 would always be true.
Perhaps others can jump in here, but I was always under the impression that tape drive 0 was the first one configured to a system, no matter what the path, drive 1 would be the second tape device, no matter what the path, and so on.
There could be circumstances whereby there is an internal DAT drive on its controller's target 4 then later there is an external tape unipak on its own target 4, etc, etc, etc.
I guess all I'm saying is that the investigation should follow device paths and not the contents of the /dev/rmt folder.
Bill at 2007-7-5 17:01:49 >
