From: LOEWENTHAL Simon (sloewenthal@gemini.edu)
Date: Tue Jun 28 2005 - 11:54:02 EDT
Thanks to Joon Martin Hansen, Johnney Chang and special thanks to Ken
Rossman.
[Ken Rossman:]
"You will not need to rewrite any boot block info. If there are no
external
disks or storage arrays that the machine connects to (i.e. only the
internal
disk or disks drove the machine's functions), then you are in fairly good
shape, I'd say. Both are SPARC based systems with SCSI. Only thing I can
think of offhand is that the info in /etc/path_to_inst might not be
correct
across both machines, so you may need to move that file out of the way,
and do a "boot -asw", answering with "/dev/null" when it asks where your
path_to_inst file is. I believe that causes Solaris to rebuild the file. "
(Sulsolve doc:
http://sunsolve.sun.com/search/document.do?assetkey=1-9-79851-1)
Following Ken's pointers I looked on Sunsolve, and found the following
documents. After I had done this the network interface wouldn't plumb
so a reboot -r once more helped solve it. [Thanks Joon].
The RMS came back up with out anymore problems and the NIS+ clients all
snapped back into life.
** This document provides the steps necessary to rebuild the
path_to_inst file on a system which is currently running in multi-user
mode (run level 3). This document can be used with root under Veritas
Volume Manager control, Disksuite/Solaris Volume Manager control, or if
root is a simple slice.
If there are problems with device path creation using a reconfiguration
boot, *devfsadm*, or *drvconfig* it may be necessary to rebuild the
*path_to_inst* file to solve the problem. It is possible to easily
rebuild the *path_to_inst* file gracefully by first making note of the
root device, and then by using specific options during boot.
The first step when needing to rebuild the *path_to_inst* file is to
make a note of the current root device. First, the command *"df -k"*
needs to be used to determine if the root filesystem is under Veritas
Volume Manager (VxVM) control, Disksuite/Solaris Volume Manager
(SDS/SVM) control, or is just a simple slice. The only line that needs
to be looked at is the line for the root (/) filesystem. The command
output for all three configurations are as follows:
VxVM:
# df -k
Filesystem kbytes used avail capacity Mounted on
/dev/vx/dsk/rootvol 6050021 5815862 173659 98% /
SDS/SVM:
Filesystem kbytes used avail capacity Mounted on
/dev/md/dsk/d0 6050021 5815862 173659 98% /
Simple Slice:
Filesystem kbytes used avail capacity Mounted on
/dev/dsk/c2t8d0s0 6050021 5815862 173659 98% /
If the root filesystem is under either VxVM control or SDS/SVM Control,
the setting of the rootdev entry in the /etc/system file needs to be
noted. By using the *"grep"* command, this rootdev entry can be found
easily. For both VxVM and SDS/SVM, an example of using the grep command
to find this entry are as follows:
VxVM:
# grep rootdev /etc/system
* rootdev: Set the root device. This should be a fully
* rootdev:/sbus@1,f8000000/esp@0,800000/sd@3,0:a
rootdev:/pseudo/vxio@0:0
set vxio:vol_rootdev_is_volume=1
#
NOTE: The line that needs to be noted is the line beginning with rootdev. In the above example, the line *"rootdev:/pseudo/vxio@0:0"* should be the line noted.
SDS/SVM:
# grep pseudo /etc/system
* rootdev: Set the root device. This should be a fully
* rootdev:/sbus@1,f8000000/esp@0,800000/sd@3,0:a
rootdev:/pseudo/md@0:0,0,blk
#
NOTE: The line that needs to be noted is the line beginning with
rootdev. In the above example, the line *"rootdev:/pseudo/md@0:0,0,blk"*
should be the line noted.
If the root filesystem is a simple slice, the physical path to this
slice needs to be noted. This can be found by using the *"ls -l"*
command on the */dev/dsk* entry for the slice used for the root
filesystem. From the example above, the slice *c2t8d0s0* is the root
slice, so an example the output using *"ls -l"* from this system is as
follows:
# ls -l /dev/dsk/c2t8d0s0
lrwxrwxrwx 1 root root 48 Jun 4 2004 /dev/dsk/c2t8d0s0 -> ../../devices/sbus@3,0/QLGC,isp@0,10000/sd@8,0:a
NOTE: The path that this is pointing to needs to be noted. The path to
be noted is following the *"../../devices"* part of the link which is
*"/sbus@3,0/QLGC,isp@0,10000/sd@8,0:a"* in our example.
Once the path to the root filesystem has been determined, either with or
without volume management, the next step is to move the current
*path_to_inst* out of the way as follows:
# mv /etc/path_to_inst /etc/orig.path_to_inst
** Once the *path_to_inst* file has been moved out of the way, we can
then begin the reboot process. First, we need to run an init 0 to drop
the system to the *ok* prompt:
# init 0
INIT: New run level: 0
The system is coming down. Please wait.
System services are now being stopped.
Stopping agent component
Jan 5 11:43:14 server agent[1199]: syslog Jan 05 11:43:14 agent {received software termination signal}
Jan 5 11:43:14 server agent[1199]: syslog Jan 05 11:43:14 agent *** terminating execution ***
platform component is not running
Print services stopped.
Jan 5 11:43:37 server syslogd: going down on signal 15
Request is in process..
VEA Server is shutting down .
Server was shutdown successfully
The system is down.
syncing file systems... done
Program terminated
{4} ok
** Now, run *"boot -ar"* from the *ok* prompt:
{0} ok boot -ar
Resetting...
Software Power ON
Clock board TOD does not match TOD on any IO board.
Clock board TOD does not match TOD on any IO board.
8-slot Sun Enterprise 4000/5000, No Keyboard
OpenBoot 3.2.27, 320 MB memory installed, Serial #7923805.
Copyright 2000 Sun Microsystems, Inc. All rights reserved
Ethernet address 8:0:20:78:e8:5d, Host ID: 8078e85d.
Rebooting with command: boot -ar
Boot device: /sbus@3,0/QLGC,isp@0,10000/sd@8,0:a File and args: -ar
Enter filename [kernel/unix]:
Enter default directory for modules [/platform/SUNW,Ultra-Enterprise/kernel /platform/sun4u/kernel /kernel /usr/kernel]:
Name of system file [etc/system]:
SunOS Release 5.8 Version Generic_117350-02 32-bit
Copyright 1983-2003 Sun Microsystems, Inc. All rights reserved.
/
The /etc/path_to_inst on your system does not exist or is empty.
Do you want to rebuild this file [n]? y
root filesystem type [ufs]:
Enter physical name of root device
[/sbus@3,0/QLGC,isp@0,10000/sd@8,0:a]: <ENTER ROOTDEV COPIED ABOVE HERE>
** At this previous prompt, you want to enter the correct rootdev path
which had been noted previously. If root was created on a simple slice,
you may simply need to press the [Enter] key to accept the default. In
our examples above, given the different types of root filesystems, the
value entered at the above prompt would be the following:
VxVM:
/pseudo/vxio@0:0
SDS/SVM:
/pseudo/md@0:0,0,blk
Simple Slice:
NOTE: Check the path listed as the default at the prompt and compare it
to the path noted previously before the reboot.
Default listed: /sbus@3,0/QLGC,isp@0,10000/sd@8,0:a
Path Noted: /sbus@3,0/QLGC,isp@0,10000/sd@8,0:a
Since these are the same, we can accept the default above by simply
pressing the [Enter] key.
Allow the boot process to continue, and once completed, there should be
a new *path_to_inst* created. Verify this by running the following
command and checking the timestamp:
# ls -l /etc/path_to_inst
** The timestamp should reflect when the file was created, and if this
is correct, then the *path_to_inst* has been rebuilt.
-- ISG/Gemini/AURA ORIGINAL MSG On Jun 28, 2005, at 10:16 AM, LOEWENTHAL Simon wrote: Today, being Monday, I was greeted with a major h/w failure. Our NIS+ root master has turned itself into a brick. Its dead. Its a SunFire v120. We have a spare SunFire v210 and I would like to take the dead machine's boot disc out of the V120 and put into the V210. I suspect that this is not such a simple swp it to the new machine task, and that I will have to rewrite some boot block to the disc so that the V210 understands whats going on, or something similar. I have put the disc into the v210, but it fails at boot after trying to plumb the interfaces (they are different), it next fails because it cannot mount any partitions. Does anybody know what changes I might have to make and how should I go about it? Regards, S. _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagers
This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 23:30:59 EDT