SUMMARY: cannot open /etc/path_to_inst

From: Fabio Kirchenchteyn <>
Date: Wed May 16 2001 - 09:02:40 EDT
Thankx to:
Osama Ahmed <> <>
Vipin Sharma - EDS Datacenter Contractor <Vipin.Sharma@Sun.COM>
Jon Andrews <>
Hans Engren <>
Lumpkin, Buddy <>
Anil Sreedharan <>
Trevor Paquette <>
Vishal P Dhuru <>
Sriram V (OCS-BLRAKS-TSG) <>
Karthikeyan S (OCS-DELRO-AVS) <>
D.A. Muran-de Assereto <>
Satish GA <> <> <>
Panesar, Tajinder <>
comp question <>
Guys,Gurus,you are simple the best!
and this is  for sure the best maillist in the whole net!
so sorry if i am forgetting someone ,lot of mails received at home....
i remember only Dana (-:

I tried boot -r
tried restauring file from backup,tried boot in single mode from cdrom
,mount / and copy file from cdrom nothing happened
rebooted the machine from the key!i mean power off and power on!and the
system was fine,except Kde was halting the system,rebooted and go from
command line...i am fine....using the time...

except this suiggestions i tried ,people suggest:

boot -asw,boot -r,boot -bar and at the ok prompt /vpd(dont know what is /vpd

two different answers:
came from Buddy and Trevor :

First, try to boot -a

It should ask you if it should recreate a /etc/path_to_inst file. It might
ask for the location, if it does that put /dev/null.

Finally, if that doesn't work, do this:

boot from cdrom
mount /dev/dsk/c.t.d.s. /a

locate path_to_inst file under /tmp with find

drvconfig -r /a/devices -p /tmp/path/to/path_to_inst
devlinks -r /a/devices
disks -r /a/devices
touch /a/reconfigure
cp /tmp/path/to/path_to_inst to /a/etc/path_to_inst

Note that devices might move around if you use this method depending on the
order you populated cards in the past (this is exactly what
/etc/path_to_inst tries to preserve).

Hope this helps.


Sun infodoc 15626

Information on /etc/path_to_inst

Relevant files:

Manual pages:
% man path_to_inst

Infodocs on SunSolve:
infodoc: 2224
infodoc: 15019
infodoc: 15010
excerpts from intinfod: 14269

95) When is it NOT a good idea to boot -r?

Be very careful doing a boot -r on a system with disks under Solstice
Disk Suite control.

Disks running under Solstice Disk Suite control are expected to be in a
certain place.  SDS uses the hardware device tree (/devices/...) to find
its devices.  If the controller of those disks has been moved to another
slot then SDS will not find its disks.

Sbus cards, even disk controllers, can be added, to sbus slots numbered
either below or above that of the first one.  There is no problem as
long as the /etc/path_to_inst file remains intact.  The main
issue is whether or not the controller of the SDS-controlled disks
appears in the same slot and are found in the same order as before
(the first controller found before is still the first controller found,
etc).  The order will be the same if the path_to_inst file is left
intact, because the system scans for new devices only, and will not
remove or reorder devices that it knows already exists.

If the controller card to SDS controlled-disks must be moved or the
path_to_inst file must be removed for some reason, the internal tables
used by SDS to find its disks must be regenerated in order to prevent
data corruption.  Disks must be removed with the "metaclear" command
and readded (using their new locations) with the "metainit" command in
the same order as they were in the tables before.

Disks under Veritas control pose no problem, because Veritas configures
itself automatically, going out and checking each disk for placement,
each time it is started.  If disks are moved around, Veritas will find
each of them wherever it is, by looking everywhere for it.

"Regular" disks (not metadevices) are not a problem with boot -r.
However, as with any file systems, the vfstab might need to be updated with
proper device numbers to mount moved disks at their proper place
in the file system tree.

103) What is a major device number?  A minor device number?

Every device driver has a corresponding major number.  This number is
used by the operating system to key into the proper device driver
whenever a device special file corresponding to one of the devices it
manages is opened.

All devices managed by a given device driver contain a unique minor
number.  Some drivers of pseudo-devices (software entities set up to
look like devices) create new minor devices on demand.

Together, the major and minor numbers define uniquely a device and its
device driver.

Device special files have a unique output when listed with the "ls -l"
command, which shows major and minor numbers:

cd /devices/pseudo
ls -l pts@0:1*

crw--w----   1 schwartz tty       24,  1 Sep 11 14:46 pts@0:1
crw--w----   1 schwartz tty       24, 10 Nov  9  1995 pts@0:10
crw--w----   1 schwartz tty       24, 11 Nov  8  1995 pts@0:11
crw-r--r--   1 root     sys       24, 12 Sep  9  1995 pts@0:12
crw-r--r--   1 root     sys       24, 13 Sep  9  1995 pts@0:13
crw-r--r--   1 root     sys       24, 14 Sep  9  1995 pts@0:14
crw-r--r--   1 root     sys       24, 15 Sep  9  1995 pts@0:15
crw-r--r--   1 root     sys       24, 16 Sep  9  1995 pts@0:16
crw-r--r--   1 root     sys       24, 17 Sep  9  1995 pts@0:17
crw-r--r--   1 root     sys       24, 18 Sep  9  1995 pts@0:18
crw-r--r--   1 root     sys       24, 19 Sep  9  1995 pts@0:19

                major number -----^^  ^^
                                      ||----- minor number

All pts are managed by the pts driver, which is major number 24 in this
example.  Minor numbers are listed after the comma.

104) How does the mechanism to add device software to a Solaris system
work?  What are the steps involved in adding a device?

Drivers for third-party devices are placed in /usr/kernel/drv, along
with any configuration file that the device might have.  Drivers and
configuration files might be placed in /kernel/drv instead, but this is
not recommended as this causes headaches if the driver crashes the
system on bootup.  Faulty drivers that crash the system but which are
in /usr/kernel/drv can be excluded from the boot sequence, if the system
is booted with the "-a" option (interactive boot) and /usr/kernel is
excluded from the module load path.

After installing the device driver and configuration file (if required),
the add_drv(1M) command is run to make the system aware that the device
is present.  It updates the following files:

  /etc/name_to_major - This file contains driver name to major number
  mapping.  Every driver has a major number;  the instances of the
  devices it manages each have their own unique minor number.

  /etc/minor_perm - This file contains permission, owner and group
  information used by drivers when creating new /devices entries (as when
  a device is accessed for the first time).

  /etc/driver_aliases - This file contains alternate names for device

  /etc/driver_classes - This file contains classes for device drivers
  (SBUS, VME, SCSI, etc).

add_drv then invokes the drvconfig(1M) command to configure the driver
if the system is not a diskless client, and then calls devlinks(1M) to
make any device links from the /dev directory.

NOTE: devices already existing on a system will not be rearranged when
new devices are added, even if new devices are added to sbus slots
numerically lower than those occupied by existing devices;  the
/etc/path_to_inst file, which maintains this information, is appended
to, not rewritten, when new devices are added.

A reconfigure boot will be done automatically the next time the system
is booted.

105) How does the system know to do a reconfiguration boot without
having been passed "-r" in the boot command?

The system will perform a reconfiguration boot automatically if it finds
a file called /reconfigure in its root directory.

On a SPARC running Solaris it is ok to remove BOTH /etc/path_to_inst
and /etc/path_to_inst.old

After removing you should have no problem doing a boot -a OR a boot -ar OR
boot -arv

The /etc/path_to_inst will be rebuilt without fail unless some other file
corruptio has occurred.

On a x86 architecture running Solaris there might be difficaulties if BOTH
the /etc/path_to_inst AND /etc/path_to_inst.olg files are removed.

If there is ever an issue where you can not boot off the boot disk due to
a problem of the boot program not finding /etc/path_to_inst you should
boot off of cdrom (boot -sw cdrom) and copy the /etc/path_to_inst file
contained on the cdrom to the /etc/path_to_inst on the boot disk.

To do this simply boot off the cdrom (boot -sw cdrom) and mount the boot
on /a

Then simply copy /etc/path_to_inst to /a/etc/path_to_inst

If this does not allow you to boot then your problems deal more than just
----- Original Message -----
From: "Fabio Kirchenchteyn" <>
To: "Fabio Kirchenchteyn" <>; "Sun Managers"
Sent: Saturday, May 12, 2001 5:45 PM
Subject: Re: cannot open /etc/path_to_inst

> already tried a backup file from the tape ...and nothing....
> ----- Original Message -----
> From: "Fabio Kirchenchteyn" <>
> To: "Sun Managers" <>
> Sent: Saturday, May 12, 2001 4:53 PM
> Subject: cannot open /etc/path_to_inst
> > Dear all!
> > i was almost sure that murphy left....when.....
> > i was testing mail in our www server ,i saw that netscape dont appear to
> > update the preferences
> > so i reboot.......
> > and the system did not waked up...
> > booted in single mode....
> > runned fsck ....
> > and still stoped at the prompt with:cannot open /etc/path_to_inst
> > what i should do???
> > all the web sites are stoped!!!
> > thank you so much.....
> > Fabio )-:
> >
Received on Wed May 16 14:02:40 2001

This archive was generated by hypermail 2.1.8 : Wed Mar 23 2016 - 16:24:55 EDT