Dear Sun-Managers:
I sincerely thank the following Sun Managers who responded to my query on
a seemingly impossible task. I'd also contacted SUN (Valerie Brand) who
sent me info on boot disk, a portion of which will be attached to the
end of this email. Thanks to:
- Casper Dik
- Martin Achilli
- Daniel J Blander
Original Question:
=================
I remember reading a SUMMARY a few months ago on booting the same
system disk running Solaris 2.5 on different HW platforms. It mentioned
something like comparing the pkginfo on different platforms and pkgadd
the missing ones which are required on different platforms.
I'm attempting to build ONE master system disk for different CPUs like
HyperSPARC, UltraSparc, Force5V and Force20VT.
So far I'd tested the following steps, all with total failure:
- Compared the pkginfo list on systems built on a Force5V, Force20,
HyperSparc.
The packages are all identical
- After I built a system from a backup tape made from another platform,
I overwrote the /etc/path_to_inst file with a basic one created for my
target platform, then I wrote a bootblock according to `uname -i`
- When I rebooted the system, I got the following error msg:
...
Hostname: r2psp
mount: /dev/dsk/c0t3d0s6 or /usr, no such file or directory
/sbin/swapadd: expr: not found
WARNING - /usr/sbin/fsck not found.
Most likely the mount of /usr failed or the /usr file system is
badly damaged. Do a boot -b ....
- I did a boot -b but it didn't work
- I rebooted the system to single-user mode (boot cdrom -sw), then
fsck'ed each file system, and rebooted the system--same error msg.
Is this an impossible task? Right now I'm keeping four different
Master System Disks for the different CPUs. To maintain these
with every little change has become quite a tedious task.
=========================================================================
Solution:
========
WARNING: The following method is only good for building a "Master Disk"
which has no third-party driver loaded. If you are rebuilding a system
with third-party drivers, tar a copy of /dev and /devices trees from an
existing system of the same platform to tape and replace the lines below
which copy the device trees from the current cdrom boot.
To boot a system disk which was created on another platform:
> boot cdrom -sw
[After system booted to single user]
# fsck -y /dev/rdsk/c0t3d0s0
# mount /dev/dsk/c0t3d0s0 /a
# cd /a/dev
# rm -rf *
# cd /tmp/dev
# tar cfp - . | (cd /a/dev; tar xfp -)
[errors appeared: ./stderr: failed to get acl count;...stdin...stdout...]
# cd /a/devices
# rm -rf *
# cd /tmp/devices
# tar cfp - . | (cd /a/devices; tar xfp -)
# cd /tmp/root/etc
# cp path_to_inst /a/etc/path_to_inst
[Some /dev links are missing from the above tar]
# cd /a/dev
# ln -s /dev/term/b bd.off
# chgrp -h root bd.off
# ln -s ./fd/2 stderr
# chgrp -h root stderr
# ln -s ./fd/0 stdin
# chgrp -h root stdin
# ln -s ./fd/1 stdout
# chgrp -h root stdout
# sync;sync;sync
[Reboot system from the new platform]
ok boot -r
I have not fully investigated what other links are missing. Would
appreciate anyone who has accomplished similar task warns me of any
shortcomings.
Thank you.
Vicky Lau
vlau@msmail2.hac.com
=========================================================================
Sun's info:
==========
Moving a boot drive ( loaded with the Solaris 2.x operating )
from one machine to another is NOT supported by SunService.
=============
Before calling SunService to report a boot problem after moving your
disk, let's review the issues which in many many cases prevent you from
sucessfully moving a Solaris 2.x boot disk from one machine to another.
The main issues involves hardware addressing and kernel device tree
configuration information. Minor things, such as changing /etc/vfstab,
is not the problem.
The main reason you cannot boot from a drive which is moved from
one machine to another is that hardware address paths are usually
different from one machine to another machine.
Each hardware platform has a hardware device tree which must match the
device tree info saved during installation in /devices and the /dev
directory.
Another reason is that a kernel from one architecture will not 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 ) will not 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 may not be accessable 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 it 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 are mounted. If the mount command for / or /usr fails,
the kernel panics, boot fails, and no reconfiguration takes place.
The program which creates symbolic links in /dev/dsk and /dev/rdsk is found
in the /usr/sbin directory as /usr/sbin/disks.
What if /usr is on the same boot disk as the root file system? Same problem,
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 will fail. Even if you fix these files
by
hand the kernel may panic when the kernel device drivers initialize (open)
their
hardware devices.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:11 CDT