bak/ rdump getting botched error


Customer using rrestore command after migration, getting botched error.


 ENV:  4.1.5

*CUSTOMER REP:  Karen Vangogh

 PROBLEM:  Customer getting botched error using rrestore and rdump.

*ACTION TAKEN:  Customer is getting error from rdump
                protocol to remote tape server botched (in rmtgets)
        lost connection to remote host
        bad return code from rdump 1

        She was doing this rdump command to a remote Sun and Solaris
        machines.  We tried to do it to the local system with
        rdump -u -0 -f risk:/dev/rmt0 /tmp
        We got this error.  We tried a local remote tar as follows
        tar -cvf- /tmp | rsh risk "dd if=/dev/rmt0 obs=1024"
        and it ran successfully.  We also tried the rdump command
        on an umounted user created filesystem and it failed.
                I'll call the customer back tomorrow around noon central time
        but these are the possible errors I have come up with from

        1. It seems that if rdump sees a .cshrc or a .login (which 
        contains "set mpty='tty') then rdump hangs on the .cshrc. 
        The work-a-round then is to temorarily move the .cshrc to a 
        backup file and then execute the rdump command.

        2. Verify that the rdump is run from a ksh session (most 
        likely).  Related to \#1 above.

        3. Possibly make the blocksize to 4k by adding a -b 4k

        4. Check that at 4.1.5 that the location of rmt is in
        /usr/sbin/rmt.  At 3.2.5, /etc/rmt was a link.

        I will check and see if they are using csh, and if they are
        ask them to try it from ksh.  Perhaps they can mv their .cshrc
        and .login files to backups temporarily.

*ACTION PLAN:  CCB noon Feb 25



*CUSTOMER REP:  Karen Vangogh

*ACTION TAKEN:  I finally got back in touch with the customer.  We went
        through each of my four steps above, and we still got the
        error.  I still thought it had something to do with the csh
        as opposed to the ksh.  She did the following
        >export SHELL
        even though root's default shell was csh.  The rdump still 
        didn't work.  
                We went into /etc/passwd and /etc/security/passwd (or do it 
        through smit) and changed the default shell from csh to ksh.  
        Then she relogged in as root and did a 
        >rdump -u -0 -f risk:/dev/rmt0 /tmp
        and the errors have moved from botched to
        >media write error 2424 blocks into volume.
        We tried a new tape, it was a tape error.
        It worked on the local system.  But it still doesn't work
        going to the remote system.  I suggested they get ksh for
        the remote system.  They have, we'll see the result.  The ksh
        the got for the Sun was not the right level.  The problem
        on the AIX side is fixed, and I would think that getting 
        a ksh on the remote system would fix the problem over the 

        The reason why this has changed from 3.2.5 to 4.1.5 is that
        at 3.2.5 the default shell was the bourne shell.  When they
        moved to 4.1.5, they went to the ksh shell.  They did this
        in order for AIX to be POSIX compatible to other systems.  It
        seems to have had some draw backs on some files, and rdump
        is now not compatible with other shells (perhaps only in
        some instances).



The rdump from 325 is not compatable with the 415 supporting
files.  Coping the rdump command from the 325 machine to the
415 machine is not an option.
.From reading through the item, it sounds like the RS6000 
problems have been solved.
        - must use ksh on both source / target machines
.The problems with the SunOS cannot be addressed by this
call center.  If requested, we can open a design change request
(DCR) for the customer - connectivity issues when using
rdump from AIX6000 to SunOS and Solaris machines.

Support Line: bak/ rdump getting botched error ITEM: BU5051L
Dated: March 1997 Category: N/A
This HTML file was generated 99/06/24~13:30:19
Comments or suggestions? Contact us