Link to home
Start Free TrialLog in
Avatar of Eric-K
Eric-K

asked on

Hard-drive Upgrade

I’m a Unix programmer, not a sysadmin.  I’ve never done anything like this before, so I could use, well, maybe just a sanity check ….

I have a clone sparc box running Solaris-7.  I’ve had it for several years, and recently ran out of hard-drive space on /home.  Since the drive is about 5 years old anyway, I thought I’d just replace it with a larger drive, which I’ve already bought.

Here’s the trick:  I need to format & partition the drive, make it bootable, and then clone my existing system to the new drive.  Sounds simple enough ...

   (1)  I don’t want to reinstall Solaris from scratch because over the years, I’ve installed all kinds of stuff, customized things etc. …  And its not just about the effort involved, it’s a matter of trying to remember everything I’ve done.  So cloning is really the only answer.  But…

   (2)  I am concerned that if I just bulk copy the image of the original drive to the new drive, there may be some system-file content which encodes the physical parameters of the drive or its partitions.  (Where’s the partition table itself, for example?)

I suppose that I’d better keep the SCSI ID at ID0 since anything (scripts, etc) that might reference the raw slices would be affected (I guess too that its the default for booting ?).  Amyway, I can’t keep the partition sizes the same (as I would if were just replacing a bad drive with an identical one) because the whole point of this exercise is to upgrade.  So what kind of trouble do I have to lookout for?

  (3)  When allocating the new space, are there any partition size limitations I have to watch out for?  I think, for example that SWAP has to be less than 2GB (right?).  What about the other partitions?

   (4)  Also regarding allocations … I currently have 256MB  memory with 512MB SWAP.  It seems to me this doesn’t leave much for /tmp, but on the other hand, I’ve been running fine like this for years … would there be any advantage to allocating a larger Swap partition?

To format the drive, I thought I’d go through the exercise of doing a cold install onto the new drive from the Solaris installation CD.  Then, once the partitions have been setup and drive is made bootable, I’d reattach & reboot the original drive, and over-copy the old system to the new drive.

Something like this (please comment):

   for  x  in  0  1  3  4  5  6  7
   do
        rm   –r   /newdrivemount/slice{$x}
        dd   /dev/dsk/c0t0d0s{$x}   /dev/dsk/c0t1d0s{$x}
   done

   (5)  Will this work as I expect, or will I be indirectly clobbering the destination partition table in the course of copying…(?)

Avatar of jlevie
jlevie

The best way to do this is to (from a boot into single user mode):

1) Use format to create slices on the new drive for each file system that you have. Note that it is possible to change the system layout while doing the transfer.

2) Use newfs on each file system on the new drive (skip the slice for swap).

3) Use ufsdump/ufsrestore to copy each existing file system to the appropriate FS on the new drive.

4) Install the bootloader (installboot)

5) Shut down and move the new drive to SCSI ID 0 and boot.
SOLUTION
Avatar of yuzh
yuzh

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Eric-K

ASKER

Thanks for the pointers, but you have to understand (as I said from the outset) that I’m not an admin, and the tools you guys regularly use are unfamiliar to me.  So when you tell me to “just” use this or that utility, try to appreciate that it makes me a bit nervous to do something critical for the first time, based on just what I read in a man-page … the script  yuzh  pointed me to is helpful, but again, I couldn’t tell just by reading it, if it had a typo … or even whether its actually doing what I really want.  I did read it though, and if I understand it correctly, the line:

    prtvtoc /dev/rdsk/${S}s2|fmthard -s - /dev/rdsk/${T}s2     # copy VTOC

suggests that its not doing what I really want ... that it clones partitions of identical size from the original (which from all articles I’ve read seems to be the thing people normally do).  So I’m still unsure whether its okay to clone to different sized partitions.

The thing is, that I’d have a lot more confidence in what I’m doing if I understood it better.  And to do that, I really need the answers to my original questions.  The main things I need to know are:

  (1)  If I first partition and then bulk-copy (by whatever means) do I corrupt the VTOC?  If not, then why not use dd, which seems pretty straight forward?  The main problem with ufsdump/ufsrestore, is that I have no place to store the backupset.
  (2)  What other files need to be specially treated? JustUNIX's script, for example, does something with vfstab, although I don’t get why.  
  (3)  I also asked for some advise as to how to apportion my new space …  (a) Are there any gottcha’s about maximum partition sizes, or anything similar that I should watchout for?  and (b) Is there any point to cranking up SWAP, if my system is already running fine?  Would it increase performance, for example?
 
I do appreciate you telling me how you would do it … if it were you … but for my own comfort level, I really need direct answers to these questions. Thx
ASKER CERTIFIED SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Addendum...

You can't use dd to clone a disk if you want to change the size of one or more partitions. That would be a block-for-block copy and you'd wind up with the new disk appearing the be the same size as the old since the partition table would be copied as-is. To replicate the system and change partition sizes it is necessary to do file copies of the data onto a new file system of the appropriate size. And it is important to preserve all of the permissions and special file types during the copy. Hence the use of ufsdump/ufsrestore.
If you don't want to use script (well script is a lot easier), you just following jlevie's instructions in http:#13748501

you can use "format" command to find out the disk name for yor new HD, when you
partition the new HD, make sure the new partion size (equal or greater than the source
partition).
Avatar of Eric-K

ASKER

Thanks jlevie ... that's exactly what I needed.

But I do have a couple more questions:
(a) What are the " rm restoresymtable " commands for?
(b) The script referenced earlier was using fssnap (a command
     I wouldn't have known about had I not seen it there ...) and I
     notice you aren't using it.  Do I need it?  I should be okay if
     I'm in single user mode right?
As to (a)... When usfrestore is extracting data from the ufsdump archive it uses restoresymtable as a workspace file. The file isn't needed once the restore completes and can be deleted.

As to (b)... fssnap is a means of getting a frozen snapshot of the file system being dumped to avoid file corruption that can result if a file changes during the dump. The very nature of single user mode ensures that can't happen so fssnap isn't needed.
Avatar of Eric-K

ASKER


Thanks guys, I really appreciate your help.

The prize, of course goes to jlevie, but I do appreciate yuzh's help as well (reading the script you pointed me back-to did help me understand, and even though it wasn't your script in the first place, the pointer was helpful).  I want however, to especially thank you, jlevie, for taking the extra time and effort to spell it all out for me.

I'm giving you guys an A-rating; jlevie gets the buck-fifty, plus I'm gonna add an extra 50 points to split between you as a thank-you bonus.

Well Done!
-Eric