Thanks to:
<bbyoung@amoco.com>
<mikem@centerline.com>
<kpi@hobbes.crc.com>
<mdkail@dime.fv.com>
<glenn@uniq.com.au>
<pluto!perryh@qiclab.scn.rain.com>
<martin@gea.hsr.it>
The solution to my unrestorable dump tape was a combination of the solutions
suggested by mikem@centerline.com and pluto!perryh@qiclab.scn.rain.com.
mikem wrote:
>Try this:
>
> dd if=/dev/rst0 bs=512 of=/BigPartition/dumpfile
> restore ivf /BigPartition/dumpfile
And perryh wrote:
>I would try using dd to reblock:
>
># dd if=/dev/rst0 ibs=1b obs=20b | restore ivbf 20 -
I had started to uses mikem's solution with success before receiving perryh's
response, except that some of my tape files are as large as 2GB. When I got
perryh's response i tried:
dd if=/dev/nrst0 bs=512 | restore rvf -
That did it! No need for extra disk space. I still don't understand why
this happened (latecomers can see my problem description following); some
suggested that my drive is not spec'd in /sys/scsi/targets/st_conf.c, but
it's ok. In any case, I did verify my tape prior to the reinstall; and
all's well that ends well.
Bill
>>Greetings:
>>
>>I am unable to restore data from a dump tape. The system, a SS10, was
>>at 4.1.3 at dump time and is now at 4.1.3_U1. The tape drive is an Archive
>>Python 4mm Helical Scan. The dump command was:
>>dump 0dsf 6000 54000 /dev/rst0 <file system>
>>The restore has been, variously:
>>restore ivf /dev/rst0
>>and
>>restore ivbf <B_factor> /dev/rst0
>>
>>Restore transcripts:
>># restore ivf /dev/rst0
>>Verify volume and initialize maps
>>Record size (512) is not a multiple of dump block size (1024)
>>#
>># restore ivbf 20 /dev/rst0
>>Verify volume and initialize maps
>>partial block read: 512 should be 10240
>>abort? [yn] y
>>dump core? [yn] n
>>#
>>(Interestingly, the blocking factor argument to the 'b' option is
>>multiplied by 512 to get the 'should be' value; I tried several
>>b values)
>>
>>I also tried tcopy:
>># tcopy /dev/rst0
>>file 1: records 1 to 35039: size 512
>>file 1: eof after 35039 records: 17939968 bytes
>>.
>>.
>>.
>>#
>>
>>The 4.1.3_U1 is installed with patches:
>> 100103-12: SunOS 4.1.3_U1: script to change file permissions to a more secure mode
>> 100444-74: OpenWindows 3.0: OpenWindows V3.0 Server Patch 3000-122
>> 100448-02: OpenWindows 3.0: loadmodule is a security hole.
>> 100452-72: OpenWindows 3.0: XView 3.0 Jumbo Patch
>> 100478-01: OpenWindows 3.0: xlock crashes leaving system open
>> 101434-03: SunOS 4.1.3_U1: lpr Jumbo Patch
>> 101436-08: SunOS 4.1.3_U1: bin/mail jumbo patch
>> 101440-01: SunOS 4.1.3_U1: security problem: methods to exploit login/su
>> 101508-10: SunOS 4.1.3_U1: sun4m kernel jumbo patch
>> 101579-01: SunOS 4.1.3_U1: Security problem with expreserve for Solaris 1.1.1
>> 101587-01: SunOS 4.1.3_U1: security patch for mfree and icmp redirect
>> 101621-02: SunOS 4.1.3_U1: Jumbo tty patch
>> 101625-02: SunOS 4.1.3_U1: ftp does not prompt for account information
>> 101665-04: SunOS 4.1.3_U1: sendmail jumbo patch
>> 101679-01: SunOS 4.1.3_U1: Breach of security using modload
>> 102060-01: SunOS 4.1.3_U1: Root access possible via forced passwd race condition
>> 102177-02: SunOS 4.1.3_U1: NFS Jumbo Patch
>> Extracted CTE patch ow3_u1
>>
>>Please help if you can,
>>Bill
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:54 CDT