SUMMARY: FSCK error for non existant file system

From: Callum Hughes <>
Date: Thu May 09 2002 - 09:13:37 EDT
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
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
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

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 or Email:
sunmanagers mailing list
Received 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