Bug 14946

Summary:	rmt(8) remote magtape protocol
Product:	Base System	Reporter:	osela <osela>
Component:	bin	Assignee:	freebsd-bugs (Nobody) <bugs>
Status:	Closed FIXED
Severity:	Affects Only Me
Priority:	Normal
Version:	Unspecified
Hardware:	Any
OS:	Any

Description osela 1999-11-17 14:00:00 UTC

I want to use the rmt on bsd vs. solaris 2.7.
When I use ufsdump from the solaris machine to the BSD I get following output:
  DUMP: Writing 32 Kilobyte records
  DUMP: Date of this level 0 dump: Wed Nov 17 15:23:38 1999
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/rdsk/c0t0d0s7 (hope:/export/home) to
alice:/dev/nrsa0.
  DUMP: Mapping (Pass I) [regular files]
  DUMP: Mapping (Pass II) [directories]
  DUMP: Estimated 436 blocks (218KB).
  DUMP: rmtstatus: expected response size 24, got 76
  DUMP: This means the remote rmt daemon is not compatible.
  DUMP: Lost connection to remote host.
  DUMP: Bad return code from dump: 1
The rmt on Solaris is not compatible with the one on BSD.
I need a solution - can any one help :->

How-To-Repeat: just do ufsdump from solaris 2.7 to bsd 3.2

Comment 1 mjacob 1999-11-17 16:34:30 UTC

Does this have problems from a FreeBSD to a FreeBSD machine as well?

Comment 2 Matt Jacob freebsd_committer

2000-02-02 08:42:44 UTC

Responsible Changed
From-To: freebsd-bugs->mjacob

I'll take this one

Comment 3 agenkin 2002-09-06 20:29:36 UTC

This may be a different issue, but I am also unable to use Solaris 8's
ufsdump to dump to a file on a FreeBSD-4.6-STABLE host over RMT.

bash-2.05# ufsdump 0f backup@backup1:/backup/nmarvin.dump /opt 
  DUMP: Writing 32 Kilobyte records
  DUMP: Date of this level 0 dump: Fri Sep 06 03:28:07 2002
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/rdsk/c0t0d0s6 (nmarvin:/opt) to backup1:/backup/nmarvin.dump.
  DUMP: Mapping (Pass I) [regular files]
  DUMP: Mapping (Pass II) [directories]
  DUMP: Estimated 6950164 blocks (3393.63MB).
  DUMP: Login incorrect.
  DUMP: Lost connection to remote host.
  DUMP: Bad return code from dump: 1

 From the above it may seem that there is an authentication problem
between the hosts, but piping the output of ufsdump to rsh and saving
it to the file over this pipe works fine (see output below).  Besides,
if the file "nmarvin.dump" does not exist, ufsdump is able to detect
that over RMT.

nmarvin# ufsdump 0f - /opt | rsh -l backup backup1 'cat > nmarvin.dump'
  DUMP: Writing 32 Kilobyte records
  DUMP: Date of this level 0 dump: Fri Sep 06 03:07:27 2002
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/rdsk/c0t0d0s6 (nmarvin:/opt) to standard output.
  DUMP: Mapping (Pass I) [regular files]
  DUMP: Mapping (Pass II) [directories]
  DUMP: Estimated 6950164 blocks (3393.63MB).
  DUMP: Dumping (Pass III) [directories]
  DUMP: Dumping (Pass IV) [regular files]
  DUMP: 6950142 blocks (3393.62MB) on 1 volume at 6461 KB/sec
  DUMP: DUMP IS DONE

-- 
Arcady Genkin

Comment 4 Mark Linimon freebsd_committer

2004-08-26 03:34:27 UTC

State Changed
From-To: open->feedback

With bugmeister hat on, reassign from inactive committer.

Comment 5 Mark Linimon freebsd_committer

2004-08-26 03:34:27 UTC

Responsible Changed
From-To: mjacob->freebsd-bugs

Is this still a problem with modern versions of FreeBSD?

Comment 6 Mark Linimon freebsd_committer

2004-08-26 07:04:37 UTC

Responsible Changed
From-To: freebsd-bugs->mjacob

mjacob has reactived his commit bit.  mea culpa for the bogus reassignment.

Comment 7 Mark Linimon freebsd_committer

2004-08-31 16:53:49 UTC

State Changed
From-To: feedback->suspended

Original submitter's email bounces.  I don't know if the second 
problem appended to this PR is still valid, though.

Comment 8 Mark Linimon freebsd_committer

2007-08-04 13:09:30 UTC

Responsible Changed
From-To: mjacob->freebsd-bugs

Assignee has turned in his commit bit, so return to pool.

Comment 9 kensmith freebsd_committer

2008-12-16 02:31:33 UTC

State Changed
From-To: suspended->closed


I verified using ufsdump from a Solaris-10 machine to a FreeBSD 7.1-RC1 
machine with the target being a real tape drive works just fine.  If 
the target is a plain file it doesn't work and generates the error 
as described in the second follow-up but rmt was designed to talk to 
tape drives.  You're better off using the approach shown as what works 
in the second follow-up.  For example even on systems where rmt does 
tolerate talking to a file the file needs to already exist, it won't 
create it for you.