Tom Blinn replied to my curiosity question about packing the database
including the HWID numbers. His words are the best summary:
Your question is a perfectly reasonable one. I've asked the same sort
of question in formal problem reports of the the team that implemented
this "feature", and the answer seems to be, basically, "you can't", if
you aren't willing to resort to the sort of tricks you used, which are
not very pretty and would certainly be likely to get you into some real
trouble if you were using some of the more advanced features of such as
LSM to manage your disks.
The only way to really get things back to a reasonable configuration,
in my experience, is to re-install from scratch. Pretty ugly, but it
is how it appears to work at this point.
...
He also mentioned that this seemed to be incomplete and that
there might be solutions in the future.
Since I'm not using LSM on this system, I didn't bother checking
the pitfalls of that, but it is good advice to not try the tricks
I used on any sort of production system. Even in my test phase,
I had a duplicate of the system disk so I wouldn't have to totally
reinstall if things got real nasty.
-mike
---------- original message ----------
> 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 Mon Nov 29 1999 - 15:29:25 NZDT