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
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
> ----------
> From: artur[SMTP:artur@compugen.co.il]
> Sent: Thursday, November 06, 1997 3:27 PM
> To: Ronemus AD (Alan)
> Subject: Re: SUMMARY: Problems with Local Restore of Remote Dump
>
>
> I suspect that the architectures sun4 and sun4m have different
> definitions for that tape. Check out that the file
> /sys/scsi/targets/st_conf.c for both systems has the same
> entry for that tape. It looks as the following:
> {
> "Archive Python 4mm Helical Scan", /* name */
> 14, "ARCHIVE Python", /* vendor id */
> ST_TYPE_PYTHON, /* type */
> 1024, /* block size */
> (ST_VARIABLE | /* options - variable records */
> ST_BSF | /* - backspace file */
> ST_BSR | /* - backspace record */
> ST_AUTODEN_OVERRIDE | /* - auto-density device */
> ST_LONG_ERASE), /* - long erase */
> 5000, 5000, /* max retries: read/write */
> { 0x00, 0x8C, 0x8C, 0x8C }, /* density codes */
> { 0, 0, 0, 0 } /* speed codes */
> },
>
> Pay attention on the block size. If you change it to 512 and
> recompile
> the kernel it must be able to restore your tape.
> Of course under miniroot you can do that. The way I can suggest
> you
> is to boot from cdrom of Solaris 2.4 (2.5 as I remember doesn't
> support
> sun4) and then restore your backup, then to boot from Sunos and run
> installboot, by the way when your boot from Solaris you get IP number
> and can restore in remote mode.
>
> Regards.
>
>
>
>
> > 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
> >
> > > ----------
> > > From: Ronemus AD (Alan)
> > > Sent: Tuesday, November 04, 1997 11:32 AM
> > > To: 'Sun Managers List'
> > > Subject: Problems with Local Restore of Remote Dump
> > >
> > > 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
> > >
> > >
>
>
>
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:08 CDT