Managers:
I received a number of interesting and informative responses which
I have included below (apologies to anyone I missed). The original
question is at the end of the summary. Paul A Sand takes the prize
for pointing me toward a solution that I *never* would have thought of,
namely, that /usr/sbin must (evidently) be the *last* thing in the $path.
My original path:
PATH=./:/sbin:/usr/sbin:/usr/bin:/usr/bin/X11:/etc
The remote dump would not work with this path, even though it
contains /usr/sbin.
But, when I changed the path to:
PATH=./:/sbin:/usr/sbin:/usr/bin:/usr/bin/X11:/etc:/usr/sbin
the remote dump worked beautifully. Strange, but true.
==========================================================================
Paul Sand wrote:
Hey, guess what? I just ran into this a bit ago. On the DEC box,
make sure /usr/sbin is in root's path for a NON-login
access. In my case, appending
set path = ($path /usr/sbin)
to my /.cshrc worked. Let me know if you continue to have problems.
==========================================================================
From: C.Ruhnke <i769646_at_smrs013a.mdc.com>
I suspect your problem may be due to using a "remote node" device address
(tbirds:/dev/rmt0h) for your output file.
I use remote access to backup my system disk from one AlphaServer 8200 to
another which has the drive attached using a pipe and a remote shell. Try
something like the following:
# /sbin/dump 0uf - /var | rsh tbirds dd of=/dev/rmt0h bs=64k
You may need to adjust the "bs=" parameter to match the block size
produced by Linux's dump utility.
===========================================================================
From: "Nestor Ruiz" <nruiz_at_hermes.bvl.com.pe>
hmm...
I made some test many time ago, with similar config, DU3.2g to a Linux box
I do made backups, but my problem was that I couldn't retrieve those backups
made in the linux box....
Later, I saw in some archieves (Summaries), that /dev/rmt0h was the special
device to "compress" data on the cartridge.
Now, I used VDUMP from DU to Linux..., using DD, how?
[alpha]#vdump -0 -f - / | rsh linux "dd ibs=512 obs=1024 of=/dev/rmt0"
Now, using the "inverse" as you are doing, I guess that it must be
[linux]<color><param>7F00,0000,0000</param># /sbin/dump 0uf - /var | rsh tbirds "dd ibs=512 obs=1024 of=/dev/rmt0h"
I remember I gave tape access to some user and then, made rsh using that
user, using "-l <<user>" option...
I would like to make some testings about this, but I guess I should use
/dev/rmt0a instead on the "h" ending...
All that I have explain, comes from the following command :
tar -b1 -cf - <<path> | rsh <<host> "dd ibs=512 obs=1024 of=<<tapedev>"
I found that command in a AIX faq, about remote tape access....
===========================================================================
From: Paul Crittenden <crittend_at_storm.simpson.edu>
Here is what I did. First make sure the name of the machine in what you think
it is. Login to each machine and then telnet to the other. Once logged in
then do a last | more and see what your machine thinks the name of the
other machine is. Put that name in the .rhosts file like this: name root.
Change ownership to root and protections to 0600. In the /etc directory I
set up hosts.equiv with the same inof as .rhosts but protections of 755 and
ownership of root. Things then worked.
What really messed me up was I had set a second IP address on my interface
and the other machine saw it as that address not the one I thought it was.
Hope this helps.
===========================================================================
From: Tom Webster <webster_at_ssdpdc.lgb.cal.boeing.com>
I'm not sure how well dump on Linux follows the rmt protocols. One thing
you might consider is doing it the hardway with dd. This is more or less
the command that we have used to do remote vdumps from one DU system to
another's tape drive, check the Linux dump syntax before using.
On tbirds:
rsh linux1 "/sbin/dump -0 -b ${BLOCKSZ} -f - ${FS}" | dd of=${TAPEDEV} bs=${BLOCKSZ}k
Where:
${BLOCKSZ} = The block size in kb that your tape drive uses natively.
${FS} = The filesystem to be dumped, we us this line inside a do loop.
${TAPEDEV} = The tape drive's device file on tbirds.
============================================================================
From: "Dr. Tom Blinn, 603-884-0646" <tpb_at_zk3.dec.com>
Where is the "rmt" tape server found on the Linux box? Make sure that you
have it linked or symlinked to the same place on the DIGITAL UNIX box; the
error you're getting suggests the Linux "/sbin/dump" is looking for it but
can't find it where it expects to find it. Alternatively, the /sbin/dump
is sending some command to rmt that rmt is supposed to execute (imagine an
"mt" command that should be shelled out), and rmt can't find whatever the
Linux box is asking it to execute (that could be the "rmt: Command not
found." error). I'm just guessing here, I don't have the Linux sources at
hand, but I suspect you can figure it out from reading the sources.
===========================================================================
The original question:
> Managers:
>
> I have been trying to make a backup of a file system located on a
> Linux box, using the DAT drive (TLZ09) on an alpha 1000A. Both
> systems have .rhosts files pointing at each other. I have included
> below the output from the dump command issued on the Linux box, as
> well as an ls for the remote tape handler on the alpha (DU 4.0d).
> What am I doing wrong?
>
> [root_at_linux1 /]# /sbin/dump 0uf tbirds:/dev/rmt0h /var
> DUMP: Date of this level 0 dump: Tue Aug 4 04:39:23 1998
> DUMP: Date of last level 0 dump: the epoch
> DUMP: Dumping /dev/sda7 (/var) to /dev/rmt0h on host tbirds
> DUMP: mapping (Pass I) [regular files]
> DUMP: mapping (Pass II) [directories]
> DUMP: estimated 9626 tape blocks on 0.25 tape(s).
> DUMP: Protocol to remote tape server botched (code "rmt: Command not found.").
> rdump: Lost connection to remote host.
> DUMP: Bad return code from dump: 1
>
> On tbirds:
>
> />ls -l /etc/rmt
> lrwxrwxrwx 1 root system 15 Jul 18 08:32 /etc/rmt -> ../usr/sbin/rmt
> />ls -l /usr/sbin/rmt
> -rwxr-xr-x 1 root bin 24576 Dec 29 1997 /usr/sbin/rmt
Received on Tue Aug 04 1998 - 20:24:14 NZST