This question is really one of curiosity. It involves the HWID number.
The question is how do you get back to using a HWID number that has
been abandoned after removing a device that was associated with that
number.
I've been experimenting with the nice feature of TU 5.0 that
allows removing and adding SCSI disks while the system is
running. I've been trying out various things with the
programs hwmgr and dsfmgr. For example:
62 coral:~etc # hwmgr -show scsi
SCSI DEVICE DEVICE DRIVER NUM DEVICE FIRST
HWID: DEVICEID HOSTNAME TYPE SUBTYPE OWNER PATH FILE VALID PATH
-------------------------------------------------------------------------
71: 0 coral disk none 2 1 dsk0 [7/0/0]
72: 1 coral cdrom none 0 1 cdrom0 [8/5/0]
74: 2 coral disk none 0 1 dsk1 [7/1/0]
75: 3 coral disk none 0 1 dsk2 [7/2/0]
76: 4 coral disk none 0 1 dsk3 [7/3/0]
In the above all the HWID numbers and "dsk*" numbers are in order.
If I deleted a disk and added another and basically screwed around
with changing disks, it appears the HWID number keeps increasing
and there is no way I have found to get a disk to occupy a previously
abandoned HWID number. A new disk seems to get the next highest HWID.
Now one can take, for example, "dsk29" and use dsfmgr to make it be
known as "dsk0" if one wants to be a bit obsessive about what disk
has what number, but the HWID just keeps going up.
Purely for aesthetic reasons, after all the experimentation, I wanted
to set the system back so that the system disk was dsk0 and others
were dsk1, dsk2, etc. I could do that with "dsfmgr -m ...."
but the HWID numbers were still higher than they were in the beginning.
It seems that if I removed /etc/dec_* and nulled out the
files /etc/df* , rebooted and ran "dsfmgr -K" to correct the lack
of device files, the dec_* files were recreated and the df* files
were repopulated and the lowest possible HWID numbers were used.
It all seems extreme when all I was wanting to do was essentially
pack the dec_* database files to remove the holes in the HWID numbers.
And if this were a system in production, I wouldn't really even
care about that. But I did get curious about how it could be done
and this was the only way I was able to come across.
-mike
------------------------------------------------------------------------------
Michael A. Crowley Director of Networking
mcrowley_at_mtholyoke.edu 216 Dwight Hall, Mount Holyoke College
413-538-2140 fax: 413-538-2331 South Hadley, MA 01075-6415
http://www.mtholyoke.edu/~mcrowley http://www.mtholyoke.edu/lits/network
------------------------------------------------------------------------------
Received on Sun Nov 28 1999 - 19:27:29 NZDT