Omniback3.5 Linux media agent - errors

[Gregory Lee]

I'm testing the Linux media agent patch for OB3.5 (patch PHSS_24427 Id = JAGab70162).

I'm running RH7.1 on LC2000 with a DLT80k attached. I've confirmed that the tape drive can be detected but I'm having problems initializing the tape.

On the OB's /usr/omni/log/debug.log I get this:


01/21/02 17:15:01 MMA.766.0 ["/src/ma/dev/devseq.c /main/r31_split/r35_fix/24":
471] A.03.50 bPHSS_24427/PHSS_24428
ValidateOBMediumHeader-ERROR (/dev/st0): header is not an OmniBack header.
DevOpen (/dev/st0): device not found in seqTab: mt_type=114

Something abt not being a valid header? Any ideas?

Also on the OS itself:
Jan 21 17:10:02 sglx kernel: Attached scsi tape st0 at scsi1, channel 0, id 3, lun 0
Jan 21 17:14:48 sglx kernel: st0: Block limits 9216 - 13059108 bytes.
Jan 21 17:16:19 sglx kernel: st0: Write not multiple of tape block size.


The cell manager is HP-UX 10.2 and the cell manager software (on W2K). The software can tell that there is a tape in the drive but when trying to initialise, it says zero media found.

I've attached detailed error logs in the attachment incl. those reported by the cell manager.

Thanks.

[Alexander M. Ermes]

Hi there.
If you can do tar or cpio to that tapedrive,
you should reinstall it in OmniBack.
Try tar or cpio, then check OmniBack.
Rgds
Alexander M. Ermes

[Gregory Lee]

Do you mean try to see whether I can access the tape drive using cpio & tar?

[Mark Fenton]

precisely

[Gregory Lee]

For the tape drive:

# mt -f /dev/st0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 9012260 bytes. Density code 0x24 (DDS-2).
Soft error count since last status=0
General status bits on (41010000):
BOT ONLINE IM_REP_EN


When I try to use tar:

# tar cvfb 20 /dev/st0 /tmp/newrpm/
tar: /dev/st0: Invalid blocking factor


What does that mean?

Thanks

[Heiner E. Lennackers]

You should specify the arguments for your options in the same order as the options itself:
tar cvfb /dev/st0 20 should work.

Heiner

[Eric Ladner]

Try initializing the tape from inside OmniBack again, then do another backup. OB writes a tape identification header when it initializes a tape so it can keep track of them.

[Kodjo Agbenu]

Hello Gregory,

If I were you, at this point of the diagnostic I would try this : connect a DDS tape drive and see if it works well (with tar and/or with OmniBack).

If this is the case, you may suspect incompatibility between DLT80 and your current scsi-tape driver (st.o). In this case, you need a kernel upgrade.

If it still doesn't work with DDS tape drive, then check whether your scsi card is compatible with your tape drive scsi interface, and check also that the right driver for that card is loaded.

Good luck.

Kodjo

[Gregory Lee]

Thanks for the feedback. What I did was to change the tape drive from a DLT80 to a DLT40 and the backup seem to have gone through (although it did complain about the filesystem setup, error msg attached).

"Directory is a mount point to a different filesystem.
Backed up as empty directory."

I've created those as separate mount points during the installation. I'm not sure why it's throwing those as errors.

BTW, it could be an issue with Omniback on Linux and DLT80 - because I replaces the DLT80 with another one just in case the original was faulty but still no luck.

Thanks.

[Eric Ladner]

Those messages are normal. Just a reminder that you need to specify the mount points in the backup seperately, excluding /proc and other stuff you don't need to backup.

Could be a bad or misaligned tape drive. Do you have another tape drive of the same model you can try?