Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1080
  • Last Modified:

SUNOS 4.1.3 Tape Restore failed

Hi,

I am trying to restore file systems on SparcStation 20 (SunOS 4.1.3) from a dump tape (made from another SPARCStation20 SunOS 4.1.3).

1) I booted from solaris 1.1.1 CDrom
2) Install Mini OS
3) Restart from the mini OS.
4) newfs /dev/rsd0a
5) mkdir /tmpa
8) mount /dev/sd0a /tmpa
9) cd /tmpa
10) restore -rf /dev/nrst0

It did restore the / file system to it. Then I started to restore /var

1) umount /tmpa
2) newfs /dev/rsd0d
3) mkdir /tmpd
3) mount /dev/sd0d /tmpd
4) cd /tmpd
5) restore -rf /dev/nrst0

It did restore the /var file system to it. Then I started to restore /usr
1) umount /tmpd
2) newfs /dev/rsd0g
3) mkdir /tmpg
3) mount /dev/sd0g /tmpg
4) cd /tmpg
5) restore -rf /dev/nrst0


Unfortunately, it didn't work. Instead, it displayed the following error
message,
/: write failed, file system is full
/: file system full
....
...
expected file nnnnnn, got mmmmmmm
expected file xxxxxx, got yyyyyyy
.......
.......

The /usr partition is using only 528MB on a working SPARCStation 20. I made a 1405MB /dev/sd0g partition in a new SPARC 20. I don't know, why it giving me error message that file system is full.
Also, / is 79MB and /var is 150 MB on working SPARC20 and I made / 150MB and /var 155MB on new SPARC 20.


First, I thought that the dump tape is bad, so I put a crossover Ethernet cable between working SPARC20 and new SPARC20.
Then, on new SPARC20
boot from cdrom
install mini root
newfs /dev/rsd0g
mount /dev/sd0g /tmpg
cd /tmpg
rsh -n hostname dump 0f - /dev/rsd0g | restore rf -

I  got same error messages.

I will be really appreciated if you can help me.

Thanks,
John
0
John22
Asked:
John22
  • 2
2 Solutions
 
jlevieCommented:
Have you tried making a /usr (sd0g) file system closed in size to what works on the "working SPARCStation 20"? Say something in the 600-800MB range?

I know there's not a problem with restoring to a larger file system, but there might be a problem restoring to a  file system of that size (1.4GB).
0
 
yuzhCommented:
Not sure why you want to keep Sun OS 4.1.3, consider upgrade to at least Solaris 8.

You can download Solaris Software CD from:

http://wwws.sun.com/software/solaris/binaries/get.html

Now, get back to your question. can you use format -> verify to make sure you have
allocate enough disk space for the partition, it might be the old dump/restore bug.

You can also try to boot up the box use Solaris 8 or newer CD, and then use ufsrestore
to restore the filesystem. (use format -> verify to make sure you get the correct device
name for the partition.)

You need to use your old CD to do "installboot" .
0
 
John22Author Commented:
Hi,

Yes, I tried /usr partition to 750MB; however, I got same result.

Yes, I can go to "format". My drives is 2 GB drives. I allocated enough disk space for the partition.

I was searching through internet yesterday, and some body has similar problem with restoring only /usr partition. He wrote solution which I don't understand:

"**************************************************
Their replies are quite helpful. All of them think that my / file system of the mini root is  full because 'restore' generate some temporary files.
Actually the two files are /tmp/rstdir*, /tmp/rstmode*.

The strange point is that these two files are not big, only about 1M(maybe 10M?). I am sure the file system is NOT full because I installed the mini root on a 500M partition, you know, the mini root won't take too many spaces. I did expand my swap space which is installed mini root, but it didn't help. Anyway, after I delete it, i am able to restore other file systems.

In the fact, I solved my problem in another way. I restore the file systems in another computer, share it, and then "tar" them to this host. This solutions has a strange point too. When I used 'tar' to copies files from the remote host, it displayed some warnings that,

./etc/restore: permission denied
./etc/in.uucpd: permission denied
.....          (some other files, permission denied too).

I checked the files permission, the permission mode is 400. So it is not readable from NFS. But after my system is recovered, i went to /usr/etc/ and the files ARE there anyway!

***************************************************************"

If you know this solution, please help me.

Thanks,
John
0
 
yuzhCommented:
If you want to use NFS, you need to let the NFS client has root access to
the filesystem, you need to make sure both NFS server and client knows
each other, defined in /etc/hosts, or NIS/NIS+, or DNS etc, then
share it like:

 share -F nfs -o rw=clientbox,root=clientbox /share-dir

tar is not the tool for the job, it can't handle special files. you can use
cpio:

eg:
 cd /source-dir
 find . -print | cpio -oacv | (cd /target-dir ; cpio -icdmuv )

 man cpio
 to learn more

 Good luck!
0

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now