Thanks to all who replied: Justin Stringfellow Tony Walsh Stan Pietkiewicz Mike Demarco John Riddoch Rob Forsey Phil Rainey Mike Scott Steve Sandau Dave Mitchell Darren Moulding Most suggestions were to re-examine the /etc/vfstab to make sure that the device and the device to fsck were consistent. However, top award for this one goes to Mr Tony Walsh for his SUPERB instructions on eradicating shadow devices from the PROM, posted, for your viewing pleasure below! The first experiment is to shut the machine down to the OBP and issue the following commands at the OBP prompt. OK> setenv auto-boot? false OK> setenv diag-level max <-- This may not work depending on you OBP version OK> setenv diag-switch? true OK> power-off Now use the soft power button on the front of the U10 or use the power switch to turn it on. You will now have to wait several minutes while the extended diags complete. When they do finish, issue the following commands and reboot. OK> setenv diag-level min OK> setenv diag-switch? false OK> reset-all Wait for the OBP prompt to return and issue the following. OK> setenv auto-boot? true <-- You could leave this out if you want. OK> boot Now wait for the offending message. If it does not reoccur, then this procedure has just cleared a shadow device from the OBP device tree which was being seen by the OS and interpreted as a drive needing attention. Also if it does not reoccur, this is a sign that the OBP level you have is a little old and is probably full of bugs that are capable of presenting these 'shadow devices' (so upgrade the OBP). A possible reason for this device difference, is that when you replaced the second drive you may have set (or left) jumpers on the drive that indicate a Master/Slave IDE setup instead of the 'Cable Select' setup favoured by Sun. You may also have changed the cabling around so that the new drive is on the second IDE channel and not the primary channel. If none of the above works, try the following as a second experiment. First move aside or remove the file called /etc/path_to_inst and /etc/path_to_inst.old. Then issue 'reboot -- -svar' or 'boot -svar' from the OK prompt and respond to the questions as required (Mostly just hit enter). When asked if you want to rebuild the path_to_inst file, reply yes and carry on. This process should rebuild the path_to_inst file from scratch and rebuild the OS device tree. How cool is that??? Well cool! Thanks again to all! Callum A. Hughes Unix Systems Engineer Securicor Information Systems t: 01249 - 665 -396 e: callum.hughes@sis.securicor.co.uk ********************************************************************** The information contained in this e-mail message is intended only for the individuals named above. If you are not the intended recipient, you should be aware that any dissemination, distribution, forwarding or other duplication of this communication is strictly prohibited. The views expressed in this e-mail are those of the individual author and not necessarily those of Securicor Information Systems Limited. Prior to taking any action based upon this e-mail message you should seek appropriate confirmation of its authenticity. If you have received this e-mail in error, please immediately notify the sender by using the e-mail reply facility. ********************************************************************** _____________________________________________________________________ This message has been checked for all known viruses on behalf of Securicor Information Systems by the MessageLabs. For further information visit http://www.messagelabs.com or Email: mailsweeper.info_at_sis.securicor.co.uk _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagersReceived on Thu May 9 09:24:26 2002
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:42:42 EST