The dsfmgr command is used to manage device special files using the new naming convention defined in Tru64 UNIX version 5.0. The following database files are used by dsfmgr:
dccd.dat
dfsl.dat
dcdd.dat
dfsc.dat
We will not attempt to show every permutation of every command option but instead will concentrate on the most useful options.
Show information on device special files for the system (output not shown).
# dsfmgr -s
Create the device special file for a newly added device (output not shown).
# dsfmgr –k
Rename a device special file to a non-existent instance.
# ls /dev/disk/dsk9 ls: /dev/disk/dsk9* not found
# dsfmgr –m dsk7 dsk9 dsk7a=>dsk9a dsk7b=>dsk9b dsk7c=>dsk9c dsk7d=>dsk9d dsk7e=>dsk9e dsk7f=>d sk9f dsk7g=>dsk9g dsk7h=>dsk9h dsk7a=>dsk9a dsk7b=>dsk9b dsk7c=>dsk9c dsk7 d=>dsk9d dsk7e=>dsk9e dsk7f=>dsk9f dsk7g=>dsk9g dsk7h=>dsk9h
Note | In order for the "dsfmgr -m" command to be successful, the device must be local to the system. If the device is not local you will receive an error similar to the following. |
dsfmgr: ERROR: cannot move device, it is not local to this node: dsk10 dsfmgr: ERROR move failed: Invalid argument
Occasionally when you replace a device, the dfsl.dat and dfsc.dat files need to be updated; otherwise, when you attempt to rename the new device back to the old device special file, you will see the following:
# dsfmgr –m dsk7 dsk9 dsfmgr: ERROR: second device status is active: dsk9a
First, you will need to identify which HWID is associated with dsk9. You will probably already know which it is, because you probably deleted the component when you replaced the device. If you do not know the HWID, however, you can still find it by searching the dfsc.dat file.
# grep "dsk 9 a" /etc/dfsc.dat A: 0 13000b1 59 17 0 b "" /dev/disk/ dsk 9 a A: 0 13000b2 59 17 0 c "" /dev/rdisk/ dsk 9 a
Or try:
# awk '/dsk 9 / { print $4 }' < /etc/dfsc.dat | uniq 59
We printed for the 4th field because it is HWID (see section 7.3). Also, be very careful with the search string; make sure the pattern is: /dsk<space><instance number><space>/
The <space> characters are very important.
The HWID is 59, and this is the one we need to remove from the files. Now that we have the HWID, we can remove it from the dfsl.dat and dfsc.dat files. We will do this using an undocumented switch "-Z" to the dsfmgr command.
# dsfmgr -Z rm_hwid 59 0 -dsk9a -dsk9b -dsk9c -dsk9d -dsk9e -dsk9f -dsk9g -dsk9h -dsk9a -dsk9b -dsk9c -dsk9d -dsk9e -dsk9f -dsk9g -dsk9h
This will remove the HWID entries from the dfsc.dat and dfsl.dat database files. Alternatively, if you need to remove entries from only one file, you can use the "rm_local_hwid" flag to remove the HWID from the dfsl.dat file or the "rm_cluster_hwid" flag to remove the HWID from the dfsc.dat file.
At this point, the "dsfmgr –m" command should work.
Note | In V5.1A, a new option "-R" has been added to the dsfmgr command that is documented and can be used to remove the HWID entries from the dfsc.dat and dfsl.dat database files. The "-R" option takes two parameters: |
Where to remove the HWID
| – remove the HWID from dfsc.dat |
| – remove the HWID from dfsl.dat |
| – remove the HWID from all locations |
The HWID
# dsfmgr –R hwid 59 -dsk9a -dsk9b -dsk9c -dsk9d -dsk9e -dsk9f -dsk9g -dsk9h -dsk9a -dsk9b -dsk9c - dsk9d -dsk9e -dsk9f -dsk9g -dsk9h
For additional information, see the dsfmgr(8) reference page for V5.1A.
Exchange two device special file instances.
# dsfmgr -e dsk6 dsk7 dsk6a<==>dsk7a dsk6b<==>dsk7b dsk6c<==>dsk7c dsk6d<==>dsk7d dsk6e<==>dsk7e dsk6f<==>dsk7f dsk6g<==>dsk7g dsk6h<==>dsk7h dsk6a<==>dsk7a dsk6b<==>dsk7b dsk6c<==>dsk7c dsk6d<==>dsk7d dsk6e<==>dsk7e dsk6f<==>dsk7f dsk6g<==>dsk7g dsk6h<==>dsk7h
This problem is similar to the "second device status is active" error but occurs when using the "dsfmgr -e" command.
The error will look like this:
# dsfmgr -e dsk7 dsk9 dsfmgr: ERROR: find device node dsk9 : Device record not found in status database dsfmgr: ERROR exchange failed: Device record not found in status database
Follow the "How Do I Fix a 'second device status is active' Error?" procedure (section 7.5.1.4) to resolve the problem.
# dsfmgr -v dsfmgr: verify all datum for system 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.
Fix database errors or inconsistencies (output not shown). Note this may need to be run a few times to correct errors.
# dfsmgr -vF
Note | The "-o" and "-O" options are used to create the pre-V5 device names that are not supported in a TruCluster Server environment. |
For more information, see the dsfmgr(8) reference page as well as the Tru64 UNIX System Administration guide.
The dn_setup command uses dsfmgr to create device special files for the system. This command is run every time the system is rebooted. The dn_setup command can also be used to recreate the devices in /dev and /devices.
To create a tape device when booting from the installation CD to restore the operating system, you can use dn_setup with the "–install_tape" switch. As a general rule, dn_setup should not be used except in those situations where the devices and device databases reach a state where no other command (dsfmgr or hwmgr) can clear things up.
Caution should be taken whenever using the dn_setup command with the "-init" or "-clean" options, especially if you are using LSM, because dn_setup will not recreate the LSM devices. See Chapter 14 ("Cluster Logical Storage Manager") for a detailed discussion.
# dn_setup -init
After executing this command, it is important to run "dsfmgr -K" immediately afterward. Furthermore, if you are using LSM, you must also run the following commands:
If the system is in multi-user mode (or in single-user mode with /usr mounted):
# /usr/sbin/volinstall update # /sbin/voldctl enable
If the system is in single-user mode and /usr cannot be mounted (likely because /usr is encapsulated within LSM):
# mknod /dev/volconfig c 41 0 # mknod /dev/voltrace c 41 1 # mknod /dev/voliod c 41 2 # mknod /dev/volinfo c 41 3 # bcheckrc
These additional steps are necessary when using LSM because "dn_setup -init" completely deletes the /devices directory as well as the contents of /dev, and dn_setup does not know about LSM. We'll cover LSM in greater detail in Chapter 14.
# dn_setup -sanity_check Passed.
Note that this is effectively the same as running "dsfmgr –zx", although the "-z" switch is undocumented.
# dn_setup –install_tape
As of this writing, there is no reference page for the dn_setup command. However, it is documented in the Tru64 UNIX System Administration manual prior to version 5.1B and the Tru64 UNIX Hardware Management manual as of version 5.1B.