SUMMARY: Re: Moving a boot disc from SunFire v120 to SunFire v210 [Our NIS+ RMS has failed]

LOEWENTHAL Simon sloewenthal at gemini.edu
Tue Jun 28 11:54:02 EDT 2005


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 at 1,f8000000/esp at 0,800000/sd at 3,0:a
rootdev:/pseudo/vxio at 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 at 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 at 1,f8000000/esp at 0,800000/sd at 3,0:a
rootdev:/pseudo/md at 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 at 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 at 3,0/QLGC,isp at 0,10000/sd at 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 at 3,0/QLGC,isp at 0,10000/sd at 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 at 3,0/QLGC,isp at 0,10000/sd at 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 at 3,0/QLGC,isp at 0,10000/sd at 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 at 0:0

SDS/SVM:

/pseudo/md at 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 at 3,0/QLGC,isp at 0,10000/sd at 8,0:a
Path Noted: /sbus at 3,0/QLGC,isp at 0,10000/sd at 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.



More information about the sunmanagers mailing list