Path: utzoo!utgpu!watserv1!watmath!att!ucbvax!VM.UOGUELPH.CA!SOFPJF From: SOFPJF@VM.UOGUELPH.CA (Peter Jaspers-Fayer) Newsgroups: comp.sys.sgi Subject: Re: Rampaging Software Installation Message-ID: <9009062038.aa00490@VGR.BRL.MIL> Date: 7 Sep 90 01:18:57 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 30 You beat me to it, Andrew. I was in the midst of composing a similar query/complaint (being less experienced, I was expressing it more along the lines of "Hey, what did we do wrong?"), when I spotted your mail. We too had our non-standard /dev/dsk/ipi0d0s[n] devices removed. As one of these (with associated link) were to describe our /usr filesystem (on a non-boot/root disk), the results were somewhat spectacular. We too didn't like it! We spent some time discussing how this could best be circumvented in the future and came up with a work-around and a better solution: 1) The work around is that install should have make it clearer that it was monkeying around with our devices and allowed us to fix up the damage before booting. But if there are a lot of them (even 4 is a lot: mknod, chmod, ln, then to /dev/rdsk and do it all over again) it's a pain, so I would like to propose: 2) MKDEV should call a MKDEV.local, which could describe locally defined devices, their protection/ownership flags, and associated links. This file should, of course be never be over-written! (as MKDEV was during the install) The documentation for MKDEV and mknod should be changed to warn people that unless changes to /dev are coded in MKDEV.local, a future install may mess you up. /PJ SofPJF@VM.UoGuelph.Ca (Probably also reachable (until ?) at SOFPJF@UOGUELPH.BITNET) Klein bottle for rent, apply within.