My original question was:
> Dear colleagues:
>
> I am trying to swap a Sparc4 disk into a Sparc5. Silly me, I thought
> that since they were in the same machine family, I could just take one
> disk out and put it in the other machine. As you can guess (since I'm
> writing this) this does not work. I have tried a number of things to
> get the thing to work, including copying /dev from one disk to the other,
> copying /platform, /devices, even /kernel. At this point I am simply
> flailing blindly at a problem which I apparently don't understand well
> enough, and my searches on Sun's database and the sun-managers archive
> came up blank. Can anyone offer concrete advice?
>
> I will summarize.
>
> Thanks!
> Charles
I was attempting to swap a Solaris 2.5 bootdisk from a Sparc4 to a
Sparc5. To make a long story short, it never worked for me. As little
as I like to admit defeat, and as much as I learned in the process, I
just couldn't justify spending more time on it. I won't go so far as to
say that it can't be done, but we tried many things, none of which worked.
Here is a (probably partial) list of things we attempted:
1. Copy /dev, /devices, /system, /kernel, and /etc/*_to_* from a working
Sparc5 (which was 2.5.1, not 2.5). 'boot -r'
2. As (1), and ran 'installboot' (even though the file should be the same).
3. As (1), but with 'boot -av'.
4. As (2), but with 'boot -av'.
Somewhere in these steps, something happened that did not allow us to boot
the disk in the Sparc4 after copying back the old files.
5. Removed all of /dev, /devices, and /etc/path_to_inst, used Sparc5 /system
and /kernel. 'boot -av'
6. Removed all of /dev and /devices, used Sparc5 /system, /kernel, and
/etc/*_to_*. 'boot -r'
7. Did:
echo "#path_to_inst_bootstrap_1" > /etc/path_to_inst
boot -r
And we probably tried some combinations not listed here. We finally just got
a new disk, installed 2.5.1 on it, and mounted the old disk as /.old, /usr.old,
etc... I am in the process of moving things over to get the configuration
back the way it was, which is what I was trying to avoid.
C'est la vie.
Anyway, the people kind enough to respond and their responses are listed below.
Regards,
Charles
------------------------------------------------------------------
Charles Homan Applix, Inc.
Network Systems Administrator 112 Turnpike Rd.
choman@applix.com Westboro, MA 01581
------------------------------------------------------------------
From: Charles Gagnon <charles@Grafnetix.COM>
I would probably, at this point, boot from the CDROM, wipe the /dev/ and
/devices completely. Then reboot making sure it reconfigures.
Make sure you keep a copy of /dev and /devices somewhere.
It might work.
-----
From: Andrew Mellanby <mel@maths.abdn.ac.uk>
My feeling is that it should not be a problem (provided that is is
physically connected correctly). Simply do:
reboot -- -r
-----
From: amy.hollander@amp.com (Amy Hollander)
are you running solaris?
you will need to reconfigure
# touch /reconfigure
# reboot
-----
From: nirger@Vest.Sdata.No (Birger A. Wathne)
Check all files matching /etc/*_to_*
There are three files that deal with mapping between
major device numbers and files, numbering of controllers, etc.
If you copy in the correct default files for a sparc 5 here, in addition
to /dev and /devices you should be able to do a reconfiguration boot.
I have never tried it, but I would suspect you need to update
these files.
-----
From: cgo@dsi.elis.fr (Cyril GODON)
The problem you did not care is the path_to_inst file.
ss4 and ss5 have the same kernel (I think) but don't name
their components the same way.
I think the only thing you should do is :
rm /etc/path_to_inst (before stopping the stations)
swap the disks
boot -av
answer all the questions with enter (default value)
at the path_to_inst step, it will ask you :
~ which path_to_inst file to take ?
answer /dev/null
(it will see it empty and rebuild it)
or (I saw it on the newer eeproms)
~ do you want to rebuild a path_to_inst file ?
answer yes
I never did it between ss4 and ss5 but I did it with no problem
between others sun4m platforms.
This step is necessary and I don't think there should be other
ones between so similar platforms.
-----
From: Casper Dik <casper@holland.Sun.COM>
Have you done a "reconfigure" reboot? That should at least get it to
single user.
Anyway, what you need to do is:
echo "#path_to_inst_bootstrap_1" > /etc/path_to_inst
and then do a "boot -r".
-----
From: "K.Ravi" <RAVKRISH.IN.ORACLE.COM.ofcmail@in.oracle.com>
-----
From: Jim Harmon <jharmon@telecnnct.com>
>From morbid curiousity, why?
Ok, here's just some of what i know as a one-time Field Engineer. It
probably won't help much, but may explain why what you tried to do
failed. As for solutions, boot the machine with a delivery CD and
reinstall the operating system on the drive. You should be able to do
that without destroying the data that's also on the disk.
If that's a problem, do you have a backup of the disk from before trying
to move it to the new box?
Ok, my thoughts on the problem:
Although any given family of CPU's normally maintain some
binary compatibility, the manufacturer, (particulary a
proprietary manufacturer, like Sun) delight in making the
binary architecture just too much of a percentage incompatible
to be able to migrate s/w up to the nexe level without
recompiling the majority of the binaries.
The compiler will almost always make just enough change to make
the two versions completely incompatible with each other, so
the new binary won't work on the old machine either.
There are exceptions, as in everything else in life, but the
exceptions are truely minority items.
An example would be if you intentionally compiled all your
"Solaris 2.5" based applications in "compatibility mode", where
the compiler builds-in alternate code and switches to allow a
program compiled on 2.5 to run on 2.4. This, however, doesn't
have anything to do with CPU compatibility, only S/W OS
compatibility. The compiler still has to differentiate between
a Sun4c and a Sun4m.
The up side is that if you can upgrade the OS on the drive to be one
compatibile with the SPARC5, the data and other programs on the disk
SHOULD work, if the OS is the same version, such as Solaris 2.5 was on
the S4, and what you planned to have on the S5.
Hope that offers some reasoning and some hope...
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:51 CDT