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 (Daniel.Blander@acsacs.com):
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 (pwolfe@mcs.com):
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 (Anatoly.Lisovsky@kamaz.kazan.su):
It is possible.
Check archives of Sun-managrs' Summaries.
Stephen Harris (sweh@mpn.com):
Check out http://www.latech.edu/sunman.html and
http://sunsite.unc.edu/sun/inform/sun-managers-summary.html
Sean Ward (seanw@amgen.com) 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 (rmk@ed.ray.com)
The 5 and the 20 use different mappings for their devices.
This is affected by /etc/path_to_inst.
Andy McCammont (and@morgan.com):
copy /etc/path_to_inst from a working SS20 and boot -r
Casper Dik (casper@holland.sun.com):
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 (richg@pencom.com):
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 (glenn@uniq.cem.au):
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:
reboot
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 campo@calspan.com
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:52 CDT