Can't write LIF to tape

[Jacob Levin]

the exact error is:
ERROR: /usr/bin/dd if=/var/tmp/uxinstlf.recovery of=/dev/rmt/1mn bs=2k failed to write LIF onto tape.

I read through a number of threads on this same error but haven't found the answer to my problem. I've connected 3 different scsi DAT4 drives to this RP8400 with no luck for this particular vpar. The other 3 partitions can read and write to the tape drive attached to them. The output from an ioscan is here:

Class I H/W Path Driver S/W State H/W Type Description
=======================================================================
tape 1 0/0/1/0/1.5.0 stape CLAIMED DEVICE HP C5683A
/dev/rmt/1m /dev/rmt/c1t5d0BESTn
/dev/rmt/1mb /dev/rmt/c1t5d0BESTnb
/dev/rmt/1mn /dev/rmt/c1t5d0DDS
/dev/rmt/1mnb /dev/rmt/c1t5d0DDSb
/dev/rmt/c1t5d0BEST /dev/rmt/c1t5d0DDSn
/dev/rmt/c1t5d0BESTb /dev/rmt/c1t5d0DDSnb

tar also fails when writing to the tape with the error:
Tar: end of tape
Tar: to continue, enter device/file name when ready or null string to quit.

User entered a null name for next device file.

I tried to tar an 8MB file to a tape that I rewound first. I'm left with thinking my scis card is bad. It's an A6829A Dual Ultra160 Adapters. The top port is connected to an HP2110 disk array and works fine. Ignite appears to not have worked for a very long time on this server. I upgraded to version C.7.3.148 after I uninstalled C.6.0.109

[Patrick Wallek]

The fact that the tape drive is showing up in ioscan tells me that things are kind of working.

You've tried different tape drives. That's a good start.

Have you tried different tapes? If not, try a brand new one?

Have you tried a different cable and terminator? If not, do that next.

If things are still not working, the particular port on the SCSI card may be your problem.

[Tim Nelson]

Default steps:
As you mentioned try to write some data to tape: i.e. tar, dd, cpio

if that does not work then Ignite is not going to work either.

replace tape and try again.
swap tape drive and try again
try tape drive on different server

if all of the above fail and the tape using works on a different server then you have either a cabling/termination issue or controller card issue.

Get a tape drive that works before worrying about Ignite.

[Jacob Levin]

Thanks guys for the quick response. I've tried multiple tapes including brand new ones, same error. Replaced scsi cables to no avail. I was able to, just now, tar single files to the tape.

wau022:/home/root> tar -cvf /dev/rmt/1mn ./tmpdf
a ./tmpdf 6 blocks
wau022:/home/root> mt -f /dev/rmt/1mn rewind
wau022:/home/root> tar -tvf /dev/rmt/1mn
rw-r----- 0/3 2858 Oct 19 06:00 2007 ./tmpdf

but I still can't run the dd command:

wau022:/home/root> /usr/bin/dd if=/var/tmp/uxinstlf.recovery of=/dev/rmt/1mn
I/O error
412+0 records in
411+1 records out
wau022:/home/root>

[john korterman]

Hi Jacob,

take a look at document id: KBRCKBRC00007576
in the tech base; perhaps it applies to your situation.

regards,
John K.

[Jacob Levin]

I would love to look at that document, but everytime I try to link a support agreement to my ID, I get "service is unavailable, please try later"

Can someone summarize that doc for me?

[Jacob Levin]

I was able to finally get a support agreement attached to my ID and look at the document. Unfortunately I already have over 200 MB free in var. any other ideas?

[Jacob Levin]

After extensive testing, it looks like I'm having a file size constraint issue with dd. I can't seem to put any file larger than ~25K to tape with the dd command, any ideas why?

[Shane Seymour]

You cannot write a LIF to tape like this:

# /usr/bin/dd if=/var/tmp/uxinstlf.recovery of=/dev/rmt/1mn

This is first and foremost not an Ignite-UX problem.

The problem here is two fold, he first problem your system firmware on any PA-RISC system will NOT be able to read back the contents of the LIF and it will not be bootable.

The second is that the default block size of dd is 512 bytes rather than the 2k required for a LIF and you've got an incomplete last block being written to tape and that failed and returned an I/O error (the tape drive will have a minimum block size and the dd command attempted to write less than that - the last block was probably not written to tape).

That is the normal behaviour of the dd command when dealing with devices. I cannot stress how important block sizes are and how important it is to get them correct when reading from or writing to device files (ever tried to recover a tar archive from tape written with a non-default block size without cheating and using pax to read it?).

When dealing with devices you have to understand and know what block sizes should be used (most important with tapes).

This probably will work:

# /usr/bin/dd if=/var/tmp/uxinstlf.recovery of=/dev/rmt/1mn bs=2k conv=sync

(although it probably would be better to replace bs=2k with ibs=2k obs=2k for reasons I won't go into sync we're using conv=sync to nul pad the last block if it's incomplete up to the correct block size)

[Jacob Levin]

Shane,

Thanks for your input however I did not arbitrarily pick those parameters, I took the line that was failing internally to the ignite process.

[Shane Seymour]

Can you explain where in the Ignite product it does this without an explicit block size. If it's incorrect I'll file a defect against it.

[Jacob Levin]

Shane,

The ignite was trying to do this:
the exact error is:
/usr/bin/dd if=/var/tmp/uxinstlf.recovery of=/dev/rmt/1mn bs=2k failed to write LIF onto tape

It errored everytime so I started playing with the dd command myself and I could not dd a file over a certain size no matter what blocksize I chose.

[Shane Seymour]

If you manually run these 3 commands:

/usr/bin/dd if=/var/tmp/uxinstlf.recovery of=/dev/rmt/1mn bs=2k
/usr/bin/dd if=/var/tmp/uxinstlf.recovery of=/dev/rmt/1mn bs=2k conv=sync
/usr/bin/dd if=/var/tmp/uxinstlf.recovery of=/dev/rmt/1mn ibs=2k obs=2k conv=sync

What results do you get?