Howto replace the system disk

[Bengt Nilsson_2]

We have PWS500au with tru64 4.0F, on which we need to replace the system os disk to a new and larger one. I have reason to believe it may fail soon, and it is also too small.

I tried to set up a similar machine (a 433au) , install 4.0F on it, and vdump/vrestore the disk contents from the old system to the new, in hope to be able to carry over the new disk to the old after this was completed and just reboot the new disk.
Well, it failed, of course. The first reason was that the working device files were overwritten so the tape device disappeared in the middle of my vrestore script. And I am sure there are many other reasons why this is the wrong method.

Could someone please help to outline the steps how to do this disk replacement/upgrade the correct way?

[Martin Moore]

If you can hook up the new disk to the system while it's still booted from the old disk, this is easy:

1. In single-user mode, run disklabel to create the partition sizes on the new disk the way you want them. (Note: if your root filesystem is AdvFS, make sure you include the "-t advfs" option to disklabel in order to include AdvFS boot blocks.)

2. Create the new filesystems on the new disk partitions with newfs (if UFS) or mkfdmn/mkfset (if AdvFS).

3. Use vdump|vrestore pipelines to copy each old filesystem to its new location. The examples section of the vdump man page includes an example of the proper syntax.

4. After all filesystems are copied, shut down the system and move the new disk to the original boot disk's slot. (You don't absolutely have to do this, but if you don't, then you'll need to edit the "new" filesystems first to change some disk pointers, because the disk will have a different device name if it's in a different slot.)

Now if you DON'T have room to have both the old and new disks up at the same time...then you'll need a tape drive and an installation CD-ROM that you can boot from. In this case, you vdump the filesystems to tape, put the new disk in, boot from CD, then run disklabel, make your new filesystems, and restore them from tape. This process is essentially covered in section 11.4.5 in the V4.0F System Admin manual, which is available at http://www.tru64unix.compaq.com/docs/base_doc/DOCUMENTATION/V40F_HTML/APS2RFTE/TITLE.HTM.

Hope this helps,
Martin

[Bengt Nilsson_2]

Looks lika a good advice, I will test it shortly.
Hopefully I will close this thread after success.

Thanks.

[Bengt Nilsson_2]

Hmm.. just remembered that I once tried to boot from CD in order to do a similar operation from tape to disk, and ran into the fact that there were no tape devices in /dev. What could be the reason for this?

[Martin Moore]

To make the tape device after you boot from the V4 CD, you have to cd to /dev and run MAKEDEV. The argument to MAKEDEV will be tzN, where N = (bus*8 + target). You can determine the values for bus and target from the console device name (from SHOW DEV at the SRM prompt). For example, if you have MKB500 as your tape device, then this is SCSI bus #1 (indicated by the B -- A=0, B=1, etc.) and the target is 5. So for this example, you would do the following after you boot from CD and escape to the shell:

# cd /dev
# ./MAKEDEV tz13 (13 = 8*1 + 5)

This will create the rmt0* devices for the tape.

Martin

[Bengt Nilsson_2]

Thanks, just one final thing: The link to the v4 manual you supplied is dead. Do you have an update?

[Martin Moore]

Ah, it seems that the period at the end of the sentence got included in the link. Here's the correct link:

http://www.tru64unix.compaq.com/docs/base_doc/DOCUMENTATION/V40F_HTML/APS2RFTE/TITLE.HTM

[Bengt Nilsson_2]

I have a question about restoring form tape.
I am "in the hands" of our equipment service engineer (our PWS5000au is controlling some complicated equipment) who is not very deep into computer management and our prescribed backup script is as follows:

umount /proc
mt -f /dev/nrmt0h rewind
vdump -0Nuf /dev/nrmt0h /
mount -t procfs /proc /proc
vdump -0Nuf /dev/nrmt0h /usr
vdump -0Nuf /dev/nrmt0h /usr/ebsys
vdump -0Nuf /dev/nrmt0h /usr/users
mt rewind
mt unload

and the restore

mt -f /dev/nrmt0h rewind
umount /proc
vrestore -x -f /dev/nrmt0h -D /
mount -t procfs /proc /proc
vrestore -x -f /dev/nrmt0h -D /usr
vrestore -x -f /dev/nrmt0h -D /usr/ebsys
vrestore -x -f /dev/nrmt0h -D /usr/users
mt rewind
mt unload


All very well, as long as you restore to a working disk, but I am now working from the install CD shell.

What to do about the /proc file system?
I am not sure what it is for, and I don't see it in /etc/fdmns. What do I mount to restore it?

Do you understand my question? I may not have expressed it very well...


Another thing:
My file domains are named rz16a, rz16g and rz16h.
My file systems are named rz16a#root, rz16g#usr, rz16h#ebsys and rz16h#users.

I was able to restore rz16a#root and rz16g#usr successfully. But then I got problems.

I mount by
mount -w -t advfs rz16h#ebsys /mnt
and restore
vrestore -x -f /dev/nrmt0h -D /mnt

Then I get (immediately)
/var: file system full
/var: write failed, file system is full
vrestore: dir_write() error [28] No space left on device; terminating

df shows
File systems 512-blocks Used Available Cap Mounted
rz16h#ebsys 24592944 32 24581248 1% /mnt

So what is the problem?

[Bengt Nilsson_2]

Sorry, please disregard the previous entry entirely.
I got all confused and screwed up.

[Bengt Nilsson_2]

I followed the advice and the disk-to-disk piping worked without any problems on my test PWS433. I have no reason to believe it will be different on my "production" PWS500.
Mission completed, case closed, thanks a bundle.