Gestione dei devices in 5.1

Questi documenti, raccolti da web, sono chiarissimi su come gestire i devices nella potente, ma complessa struttura dei devices in Tru64 5.1:


Abstract: This is a brief explanation of how to replace a (presumably failed) SCSI device, such as a hard drive or tape drive, in DEC/Compaq/HP Tru64 Unix without leaving a bunch of crud behind in the hwmgr database, which can be a real problem in clusters if it builds up over time. Of course, no warranty, so don't cry to me if you mess up your machine.

1.	Check that the current database is consistent: 
root@venus # dsfmgr -vV
dsfmgr -vV
  Secure Session Lock. At Wed Apr 24 10:50:33 2002
dsfmgr: verify with fix all datum for system (5.1A-0 1885) at /

Default File Tree:
    OK.

Device Class Directory Default Database:
    OK.

Device Category to Class Directory Database:
    OK.

Dev directory structure:
    OK.

Device Status Files:
    OK.

Dev Nodes:
    OK.
  Release Session Lock at Wed Apr 24 10:50:33 2002
2.	Find the Device ID (second column) for the device you will replace: 
3.	root@venus # hwmgr -show scsi | grep dsk2
4.	   75:  2        venus      disk      none    0      1    dsk2   [1/0/0]
    
5.	Determine paths to the old device: 
root@venus # hwmgr -show scsi -full -did 2

        SCSI                DEVICE    DEVICE  DRIVER NUM  DEVICE FIRST
 HWID:  DEVICEID HOSTNAME   TYPE      SUBTYPE OWNER  PATH FILE   VALID PATH
-------------------------------------------------------------------------
   75:  2        venus      disk      none    0      1    dsk2   [1/0/0]

      WWID:0c000008:0000-0e11-001a-171c
      BUS   TARGET  LUN   PATH STATE
      ------------------------------
      1     0       0     valid
6.	Swap the hardware 
7.	Scan for the new hardware.
	Check the full hwmgr output for the new device to see if the paths
	match the old device's. The old device should now have a blank in
	the "first valid path" column. If you have a large number of devices,
	you can limit the results of hwmgr with the -type tape or -type disk
	options (eg hwmgr -show scsi -type tape). 
8.	root@venus # hwmgr -scan scsi
9.	hwmgr: Scan request successfully initiated
root@venus # hwmgr -show scsi
        SCSI                DEVICE    DEVICE  DRIVER NUM  DEVICE FIRST
 HWID:  DEVICEID HOSTNAME   TYPE      SUBTYPE OWNER  PATH FILE   VALID PATH
-------------------------------------------------------------------------
    0:  8        venus      processor none    0      1    (null)
    0:  9        venus      processor none    0      1    (null)
    0:  10       venus      processor none    0      2    (null)
    0:  11       venus      processor none    0      2    (null)
   73:  0        venus      disk      none    2      1    dsk0   [0/0/0]
   74:  1        venus      disk      none    0      1    dsk1   [0/1/0]
   75:  2        venus      disk      none    0      1    dsk2
   82:  6        venus      cdrom     none    0      1    cdrom0 [2/0/0]
  165:  3        venus      disk      none    0      1    dsk81  [1/0/0]

root@venus # hwmgr -sh sc -full -did 3
        SCSI                DEVICE    DEVICE  DRIVER NUM  DEVICE FIRST
 HWID:  DEVICEID HOSTNAME   TYPE      SUBTYPE OWNER  PATH FILE   VALID PATH
-------------------------------------------------------------------------
  165:  3        venus      disk      none    0      1    dsk81  [1/0/0]
      WWID:0c000008:0000-0e11-001a-2daa
      BUS   TARGET  LUN   PATH STATE
      ------------------------------
      1     0       0     valid

10.	Exchange the old device file with the new one: 
11.	root@venus # dsfmgr -e dsk2 dsk81
12.	  dsk2a<==>dsk81a  dsk2b<==>dsk81b  dsk2c<==>dsk81c  dsk2d<==>dsk81d  dsk2e<==>dsk81e
13.	  dsk2f<==>dsk81f  dsk2g<==>dsk81g  dsk2h<==>dsk81h  dsk2a<==>dsk81a  dsk2b<==>dsk81b
14.	  dsk2c<==>dsk81c  dsk2d<==>dsk81d  dsk2e<==>dsk81e  dsk2f<==>dsk81f  dsk2g<==>dsk81g  
  dsk2h<==>dsk81h
root@venus # hwmgr show scsi
        SCSI                DEVICE    DEVICE  DRIVER NUM  DEVICE FIRST
 HWID:  DEVICEID HOSTNAME   TYPE      SUBTYPE OWNER  PATH FILE   VALID PATH
-------------------------------------------------------------------------
    0:  8        venus      processor none    0      1    (null)
    0:  9        venus      processor none    0      1    (null)
    0:  10       venus      processor none    0      2    (null)
    0:  11       venus      processor none    0      2    (null)
   73:  0        venus      disk      none    2      1    dsk0   [0/0/0]
   74:  1        venus      disk      none    0      1    dsk1   [0/1/0]
   75:  2        venus      disk      none    0      1    dsk81
   82:  6        venus      cdrom     none    0      1    cdrom0 [2/0/0]
  165:  3        venus      disk      none    0      1    dsk2   [1/0/0]
   
15.	Delete the old device: 
16.	root@venus # hwmgr -delete scsi -did 2
17.	hwmgr: The delete operation was successful
root@venus # hwmgr -show scsi
        SCSI                DEVICE    DEVICE  DRIVER NUM  DEVICE FIRST
 HWID:  DEVICEID HOSTNAME   TYPE      SUBTYPE OWNER  PATH FILE   VALID PATH
-------------------------------------------------------------------------
    0:  8        venus      processor none    0      1    (null)
    0:  9        venus      processor none    0      1    (null)
    0:  10       venus      processor none    0      2    (null)
    0:  11       venus      processor none    0      2    (null)
   73:  0        venus      disk      none    2      1    dsk0   [0/0/0]
   74:  1        venus      disk      none    0      1    dsk1   [0/1/0]
   82:  6        venus      cdrom     none    0      1    cdrom0 [2/0/0]
  165:  3        venus      disk      none    0      1    dsk2   [1/0/0]
    
18.	Check for any lingering inconsistencies: 
19.	root@venus # hwmgr -show component -inconsistencies
root@venus # dsfmgr -vV
dsfmgr -vV
  Secure Session Lock. At Wed Apr 24 10:59:08 2002
dsfmgr: verify with fix all datum for system (5.1A-0 1885) at /
Default File Tree:
    OK.
Device Class Directory Default Database:
    OK.
Device Category to Class Directory Database:
    OK.
Dev directory structure:
    OK.
Device Status Files:
    OK.
Dev Nodes:
    OK.
  Release Session Lock at Wed Apr 24 10:59:08 2002
20.	Fix any detected problems: 
21.	root@venus # dsfmgr -vV -F
    
22.	Cluster Only:Check inconsistencies on other nodes and fix if needed: 
root@escher # hwmgr -show component -inconsistencies
root@escher # hwmgr -scan scsi
root@escher # dsfmgr -vV
root@escher # dsfmgr -vV -F

root@bach # hwmgr -show component -inconsistencies
root@bach # hwmgr -scan scsi
root@bach # dsfmgr -vV
root@bach # dsfmgr -vV -F


Abstract: Hardware Configuration Databases Restart... When you believe you have messed up your hardware configuration databases and you want to start from scratch. If you are in a cluster, we have no process for you. If you are not in a cluster, here are the directions: You must delete all the configuration database files. To do this, use the script at the following location. This script assumes that you have booted from the disk that you want to cleanup. If not, you need to create a script similar to the one supplied below to delete the files on the mounted data disk (your target system disk).

anw: /repository/ehm/best_practices/ehm_restart 
  

Shutdown the system: 

# shutdown -h now 
  

Boot the system to single user: 

>>>b -fl s 
  

Mount the root file system writable: 

# /sbin/mountroot 

All of the hardware components on this system now have their assigned names and device special files. You must now fix all the files and sub-systems that use device special file names and hardware component names. This typically includes LSM, advfs, /etc/fstab, /etc/sysconfigtab, and possibly others specific to your system and layered products. You can use the following command to see how the device special file names have been assigned to your devices:


# hwmgr -view device 
  

Now reboot the system: 

# reboot


Testo: Gestione devices in Tru64 5.1
Data: 31 Ottobre 2003
Versione: 1.0.2 31 Ottobre 2003
Autore: ignoto
Intelligence Service: Roberto Masdea
HTML Editing: mail@meo.bogliolo.name