f



Creating a hard drive image - sunos 5.7, scsi 20gb drive, archaic hardware

Hi,

I have never seen this sort of hardware setup before (setup sun and ia
servers before, worked with old hardware before, but never saw this
setup).  What this site has is a rack of boards, that sort of look like
old mainframe multiplexer controller boards ... but htis one rack has a
SPARC board that connects to a box above it, which holds an enclosed
hard drive, about 20 gb.

It reportedly (couldnt connect to it one day to run commands to see
exactly what it has hardware and software wise) is running 5.7 SunOS
under a WinXP OS.

It reportedly has five 4gb partitions, one or more of which may be
virtual partitions (never worked with virtual partitions that I know
of); and is a drive that needs a pin converter (i.e. 58 pin to 68 pin -
may not necessarily be the exact number of pins, but needs a centronics
converter).

What the client wants is a bootable second hard drive attached to the
enclosure, and a disk image made of the first to the second, in case
the first hard drive dies, and cannot afford new hardware I guess.

So a few questions ...
1.  What would be the hardware sequence of steps, i.e. set the scsi
drive jumper to correct setting, attach the centronics converter,
attach the drive and cable, and get ready to go boot the system.
2.  What would be the sequence of software steps, i.e one of the
following -
a. simple copy operation - use dd and ufsdump commands, any others?
b. new fresh drive install and then copy operation - print out vtoc,
run it through fmthard, newfs, dd, ufsdump?
3. Verification that operation was successful?

I'm sort of new to this whole thing, so any help would be appreciated -
since the people who originally set this up have gone out of business,
original installers left company or are unable to get ahold of, etc.

Thanks in advance.

0
5/13/2006 10:26:10 PM
comp.unix.solaris 26025 articles. 2 followers. Post Follow

5 Replies
826 Views

Similar Articles

[PageSpeed] 11

Hello,

So a few mysteries solved on this.  What we have is a sparc board with
a serial cable attached to another piece of the system that enables
hyperterm to interact with the sparc board and the drives unit.  Out f
three disks, one was able to be seen going through an init 0, then at
the ok prompt a probe-scsi sees the disks, and then a boot -r to get
the system up with the drives seen.  Once up and logged in as root, in
format it sees the disks.

Now the question is, how to clone a hard drive.  The drive to be cloned
says it is a 18 Gig drive, and I have a 18 gig drive.  If I were to use
ufsdump or dd to clone it, what are the pros and cons of one over the
other, i.e dd copies not only the data but the drive headers and vtoc,
etc.

Any advice on all this and a good step by step procedure?

Thanks.

James wrote:
> Hi,
>
> I have never seen this sort of hardware setup before (setup sun and ia
> servers before, worked with old hardware before, but never saw this
> setup).  What this site has is a rack of boards, that sort of look like
> old mainframe multiplexer controller boards ... but htis one rack has a
> SPARC board that connects to a box above it, which holds an enclosed
> hard drive, about 20 gb.
>
> It reportedly (couldnt connect to it one day to run commands to see
> exactly what it has hardware and software wise) is running 5.7 SunOS
> under a WinXP OS.
>
> It reportedly has five 4gb partitions, one or more of which may be
> virtual partitions (never worked with virtual partitions that I know
> of); and is a drive that needs a pin converter (i.e. 58 pin to 68 pin -
> may not necessarily be the exact number of pins, but needs a centronics
> converter).
>
> What the client wants is a bootable second hard drive attached to the
> enclosure, and a disk image made of the first to the second, in case
> the first hard drive dies, and cannot afford new hardware I guess.
>
> So a few questions ...
> 1.  What would be the hardware sequence of steps, i.e. set the scsi
> drive jumper to correct setting, attach the centronics converter,
> attach the drive and cable, and get ready to go boot the system.
> 2.  What would be the sequence of software steps, i.e one of the
> following -
> a. simple copy operation - use dd and ufsdump commands, any others?
> b. new fresh drive install and then copy operation - print out vtoc,
> run it through fmthard, newfs, dd, ufsdump?
> 3. Verification that operation was successful?
>
> I'm sort of new to this whole thing, so any help would be appreciated -
> since the people who originally set this up have gone out of business,
> original installers left company or are unable to get ahold of, etc.
> 
> Thanks in advance.

0
James
5/16/2006 12:12:20 AM
If both drives have the same physical capacity, I suggest to use DD,
since this requires much less steps.

0. Pick the time when disk IO is minimal. Ideally, reboot the system
to a single-user mode.

1. Make sure the destination drive is prepared a-la-Sun:
start "format" command, pick the number to select the disk, see if it
complains the drive isn't labelled. If it does, agree to label, and do
another "label" before going out of "format" or changing to another
disk within "format" context.
You shouldn't care how it slices the destination disk - important is
only that slice 2 covers the whole disk,  starting from cylinder 0.
You'll overwrite the VTOC in the next step, anyway

2. run "dd" - this will copy the slicing (partition information, VTOC)
over as well:
dd if=/dev/rdsk/cAtBd0s2 of=/dev/rdsk/cXtYd0s2 bs=1024k

A & B are controller and target IDs of source disk,
X & Y - of the destination one.
"bs=" key is important, if you skip it, dd takes ages. With these keys,
the copy should take 15 to 40 minutes for 18 gb disk.

3. fsck all slices on destination disk that  contain UFS filesystems,
and mount the new root slice to /mnt

4. cp /mnt/etc/vfstab /mnt/etc/vfstab.pre-dd && vi /mnt/etc/vfstab
and replace all entries with cAtB by cXtY (2 entries per line, usually)


5. shutdown to "OK" prompt and run "probe-scsi-all"  and "devalias" to
note the OBP path to new disk.

6. Make a new alias for a new boot disk, for instance:
nvalias newbootdisk /aaa/bbb/ccc/sd@Y,0:a
where Y is SCSI ID of new disk, 0 is LUN (usually 0), a is slice (a to
h),
and /aaa/bbb/ccc/ is a path to SCSI controller the disk is connected
to.  If both disks are on the same SCSI bus, this path is the same as
on source disk.


now, store store the changes and boot from the new disk in single-user
mode to test it:
nvstore
boot newbootdisk -s

Good luck,
Andrei

0
aryzhov
5/19/2006 9:24:51 AM
aryzhov@spasu.net wrote:
> If both drives have the same physical capacity, I suggest to use DD,
> since this requires much less steps.
>
> 0. Pick the time when disk IO is minimal. Ideally, reboot the system
> to a single-user mode.
>
> 1. Make sure the destination drive is prepared a-la-Sun:
> start "format" command, pick the number to select the disk, see if it
> complains the drive isn't labelled. If it does, agree to label, and do
> another "label" before going out of "format" or changing to another
> disk within "format" context.
> You shouldn't care how it slices the destination disk - important is
> only that slice 2 covers the whole disk,  starting from cylinder 0.
> You'll overwrite the VTOC in the next step, anyway
>
> 2. run "dd" - this will copy the slicing (partition information, VTOC)
> over as well:
> dd if=/dev/rdsk/cAtBd0s2 of=/dev/rdsk/cXtYd0s2 bs=1024k
>
> A & B are controller and target IDs of source disk,
> X & Y - of the destination one.
> "bs=" key is important, if you skip it, dd takes ages. With these keys,
> the copy should take 15 to 40 minutes for 18 gb disk.
>
> 3. fsck all slices on destination disk that  contain UFS filesystems,
> and mount the new root slice to /mnt
>
> 4. cp /mnt/etc/vfstab /mnt/etc/vfstab.pre-dd && vi /mnt/etc/vfstab
> and replace all entries with cAtB by cXtY (2 entries per line, usually)
>
>
> 5. shutdown to "OK" prompt and run "probe-scsi-all"  and "devalias" to
> note the OBP path to new disk.
>
> 6. Make a new alias for a new boot disk, for instance:
> nvalias newbootdisk /aaa/bbb/ccc/sd@Y,0:a
> where Y is SCSI ID of new disk, 0 is LUN (usually 0), a is slice (a to
> h),
> and /aaa/bbb/ccc/ is a path to SCSI controller the disk is connected
> to.  If both disks are on the same SCSI bus, this path is the same as
> on source disk.
>
>
> now, store store the changes and boot from the new disk in single-user
> mode to test it:
> nvstore
> boot newbootdisk -s
>
> Good luck,
> Andrei

Andrei,

Thank you for replying, and I will try your procedure.  The only
problem is neither of the two IBM transfer drives for the Sun system
are the same geometry as the two IBM backup drives.  My fear with using
dd is that if the geometry on all drives are not the same, that it
would corrupt the original data on the transfer drives.  The procedure
I was using was the following and I kept running into several problems,
mainly that they are not bootable:

01. SetSCSI jumpers to (next drive seting ID) on the backup drive
02. Connect SCSI cables to SCSI backup drives and transfer drives
(while power is off to the SPARC board and the drive unit)
03. Power on SPARC board
04. Power on Drive unit
05. Login as root
06. Type format and press retrun
07. If backup drive does not show up in format:
     a.  Press CRTL-D and then press return
     b.  Type init 0 and press return
     c.  When machine reboots and you are at ok prompt:
         1.  Type probe-scsi and press return
         2.  Type boot -r and press return
     d.  When machine reboots, login as root
     e.  Type /usr/sbin/drvconfig and press return
     f.   Type /usr/sbin/devlinks and press retrun
     g.  Type /usr/sbin/disks and press retrun
     h.  Type /usr/ucb/ucblinks and press return
     i.  Type init 0 and press return
     j.  At ok prompt type boot -r and press return
     k.  Login as root
     l.  Type format and press return, drive should show up now, if not
it may be a bad drive
08.  Type format and press return
09.  When format and verify are done, type label and press return,
press return after label
10.  Type partition and press return
     a.  Second slice is always entire disk:
          1.  Type 2, press return twice, type in full disk size and
press return
     b.  Type in 0 and press return, root, return, return 2x, size of
root, return
     c.  Type in 1 and press return, swap, return, return 2x, size of
swap, return
     d.  Type in 5 and press return, var, return, return 2x, size of
var, return
     e.  Type in 6 and press return, usr, return, return 2x, size of
usr, return
      f.  Type in 7 and press return, home, return, return 2x, size of
home, return
11.  Type print to see partition table, if done type label, return
12.  Type quit and press return (twice for both)
13.  Type newfs /dev/rdsk/c#t#d#s# (replace #'s with appropriate
numbers), for each partition slice
14.  Type fsck -F ufs -y -o b=32 /dev/rdsk/c#t#d#s# (replace #'s with
appropriate numbers), for each partition slice
15.  Make sure the two steps above have been followed for each slice
16.  Type swap -a /dev/dsk/c#t#d#s1
17.  Type swap -l to see swap partition activated
18.  Type:
  mkdir /mnt/backup
  for i in home var usr root home; do
    mkdir /mnt/backup/$i
  done
  ls -l /mnt #(all should show up, if not or any errors mkdir each on
seperate line)
19.  The root, var, home, usr directories should all show up in
/mnt/backup via ls on dir
20.  Type /usr/sbin/installboot /usr/platform/`uname
-i`/lib/fs/ufs/bootblk /dev/rdsk/c#t#d#s2
21.  Type init 0 and press return
22.  At ok prompt power off drive ubit and sparc board
23.  Attach SCSI cable so only backup drive is attached
24.  Turn on drive unit and sparc board
25.  At ok prompt type boot -s
26.  If this does not boot the drive note that, if so note that; repeat
steps 21 and 22
27.  Reattach cables
28.  Power on sparc board and drive unit
29.  Login as root and then init S
30.  Login as root if prompted
31.  Type:
  mkdir /mnt/backup/tmp
  mount /dev/dsk/c#t#d#s0 /mnt/backup/root
  mount /dev/dsk/c#t#d#s1 /mnt/backup/tmp
  mount /dev/dsk/c#t#d#s2 /mnt/backup
  mount /dev/dsk/c#t#d#s5 /mnt/backup/var
  mount /dev/dsk/c#t#d#s6 /mnt/backup/usr
  mount /dev/dsk/c#t#d#s7 /mnt/backup/home
  find / -mount | cpio -p -v -m -u -d -c /mnt/backup/root
  find /tmp -mount | cpio -p -v -m -u -d -c /mnt/backup/tmp
  find var -mount | cpio -p -v -m -u -d -c /mnt/backup/var
  find /usr -mount | cpio -p -v -m -u -d -c /mnt/backup/usr
  find /home -mount | cpio -p -v -m -u -d -c /mnt/backup/home
32.  All data should be copied over successfully, there are three
alternative methods to clone hard drives:
  a.  Use of rsync if installed to copy over data
  b.  Use of dd if disk geometry is same on each drive
  c.  Use of ufsdump 0uf - / | ufsrestore -rf -
33.  This should have been done before, but on /backup/etc, edit fstab
and mnttab files via vi so that it shows one of the two cases:
  a.  Only the transfer drive is mounting first and then the backup
drive
  b.  Only the backup drive is mounting - preferable method
34.  Repeat steps 21-25 and test data

Thanks,

James

0
James
5/20/2006 5:02:35 PM
James,

that all sound reasonable, but I would strongly recommend using ufsdump
| ufsrestore
rather than find | cpio, at least for root filesystem

Also, after ufsrestore or cpio, you have to run installboot, which
calculates the physical offset of
ufsboot binary (it is always different whenever you re-create the
filesystem and do restore in separate steps).
You wouldn't need to run installboot  with dd method.

Lastly, in Solaris it's not fstab but vfstab, besides, mnttab is not
supposed to be edited by hand
(solaris re-creates it at every reboot, anyway)

You probably shouldn't care about geometry differences as long as
capacities are equal.
SCSI will hide real spindle geometry from you,  anyway.
In my experience, all 18 gb SCSI disk, after being auto-labelled by
Solaris, show up as SUN18G,
with the same geometry.

Regards,
Andrei

0
aryzhov
5/21/2006 6:53:21 PM
In comp.unix.solaris aryzhov@spasu.net wrote:
> Also, after ufsrestore or cpio, you have to run installboot, which
> calculates the physical offset of
> ufsboot binary (it is always different whenever you re-create the
> filesystem and do restore in separate steps).

'installboot' is a shell script that runs 'dd' to copy the blocks in
place.  I see nothing in that script that "calculates" a physical offset
other than the fact that it always starts with block 1 of the slice.
There is no difference between installs.  

-- 
Darren Dunham                                           ddunham@taos.com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >
0
Darren
5/22/2006 7:20:18 PM
Reply: