mt status reports 'nrmt0h: No such device or address'

[James Long_5]

I'm trying to boot an Alphaserver 800 5/500 using a Tru64 V4.0F installation CD to get to a shell prompt and "dd" some data from a Quantum DLT 15/30G tape onto the Alphaserver's RAID logical disk. The server does not otherwise boot due to a damaged root partition (see other thread). I have the tape drive powered and cabled, and 'scu show edt' sees it thus:

CAM Equipment Device Table (EDT) Information:

Device: RRD47 Bus: 0, Target: 4, Lun: 0, Type: Read-Only Direct Access
Device: DLT2000 15/30 GB Bus: 1, Target: 5, Lun: 0, Type: Sequential Access

From reading /dev/MAKEDEV, I inferred that the command I needed to make a tape device node was either:

./MAKEDEV tms0

or maybe

./MAKEDEV tz0

I tried the first, and set TAPE first to /dev/nrmt0h and later /dev/nrmt0l, but 'mt status' consistently returned 'nrmt0h: No such device or address' (or same for nrmt0l). I rm'ed the device nodes and tried the latter MAKDEV command (tz0) and got the same results when I tried to use mt status on nrmt0h, nrmt0l, nrmt0m, and nrmt0a.

Whats the proper incantation to create a functional tape device node that will allow me to operate the Quantum DLT drive using the mt and dd utilities?

Thank you!

Jim

[James Long_5]

I am not certain that this was indeed the solution, but after running 'scsimgr -scan_all' I now seem to have devices rmt1* which appear to talk to the drive. I am performing tests to determine how well /dev/nrmt1a works. I am dd'ing a file from tape to /dev/null, but so far it is running quite slowly -- over 30 minutes and counting to dd a 200 megabyte file.

I have /dev/rmt1a, h l and m -- what differences if any are there between these device nodes?

Thank you!

Jim

[Steven Schweda]

> [...] what differences [...]

Have you tried anything like?:

man mt

Density/compression, rewind, ...?

[James Long_5]

Thank you, Steven. The mt page (at least the one on the 4.0F install CD) describes mt(1) and does not mention anything about the suffix letters. However, a document I had found last night shed some light: "Troubleshooting tape/library drives under TRU64 UNIX" from http://www.dectrader.com/docs/set2/LTT-TRU64-TROUBLESHOOTING.pdf. That document described the suffix letters, and also gave me the clue I needed to create the device node with less futzing: watch the start-up probes closely, and when you see something like:

tz## at scsi1 target 5 lun 0

use the tz## in the MAKEDEV command. I'm coming from modern BSD, where MAKEDEV is no longer used, and devices generally get numbered sequentially from 0, based on their probe order, so the first device being tz13 didn't occur to me.

I'm also unclear whether the scsimgr command actually helped, or whether it was just coincident with something else I did. But knowing the precise device to MAKEDEV has solved my device node issues for now.

Thank you for replying!

[Steven Schweda]

> [...] I'm coming from modern BSD, [...]

And I haven't touched Tru64 pre-V5.0 (where,
I believe, the device naming scheme changed
some), so I know nothing.

> [...] devices generally get numbered
> sequentially from 0, based on their probe
> order, [...]

There's much to be said in favor of a scheme
where the name of a device does not change
when you add another device, I claim. I was
recently annoyed by some GNU/Linux system
where adding a disk left the boot disk
unbootable because all the stuff in its
/etc/fstab was rendered invalid because of
the device name changes.

[Pieter 't Hart]

It is not mt0 even if it is the first device configured
In Tru64 V4.0F the device must be adressed according to it's scsi id.

so most likely ./MAKEDEV tz5 (or tz15 as it is on bus-1) creates the device special files so the system can communicate with it.