SunSolve Internal

Infodoc ID		Synopsis		Date
15626		General information on /etc/path_to_inst		28 Oct 1997

Description

Top

Information on /etc/path_to_inst
			--------------------------------


Relevant files:
	/etc/path_to_inst
	/etc/path_to_inst.old

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
  drivers.

  /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 disk
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 with
/etc/path_to_inst

SOLUTION SUMMARY: