Some things to check:
1) Was the dump created in accordance with the man page
(specifically, the unmounted or mounted read-only part)?
2) Was the system in single-user mode when the dump was taken?
3) What system was the dump created on?
4) What system are you trying to extract the dump on?
5) Are there any ufs patches which might cover any bugs in this area?
6) Are you using the same architecture as when the dump was created?
(I'm not 100% sure that ufs is endianness-agnostic).
9 times out of 10 when I see a strange error during ufsrestore, it was
because a dump was taken of a live filesystem without using fssnap. The
most common one I used to see was "bread: seek past end of device", and
there are others, all equally cryptic. This may simply be another example.
The error comes from xtrmap (using the opensolaris code as an example,
from
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/backup/restore/tape.c#1399):
1398 *static* *void*
1399 xtrmap <http://src.opensolaris.org/source/s?refs=xtrmap&project=/onnv>(*char* *buf,
size_t <http://src.opensolaris.org/source/s?defs=size_t&project=/onnv> size
<http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/backup/restore/tape.c#size>)
1400 {
1401 *if* ((map
<http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/backup/restore/tape.c#map>+size
<http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/backup/restore/tape.c#size>)
> endmap
<http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/backup/restore/tape.c#endmap>)
{
1402 int64_t <http://src.opensolaris.org/source/s?defs=int64_t&project=/onnv> mapsize
<http://src.opensolaris.org/source/s?refs=mapsize&project=/onnv>, increment
<http://src.opensolaris.org/source/s?refs=increment&project=/onnv>;
1403 int64_t <http://src.opensolaris.org/source/s?defs=int64_t&project=/onnv>
diff <http://src.opensolaris.org/source/s?refs=diff&project=/onnv>;
1404
1405 *if* (spcl <http://src.opensolaris.org/source/s?defs=spcl&project=/onnv>.c_type <http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/backup/restore/tape.c#c_type> != TS_ADDR <http://src.opensolaris.org/source/s?defs=TS_ADDR&project=/onnv>) {
1406 (*void*) fprintf
<http://src.opensolaris.org/source/s?defs=fprintf&project=/onnv>(stderr
<http://src.opensolaris.org/source/s?defs=stderr&project=/onnv>,
1407 gettext
<http://src.opensolaris.org/source/s?defs=gettext&project=/onnv>("xtrmap: current
record not TS_ADDR\n"));
1408 done
<http://src.opensolaris.org/source/s?defs=done&project=/onnv>(1);
1409 }
What this actually means is beyond me, but may indicate the backup tape
is corrupt, or the backup was not done correctly in the first place.
Finally, if this is all Solaris 10, then you should log a support call
to help get this resolved.
Hope that helps,
Brian
Sarah kho wrote:
hi,
I am trying to restore a file system i dumped using ufsdump command.
The dump was created in level 0 sometimes ago and now when i try to
restore it, the ufsrestore command ends with the following message and
nothing else is shown after it and the file system is not restored either.
xtrmap: current record not TS_ADDR
Before showing this message, ufsrestore shows correct information
about the dump. information like: creation date, label, etc. I tried
google but it was not helpful. if you happen to know how to deal with
this problem, pleas let me know.
thanks.
------------------------------------------------------------------------
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
--
Brian Ruthven
Solaris Network RPE (Sustaining)
Oracle UK
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
