ignite make_tape_recovery cannot find tape drive

[Gregory Locke]

My primary DLT8000 drive failed/jammed with a tape stuck inside. Under contract, HP brought me another DLT8000. I shut the system down, matched SCSI ids, and replaced the defective tape drive with a new tape drive. Brought system back up. Tested drive-seems ok.

When performing an Ignite make_tape_recovery, it states that the drive does not exist. If I interactively use it, 0mn is not available. Attached is a normal output capture. Any help would be appreciated.

[Torsten.]

Hi,

the output of "ioscan -fn" and "ll /dev/rmt" would be helpful.

[A. Clay Stephenson]

Do an ioscan -C tape -fn and post the output. Also do an ls -l /dev/rmt/* and post that output.

I am not sure what "Tested drive-seems ok means". Does that mean that you tried a small tar, cpio, or dd and then tried a read back the image?

[Gregory Locke]

Here you are.

[Torsten.]

Look:

tape 0 0/1/1/1.5.0 stape CLAIMED DEVICE QUANTUM DLT8000
/dev/rmt/0m /dev/rmt/c3t5d0BESTb
/dev/rmt/0mb /dev/rmt/c3t5d0BESTn
/dev/rmt/0mnb /dev/rmt/c3t5d0BESTnb
/dev/rmt/c3t5d0BEST

and

crw-rw-rw- 2 bin bin 205 0x035000 Apr 26 10:00 0m
crw-rw-rw- 2 bin bin 205 0x035080 Feb 13 2005 0mb
crw-rw-rw- 2 bin bin 205 0x0350c0 Feb 13 2005 0mnb

0mn is missing!

Re-create the device files:

insf -eCtape and check if /dev/rmt/0mn is now there.

[Steven E. Protter]

Shalom,

Tape drive is present.

tape 2 0/1/1/1.4.0 stape CLAIMED DEVICE Quantum DLT4000
/dev/rmt/2m /dev/rmt/c3t4d0BEST
/dev/rmt/2mb /dev/rmt/c3t4d0BESTb
/dev/rmt/2mn /dev/rmt/c3t4d0BESTn
/dev/rmt/2mnb /dev/rmt/c3t4d0BESTnb
target 8 0/1/1/1.5 tgt CLAIMED DEVICE
tape 0 0/1/1/1.5.0 stape CLAIMED DEVICE QUANTUM DLT8000
/dev/rmt/0m /dev/rmt/c3t5d0BESTb
/dev/rmt/0mb /dev/rmt/c3t5d0BESTn
/dev/rmt/0mnb /dev/rmt/c3t5d0BESTnb
/dev/rmt/c3t5d0BEST

I'd suggest testing it with cstm/mstm or xstm to see if its working correctly.

It would also be very helpful to see the Ignite logs. Their location is displayed on screen when you do an ignite backup.

I'm assuming since a test drive worked, that the stape driver is installed in the kernel. If not,see sam kernel configuration drivers and prepare for a boot.

Note also that HP will not permit you to boot off any old tape driver. Generally those listed as certified for the hardware will work as boot devices. Beyond that though the tape may build, booting off it may be problemetic.

SEP

[A. Clay Stephenson · Accepted solution]

That silly box was telling you the truth. You are missing the "shorthand" version of the Omn device node.

mknod /dev/rmt/0mn c 205 0x035040

or use the insf command. The mknod command is safe in this case because the long form of the device node does exist.

[Gregory Locke]

Thanks to those who have help out so far. I did the
insf -eCtape and 0mn is now there.

Here is what I am now getting:
zeus:[/opt/ignite/bin] # make_tape_recovery
* Creating local directories for configuration files and archive.

======= 04/26/07 11:01:46 PDT Started make_tape_recovery. (Thu Apr 26
11:01:46 PDT 2007)
@(#) Ignite-UX Revision C.6.1.44
@(#) net_recovery (opt) $Revision: 10.672 $

* Testing for necessary pax patch.
* Passed pax tests.
* Checking Versions of Ignite-UX filesets
ERROR: Failed to open tape device /dev/rmt/0mn:No such device or address
(errno = 6).
ERROR: Check tape device failed.

======= 04/26/07 11:01:49 PDT make_tape_recovery completed unsuccessfully

[Patrick Wallek]

OK, is there actually a tape in the drive? Double check to make sure.

Now do a:

# mt -f /dev/rmt/0mn stat

and see what that return. It should return 'BOT' (Beginning Of Tape) and some other info. If it does not return that, then you need to check the tape drive.

You should also verify that something like a simple 'tar' command works.

# mt -f /dev/rmt/0mn rew
# tar -cvf /dev/rmt/0mn /tmp
# mt -f /dev/rmt/0mn rew
# tar -tvf /dev/rmt/0mn

That will write the contents of /tmp to the tape, rewind it, and then list what is on the tape. If that fails, you may need to check the drive itself again.

[Gregory Locke]

Well, the good news is that, thanks to all of you for helping out, 0mn is once again available to the make_tape_recovery utility. However, now that I am getting farther along, it still aborts with another problem. The latest recovery.log is attached. Please check it out.

Signed,
A little less desparate.

[Torsten.]

Your system stores configs about missing disks.

The message
"save_config: Error - unknown disk type for , not SCSI or HPFL"
let me assume about an old OS version.

What is your OS and ignite version?
Did you remove disks without exporting the VGs?

Tell us about the history...

If you have information stored like

/dev/vg03 directory but you don't have a vg03 now, ignite will complain...

[Gregory Locke]

No, no disk drives have been replaced. This worked fine last week. However, I did replace a tape drive on Saturday morning, with system powered off, same SCSI ID and channel. No users complaining, everything else appears OK.

Is there something that can be reset?

[Torsten.]

Your log says

/dev/dsk/c5t0d5
/dev/dsk/c7t0d5

are missing.

Check
ioscan -fn
strings /etc/lvmtab
(note the VG)
vgdisplay -v vg..

to find more information about the "missing" disks.

[Gregory Locke]

HP-9000 PA-RISC OS 11.23
HP-UX Ignite Revision C.6.1.44

[Gregory Locke]

Attached are the results of the commands suggested.

[Torsten.]

There is something wrong.

zeus:[/] strings /etc/lvmtab
/dev/vg00_bckup
/dev/dsk/c2t1d0
/dev/dsk/c2t0d0
/dev/dsk/c5t0d5
/dev/dsk/c7t0d5

The "missing" disks belong to vg00_bckup, but your vgdisplay shows only:

--- Physical volumes ---
PV Name /dev/dsk/c2t1d0
PV Name /dev/dsk/c2t0d0
PV Status available

The LUNS on your VA array are CLAIMED.

So try

vgchange -a y vg00_bckup
vgdisplay again.

any errors?

pvdisplay /dev/dsk/c5t0d5
lvdisplay -v /dev/vg00_bckup/lvol1

[Gregory Locke]

Here are the results of the commands.

[Steven E. Protter]

vgdisplay: Warning: couldn't query physical volume "/dev/dsk/c5t0d5":

Same deal for the alternate path to the same disk.

This disk is in the volume group but can't be accessed. strings /etc/lvmtab

You may need to:
mv /etc/lvmtab /etc/lvmtab.old
vgscan -a

Ignite will not make a backup of a system unless there is LVM consistency. As far as I can tell there is nothing wrong with the tape drive at this point.

You may be forced to run:
vgreduce -f

If so, follow the instructions after this command to insure you can run Ignite backups afterwards.

Before doing anything, you might want to do the following:
dmesg

grep -i lbolt /var/adm/syslog/syslog.log

mstm/cstm xstm check your hardware. There may indeed be a bad disk. If the disk is on a SAN(unlikely) check if the SAN admin has done something that should not have been done.

sEP

[Torsten.]

The devices

/dev/dsk/c5t0d5
/dev/dsk/c7t0d5

are LUN5 on your VA7410 array.
Check the array with

armdsp -a array_alias

for problems and proceed like SEP has suggested.