SUMMARY: Boot disk exchange - Sparc 5 & Sparc 20

Date: Fri Feb 02 1996 - 10:51:01 CST

SUMMARY: Boot disk exchange - Sparc 5 & Sparc 20
Original statement:
> We're having a problem exchanging boot disks between a
>Sparc 5 and a Sparc 20. Neither machine can read the
>other's boot disk. It seems to be some kind of problem
>in the /devices directory.
> Each machine is running Solaris 2.4. (This does work
>under SunOS 4.4.)
> Does anyone know of a way to resolve this, other than
>reinstalling the operating system?

Several people suggested rebooting with "boot -r", but I had
neglected to mention in my original post that we had already
tried that to no avail. A few others said they had encountered
the same problem and were unable to resolve it.
More specific comments and suggestions follow.

Daniel Blander (
  Been there done that - different kernels is the issue (remember one
  is a MicroSPARC the other a SuperSPARC so the kernels are in-compatible).
  Someone did mention a method for dealing with this, but I believe it
  included kernel reconfig. Basically it boils down to the /kernel
  directory....and new devices for the CPU....

Patrick Wolfe (
  I use a single disk to stage new servers, and have separate partitions
  for the Sparc classic, Sparc 5 and Sparc 20 (plus two left over for
  whatever platform we next switch to, probably Ultra).
Anatoly Lisovsky (
  It is possible.
  Check archives of Sun-managrs' Summaries.
Stephen Harris (
  Check out and

Sean Ward ( said:
  On Solaris 2.x, there is a file /etc/path_to_inst, which tells where
  all the /devices links are. This file is very hardware dependent. If you
  wanted to swap disks, you would have to copy the correct version of that file
  in order for things to work properly. Even then, you may still have problems.

Rick Kelly (
  The 5 and the 20 use different mappings for their devices.
  This is affected by /etc/path_to_inst.

Andy McCammont (
  copy /etc/path_to_inst from a working SS20 and boot -r

Casper Dik (
  Before installing the system do:
  # mv /etc/path_to_inst /etc/path_to_inst.otherhw [*DONT* use .old as suffix ]
  # echo '#path_to_inst_bootstrap_1' > /etc/path_to_inst
  then reboot with "-r".

Richard S. Goldstein (
    when you install the os on your machine (for the first time) /devices
  is config'd to point to real hardware addresses ala openboot prom. When
  you move the disks from one machine to another (even between similar
  machines) there is not guarantee that the hardware addresses will be
  the same.
    SUN do not support what you are trying to do, but the answer is yes, you can
  work around this. You will need to boot from CD. After the system comes
  up, delete everything in /dev and /devices. Also, move your /etc/path_to_inst
  file to something else for safe keeping.
    WAIT...I lied :-) after you are up on CD mount the drive that needs to be
  "modified" (your root disk). Delete dev and devices from this mount point
  NOT /dev and /devices. Again, rename etc/path_to_inst under this mount point
  as well.
    tar (or copy or whatever) the /dev stuff to /othermountpoint/dev and
  /devices to /othermountpoint/devices. Then boot -rap. This will rebuild
  the devices directory with the correct pointers to hardware addresses.

Glenn Satchell (
  Boot the system from the Solaris 2.4 CD with the target disk attached.
  Mount the / partition on, say, /a, eg:
      mount /dev/dsk/c0t3d0s0 /a
  Remove the /devices, eg:
      rm -r /a/devices
  Copy the /devices from the booted image, eg:
      cd /; tar cf - devices | (cd /a; tar xf -)
  Run drvconfig, note the undocumented flag to drvconfig, but it is there
  is you run strings on the drvconfig binary, eg:
      drvconfig -r /a/devices -p /a/etc/path_to_inst
  Run disks to set the links in /a/dev/dsk, eg:
      disks -r /a
  Now you should unmount /a, eg:
      cd /
      umount /a
  Run fsck if you feel like it, eg:
      fsck /dev/rdsk/c0t3d0s0
  and then reboot an dhopefully all should be well, eg:

In making this summary I think I omitted part of someone's message.
Apologies, also to anyone I may have missed.

Because the machines in question have been in constant use since I
posted, I haven't been able to experiment with the suggestions.
When I can, I'll follow up my results.

Thanks very much to all who replied.

				Jim Campobello

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:52 CDT