ITEM: BU5051L
bak/ rdump getting botched error
Question:
Customer using rrestore command after migration, getting botched error.
Response:
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
austext
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
TEST CASE: n/a
Response:
*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
>SHELL=/usr/bin/ksh
>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
network.
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).
*ACTION PLAN: CWCA
Response:
ACTION PLAN:
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