Solaris 2.4 UFSDUMP/UFSRESTORE

Solaris 2.4 UFSDUMP/UFSRESTORE

Post by <Mike Batterden> » Thu, 22 Jun 1995 04:00:00



I have been experiencing problems when I attempt to
perform 'ufsrestore' on any Solaris 2.4 machine with tapes
that were created using 'ufsdump' on Solaris 2.3 or
'dump' on SunOS 4.1.3.

The error message that i see states something like
"Invalid Tape Length Specified".  In all cases, the
tape drive being used is the Exabyte 8500C

All of these dumps restore with no problem on any
machine running SunOS 4.1.3 or Solaris 2.3 using
the default blocking factor.

Has anyone had any similar experiences or
is there a 2.4 patch related to this ?

TIA

 
 
 

Solaris 2.4 UFSDUMP/UFSRESTORE

Post by Hans Werner Stru » Fri, 23 Jun 1995 04:00:00


: I have been experiencing problems when I attempt to
: perform 'ufsrestore' on any Solaris 2.4 machine with tapes
: that were created using 'ufsdump' on Solaris 2.3 or
: 'dump' on SunOS 4.1.3.

: The error message that i see states something like
: "Invalid Tape Length Specified".  In all cases, the
: tape drive being used is the Exabyte 8500C

: All of these dumps restore with no problem on any
: machine running SunOS 4.1.3 or Solaris 2.3 using
: the default blocking factor.

: Has anyone had any similar experiences or
: is there a 2.4 patch related to this ?

In /kernel/drv/st.conf, use:
tape-config-list=
"EXABYTE EXB8500C", "Exabyte 8500C 8mm Helical Scan", "Exa8500c";
Exa8500c = 1,0x29,0,0xCE39,4,0x14,0x15,0x15,0x8C,3;

Note the 0 in the 3rd position, which differs from Solaris 2.3!

--


 Drittes Physikalisches Institut,  Univ. Goettingen
 Buergerstr. 42-44,   D-37073 Goettingen,   Germany

 
 
 

Solaris 2.4 UFSDUMP/UFSRESTORE

Post by Don Turrenti » Sat, 24 Jun 1995 04:00:00


: I have been experiencing problems when I attempt to
: perform 'ufsrestore' on any Solaris 2.4 machine with tapes
: that were created using 'ufsdump' on Solaris 2.3 or
: 'dump' on SunOS 4.1.3.

: deleted ....

I remember reading in the Sol 2.4 Open Issues and Late Breaking News
that there were compatibility problems with pre-Solaris 2.4 tapes,
great isn't it! Anyhow it does suggest workarounds for SUN drives.

Here it is, I found it! To save space here is the workaround for an
Exabyte 8500. PLEASE BE ADVISED this is what is in the manual!

o Edit the /kernel/drv/st.conf:
        tape-config-list=
        "EXABYTE EXB-8500","Exabyte EXB-8500 8mm Helical Scan", "Exa8500",
        ...
        ...
        ...
        Exa8500 =1,0x29,0,0x04E39,4,0x14,0x15,0x8C,0c8C,3;

The ... represents other entries.

Hope this helps.

-Don

--
Don Turrentine, Information Systems Specialist
UAB - Cardiac Rhythm Management Laboratory
Volker Hall G78A
1670 University Blvd
Birmingham, AL 35294-0019
205-975-4710 Voice
205-975-4720 Fax

 
 
 

1. ufsdump + ufsrestore no longer reliable across network in 2.4?

Has anyone else observed problems when using ufsdump + ufsrestore
to copy filesystems between Solaris 2.4 hosts across an Ethernet?

E.g. a command like this:

        # su userThatCanReadRawDisks -c 'rsh remoteHost -n "/usr/lib/fs/ufs/ufsdump 0f - /dev/rdsk/c0t1d0s2"' | /usr/lib/fs/ufs/ufsrestore rf -

which used to work here when copying between Solaris 2.3 hosts,
no longer seems to work when copying between Solaris 2.4 hosts.
I get hiccups like this (on a 1.6 GB filesystem):

          DUMP: 51.34% done, finished in 2:16
        resync restore, skipped 5 blocks
        ./src/base/X11R6/xc/programs/twm/resize.h: not found on volume
          DUMP: 56.01% done, finished in 2:01

Some files not mentioned in any error message are also corrupted.
The source filesystem is mounted readonly and the destination filesystem
is newly newfs'ed, so phase errors shouldn't be a problem.

These symptoms are _quite_ scary, as I've always viewed ufsdump + ufsrestore
to be the most reliable way to copy filesystems in SunOS.

I notice that ufsdump and ufsrestore have had a lot of changes,
at least in their diagnostics, so I'm suspicious that they may
have mutated a little too quickly.  Perhaps I should go back
to 5.3 ufsdump + ufsrestore.

Both source and destination hosts here are using the following patches.

        101242-08 101753-04 101829-01 101878-01 101879-01 101880-03
        101902-02 101905-01 101907-05 101920-02 101922-06 101923-03
        101925-01 101927-01 101933-01 101945-13 101959-03 101969-05
        101973-03 101979-03 101981-02 101987-02 101995-01 102001-03
        102002-03 102003-01 102005-01 102007-01 102011-02 102020-03
        102035-01 102036-01 102037-01 102038-02 102044-01 102048-01
        102057-08 102062-03 102066-04 102070-01 102079-01 102112-01
        102113-03 102137-01 102216-01

2. Redhat 6 NIS Help

3. ufsrestore/ufsdump on Solaris Sparc/x86 incompatibility

4. /usr/games/fortune

5. Solaris ufsdump/ufsrestore usage

6. How to start xfs and xset, rc.local no work.

7. ufsdump & ufsrestore on solaris 8

8. Version 0.5 of HFS module

9. ufsdump & ufsrestore on Solaris 2.5 and 2.5.1

10. Problem with solaris 2.4 ufsdump

11. Reproducible bug in Solaris 2.4 ufsdump

12. Solaris 2.4 ufsdump and truss

13. solaris 2.4 ufsdump problem