Dear Sun Managers,
Thanks to the following folks who provided additional insights into
my problem:
Don Lewis <Don.Lewis@tsc.tdk.com>
Artur Schnayder <artur@compugen.co.il>
Joseph S. D. Yao <jsdy@cais.com>
Chuck Kenyon <chuck@npiww.com>
Apparently I need to amplify on my previous summary. The sun4 kernel
(and presumably the mini-root) doesn't have a definition for a SCSI DAT
drive; this is true in both SunOS 4.1.3_U1 Rev. B and 4.1.4. The
directory /usr/kvm/sys/scsi is not present on a sun4 installation and
therefore st_conf.c is not used. This is confirmed by running:
strings /vmunix | grep Archive
On a generic sun4m kernel, this produces strings for QIC-150 and 4mm DAT
drives; however, on a sun4 kernel the output is just the single word
(Archive). This probably means that the sun4 system is treating the DAT
as though it were a QIC drive, corrupting the data stream in the
process.
Joseph had the following suggestion, which I haven't had a chance
to try.
>I hate to suggest it; but if you have enough disk space on a separate
>disk, you might try
> dd if=/dev/nrst0 bs=512 of=/bigfs/x
> restore rvf /bigfs/x
Some combination of dd parameters may produce usable data for restore,
but no combination to date has worked. Any further insights would be
appreciated.
Thanks,
Alan
> ______________________________________________________________________
> _________________________
>
The second summary:
> ______________________________________________________________________
> _________________________
>
Dear Sun Managers,
Thanks to Artur for putting me on the right track. The 4 mm DAT
drive is defined for the sun4m architecture (the Sparc5 where the tape
was written) but is undefined for sun4 (the SPARCstation 4/370 where I
attempted to read the tape). Apparently the default st device expects
512 byte blocks, while the tape was written with 1024 byte blocks. This
explains the source of the problem, but not the inability of dd to
convert the data. One of the command strings I used was
> dd if=/dev/nrst0 obs=1024 conv=sync | restore rvf -
>
which should have solved the problem. Perhaps the default st behavior
somehow corrupts the data in some other way as well. Any additional
insights would be appreciated.
Thanks,
Alan
> ______________________________________________________________________
> _________________________
>
The first summary:
> ______________________________________________________________________
> _________________________
>
Dear Sun Managers,
Thanks to those who replied to my posting, which is appended. Dave
Mitchell and Artur Schnayder suggested the following parameters for dd
and/or restore, some of which I hadn't attempted.
dd if=/dev/nrst0 obs=1024 | restore rvf -
dd if=/dev/nrst0 ibs=96b obs=126b | restore rvf -
restore -rvfb /dev/nrst0 96
Unfortunately, that didn't solve the problem. Joel Lee suggested that
special drivers might be required that were missing from the crashed
system, but the drive is a Sun 4 mm DDS DAT that is supported on SunOS
4.1.3_U1 Rev. B. The problem is unresolved, so I would be glad to hear
additional suggestions. I will summarize again if a solution is found.
Thanks,
Alan
________________________________________________________________________
_______________________
The original posting:
> ______________________________________________________________________
> _________________________
>
>
> Dear Sun Managers,
>
> I have encountered a strange problem with doing a restore on a
> local Sun 4mm 2/5 GB tape drive from a tape made using rdump to the
> same drive. My environment is SunOS 4.1.3_U1 Rev. B on a sun4
> (SPARCstation 4/370). The tapes were maded using the command:
>
> rdump 0uctbsdfv 1 96 5000 61000 remote_tape_host:/dev/nrst0
> local_partition_name
>
> After a disk crash and installing new disks, I loaded the mini-root
> from CD and attempted to restore from the same tape drive mounted
> locally with the following command:
>
> restore rvf /dev/nrst0
>
> This failed with the error message "record size (512) is not a
> multiple of dump block size (1024)." I attempted to resolve this
> using dd as follows:
>
> dd if=/dev/nrst0 ibs=1024 conv=sync | restore rvf -
>
> This produced a checksum error and an error message from restore that
> the tape was not in dump format. When I leave out the conv=sync
> option I get error messages about a partial block read as well as the
> checksum. I've tried a variety of block sizes in restore and dd
> without success. I have a number of files on the tape and all produce
> the same results, as does using the SunOS 4.1.4 CD to load the
> mini-root.
>
> I finally did a complete install from the CD and with the correct
> network configuration. I put the DAT drive on the original tape host
> (SunOS 4.1.3_U1 Rev. B, sun4m (Sparc5)) and was able to restore using
> the following command:
>
> rrestore rvf remote_tape_host:/dev/nrst0
>
> This worked, but required more time and effort than restoring locally
> using the mini-root from the CD. Does anybody know a workaround? I
> will summarize.
>
> Thanks,
> Alan
>
> Alan Ronemus Telephone: (304)747-3651
> Union Carbide Corporation Facsimile: (304)747-5430
> 3200 Kanawha Turnpike E-mail: ronemuad@ucarb.com
> P. O. Box 8361
> South Charleston, West Virginia 25303
>
>
Alan Ronemus Telephone: (304)747-3651
Union Carbide Corporation Facsimile: (304)747-5430
3200 Kanawha Turnpike E-mail: ronemuad@ucarb.com
P. O. Box 8361
South Charleston, West Virginia 25303
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:08 CDT