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/sunmanagersReceived on Wed Jun 29 10:58:14 2005
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:43:49 EST