andrew@alice.UUCP (Andrew Hume) (09/05/90)
The other day I was roused from my terminal stupor by our installation manager who had been supervising 2 field engineers installing some ``maintenance software'' updates. apparently, there was some trouble booting, and could I come and help? the problem was pretty clear; nothing could mount as the devices in /etc/fstab didn't even exist!! I said ``where did they go? no one could be such a d*ckhead as to remove a customer's devices for so piddly a thing as a maintenance update?'' (Of course, I was asking for trouble using non-standard partitions for my filesystems.) And of course, my awk script for generating these didn't work because the godforsaken awk that comes standard is 6 years old and doesn't even have sub() in it. but hey, what are computers for, anyway? the event fizzled out as I did a few mknod's by hand, mounted enough stuff to do some work and then generated my devices and we were then able to boot. (we pass over the fact that the installation procedure had put us back to 96 processes (for a 380??) which i only found out today.) my question is: why is this clearing out and regenerating of /dev/dsk /dev/rdsk (and whatever else) done? it can't be for space; my /dev/dsk has the standard partitions for 160(!!) ipi drives (10 controllers at 16 drives each). are you telling me my 8 extra devices were too much? if sgi (and it may be sys v or mips' fault) REALLY wants to do this, is there some way we can prevent it or provide a hook so we can ensure the devices we want are remade?
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (09/06/90)
In article <11288@alice.UUCP>, andrew@alice.UUCP (Andrew Hume) writes: > ... > the godforsaken awk that comes standard is 6 years old and doesn't > even have sub() in it. ... Does nawk do what you want? We're just following the rapid-replacement-without-pain plan of awk from AT&T. Perhaps a little howling from customers would let us discover that the next IRIX release is, in the words of nawk(1), "the next major UNIX system release." (What inst and MAKEDEV do and should or should not do to /dev has far too much history and danger for me to say anything about.) Vernon Schryver, vjs@sgi.com
SOFPJF@VM.UOGUELPH.CA (Peter Jaspers-Fayer) (09/07/90)
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.