tar: cannot open /dev/rmt/0m

[Brad Beard]

I'm using the following command to try to back up an entire directory:
tar -cvf /dev/rmt/0m .

This has been working for a long time, but a new motherboard was installed yesterday and that's when this command stopped working. I have tried the following command with no luck:
insf -e

Also, when I issue the following command I get nothing back (it does not recognize it even has a tape drive, but the directory and file are there - /dev/rmt/0m):
ioscan -fnC tape

Thanks for your help.

[Rick Garland]

Does SAM show the tape device? You may need to re-initialize it via SAM (would be the easiest way)

How about ioscan - does it show in there?

Could the device have been moved to another name?

[Alan Riggs]

You may have a more serious problem than tar, if insf does not return. I'm not clear from your post whether ioscan -fn returns properly or not. If it does return, then try removing all files attached to that device and runnine insf -H . It is always better to specify rather than run insf -e unless you are in single user mode, anyway.

[Brad Beard]

SAM does not show the tape drive. ioscan -fn works correctly, but it does not see the tape drive. The tape drive has power (I can insert and eject tapes), but it just isn't recognized at all. I don't believe it would have been renamed. A new motherboard was installed yesterday and we didn't change any names. It's possible that maybe it wasn't hooked up correctly after the motherboard installation. It does have power though - I'm assuming there's another wire that has to be hooked up as well. I appreciate your responses. Any other suggestions? Thanks.

[Alan Riggs · Accepted solution]

Is the drive internal? If so, does ioscan show anything on that path at all? It sounds like you might have a connection problem to th enew motherboard.

[James R. Ferguson]

Brad:

I had a similar problem recently. The SCSI cable to the tape drive may have disconnected or the tape drive itself may be defective. In my case, too, I could insert and eject tapes. A key sympton was the absence of any tape from ioscan. I suggest re-seating or replacing the tape drive.

...JRF...

[Brad Beard]

The tape drive is internal. How can I find the hardware path to see if ioscan works on that path? I'm going to have to check the internal connection to the motherboard, but I can't take the box down right now. Thanks for your help.

[James R. Ferguson]

Brad:

Ah, the wonderful properties of internal tape drives (not!). I realize that you have to down the box. I suspect that there's nothing wrong with ioscan nor the SCSI path; only the tape drive or the connection to it. You might get the warm fuzzy your looking for by doing an ioscan to your CDROM drive since it's probably on the same path.

...JRF...

[Ruediger Noack]

Hi Brad,

after changing the motherboard the hardware path to tape drive shouldn't be changed. So you can find out the path with
lssf /dev/rmt/0m.
Now you can recreate the device file with
insf -H (see above).

Hope this helps

Ruediger

[Brad Beard]

when I ran the lssf /dev/rmt/0m command, I received the following output:

stape card instance 1 SCSI target 0 SCSI LUN 0 at&t best destiny available at address ??? /dev/rmt/0m

[Alan Riggs]

Brad -- the SCSI path depends upon the hardware. On a K serer the internal tape is 10/12/5.0.0. On a D: 8/16/5.0.0. What you can look for in an ioscan is:

x/x Core I/O Adapter
x/x/0 Built-in Parallel Interface
x/x/5 Built-in SCSI
x/x/5.0 (no label -- driver = tgt)
x/x/5.0.0 [YOUR TAE DEVICE]
x/x/5.2 (no label -- driver = tgt)
x/x/5.2.0 [YOUR CD-ROM]
x/x/5.7 (no label -- driver = tgt)
x/x/5.7.0 Initiator


If your display in ioscan -fn does not match this pattern (assuming a tape and a CD on teh internal SCSI) then you almost certainly have a seating problem with the internal tape drive. I would have whatever tech installed the motherboard for you come back to reseat (or replace) the internal tape drive.

[Brad Beard]

I appreciate all of your help. It appears that there is definitely an internal connection problem after trying all of the commands listed above. I have contacted the person who installed the motherboard and he is going to come back to take a look. Again, thanks everyone for your help.

[Bill Hassell]

Brian wrote:

"when I ran the lssf /dev/rmt/0m command, I received the following output:

stape card instance 1 SCSI target 0 SCSI LUN 0 at&t best destiny available at address ??? /dev/rmt/0m"

The ??? is intersting. It looks like the hardware path is invalid, which in HP-UX is translated from an instance number into a full hardware path inside the kernel. Try this:

rm -H 12/3.4.5.0

where 12/3.4.5.0 is replaced with the actual hardware path of the tape drive. This will remove the device files as well as the instance number from the kernel's memory.

Now check to see that /dev/rmt/0m is gone too (use lssf /dev/rmt/* to see all the tape devices). If it is still there but all device files assigned to the problem hardware address are gone, you can then remove /dev/rmt/0m by hand (nad any others that weren't removed by rmsf)

Now recreate the device files with:

insf -H 12/3.4.5.0

(again, replace 12/3.4.5.0 with your real hw path) and use lssf again to make sure there are device files assigned to this hardware address. If so, make sure 0m belongs to the hw address too...if it does not exist, you can either create a link between a correct device file and the 0m file, or simply duplicate the device file with mknod using the same major/minor numbers found in an ls -l listing of /dev/rmt/*.

Now try:

mt -t rew

(there must be a tape installed). If the tape is writable, try:

mt -t status

If these return correctly, tar should work like a champ.