NOTE:  The information in this article applies to Solaris 2.x systems only.

CAUTION:
Moving a boot drive (loaded with the Solaris 2.x operating system)
from one machine to another is NOT supported by SunService.
                               =============            

Before calling SunService to report a boot problem after moving your
disk, review the issues which in many cases prevent you from
successfully moving a Solaris 2.x boot disk from one machine to another.

The main issues involve hardware addressing and kernel device tree
configuration information.  Minor things, such as changing /etc/vfstab,
are not the problem.

The main reason why you cannot boot from a drive that is moved from
one machine to another is that hardware address paths are usually
different from one machine to another.
 
Each hardware platform has a hardware device tree which must match the
device tree information saved during installation in /devices and the /dev
directories.

Another reason is that a kernel from one architecture cannot boot
on a machine of a different architecture.  Customers often overlook these
architecture differences (Sun 4/4c/4m/4d/4u).  A boot drive moved
from a SPARCstation 2 (sun4c architecture) cannot boot on a 
SPARCstation 5 (sun4m architecture).

Unless the two machines on which you are moving boot disks are identical,
including Sbus cards, the boot device might not be accessible during boot.
The kernel cannot open a hardware device if the device tree information
in /devices and /dev is incorrect.

Why doesn't "boot -r" or "touch /reconfigure" and reboot fix this?

The PROM boot command loads the ufsboot program, which in finds and loads the
kernel.
The kernel starts init, which runs the initialization scripts in /etc/rcS.d and

/etc/rc2.d.

The reconfiguration processing is performed in /etc/rcS.d/S60devlinks.
A reconfiguration boot doesn't actually start the process until after the 
/ and /usr directories are mounted.  If the mount command for / or /usr fails, 
the kernel panics, boot fails, and no reconfiguration takes place.
The program that creates symbolic links in /dev/dsk and /dev/rdsk is
in the /usr/sbin directory as /usr/sbin/disks.

What if /usr is on the same boot disk as the root file system?  The problem is
the 
same - the symbolic link in /dev/rdsk and /dev/dsk must exist in 
order to mount /usr.

If /dev and /devices in your boot drive's root file system don't match exactly
(especially for / and /usr),  boot fails.  Even if you fix these files by
hand, the kernel might panic when the kernel device drivers initialize (open)
their
hardware devices.


To view what your device tree information should be on a given hardware
platform:

  ok boot cdrom -s
  # ls -lR /devices
  # ls -lR /dev


You can try to fix /devices and /dev by hand (and your mileage will vary
depending
on experience).  Many customer express frustration from the time wasted booting,

mounting the root file system, and hacking device tree info, only to have the
kernel panic during boot. It may be best to do some planning and plan your
fresh
installation now.

Just because /etc/vfstab has been changed doesn't mean the OS can find the
disk.
The solution is to re-install the OS using jump-start or by booting from
CD-ROM.

SunOS systems are easy to do, because the /etc/fstab, /dev entries, and kernel
can all be modified without regard to the setup of the source system; either
before taking the source system down, or booted from miniroot on the new
system.