Very Computer

I'm trying to backup to a remote DLT drive (using ufsdump),
and I'm getting the following error:

#!/bin/sh
ufsdump 3uf agsun03:/dev/nrst28 /

  DUMP: Writing 32 Kilobyte records
  DUMP: Date of this level 3 dump: Tue Dec 10 03:00:01 1996
  DUMP: Date of last level 0 dump: Mon Dec 09 09:40:13 1996
  DUMP: Dumping /dev/rdsk/c0t3d0s0 (agsun02:/) to agsun03:/dev/nrst28.
  DUMP: Mapping (Pass I) [regular files]
  DUMP: Mapping (Pass II) [directories]
  DUMP: Mapping (Pass II) [directories]
  DUMP: Mapping (Pass II) [directories]
  DUMP: Mapping (Pass II) [directories]
  DUMP: Estimated 150 blocks (75KB).
  DUMP: Protocol to remote tape server botched (in rmtgets).
  DUMP: Lost connection to remote host.
  DUMP: Bad return code from dump: 1

The DLT drive is a Quantum DLT4000, and it works fine when used
locally. Remote backups to other machines with the same type
DLT drive also work fine. We're running Solaris 2.5 on Sparc 10's.

Any ideas?

Thank you very much,

Jerry Cunningham
UNIX System Administrator
U.S. Census Bureau

Next, the last time I saw a problem similar to this it was caused by a
badly configured .cshrc file on the machine that has the tape drive.
Basicly, the ufsdump on your machine needs to start a non-interactive
shell on the machine with the tape drive to run /etc/rmt which talks to
the tape drive locally. If that shell trys to do an interactive type
thing (like stty) to this non-interative shell you'll see that kind of
error. Fix the .cshrc (if you're running csh) and everything should work
properly assuming this is the same type of problem.

Good luck...

        Dave

--
-------------------------------------------------------------------------------


Noran Instruments, Inc.     |
Middleton, WI.              |
(608)836-4125               |

Look, look, see Windows 95.  Buy, lemmings, buy!  
Pay no attention to that cliff ahead...            Henry Spencer

(C) 1996 Dave Greunke

Redistribution via the Microsoft Network prohibited
The above opinions are my own and probably do not reflect those of my
employer.

From the SUN admin FAQ :

62)     My rdump is failing with a "Protocol botched" message. What do I do?

        The problem produces output like the following:

          DUMP: Date of this level 0 dump: Wed Jan  6 08:50:01 1993
          DUMP: Date of last level 0 dump: the epoch
          DUMP: Dumping /dev/rsd0a (/) to /dev/nrst8 on host foo
          DUMP: mapping (Pass I) [regular files]
          DUMP: mapping (Pass II) [directories]
          DUMP: estimated 8232 blocks (4.02MB) on 0.00 tape(s).
          DUMP: Protocol to remote tape server botched (in rmtgets).
         rdump: Lost connection to remote host.
          DUMP: Bad return code from dump: 1

        This occurs when something in .cshrc on the remote machine prints
        something to stdout or stderr (eg. stty, echo). The rdump command
        doesn't expect this, and chokes. Other commands which use the rsh
        protocol (eg. rdist, rtar) may also be affected.

        The way to get around this is to add the following line near the
        beginning of .cshrc, before any command that might send something
        to stdout or stderr:

        if ( ! $?prompt ) exit

        This causes .cshrc to exit when prompt isn't set, which
        distinguishes between remote commands (eg. rdump, rsh) where these
        variables are not set, and interactive sessions (eg. rlogin) where
        they are.

HTH,

--

IRIS                            http://www.irislink.com/
Rue du Bosquet 10
B-1348 Louvain-la-Neuve Belgium