gmark@ihlpf.ATT.COM (Stewart) (07/15/88)
Has anyone else had this experience? Using the same disks to bring up 7 machines so far, we have had 3 come up with a shell script file in place of the /usr/include directory and the subtended files. It's as though some disk randomly puts a file there, preventing what I assume is part of the development set (the /usr/include library files and that directory) from being installed. It's a simple fix, moving the file and making the directory, then copying the files from one of our other machines, but I wonder why it happens and what the possibility of other parts of the system being garbaged is. These were all new machines, with the faulty and non-faulty bringups equally distributed between 7300s and 3B1s (yeah, right, 7 machines -- okay almost equally). Pretty strange. Comments? - Mark G. Mark Stewart ATT_BTL, Naperville, Ill. ix1g266 ixlpq!gms (312)979-0914 (please include phone in response)
jlw@lznv.ATT.COM (J.L.WOOD) (07/15/88)
I've seen this before and the cause is that there are no files from /usr/include in the foundation set. /usr/include is created by loading the development set. What happened to us was that we `installed from floppy' a package or two that had .h files in them. The Install script had something of the form: mv xyz.h /usr/include which would produce the effect we encountered. The message: Load the development set immediately after the foundation set if you are going to put it on the machine at all; otherwise, don't worry. Joe Wood lznv!jlw
gil@limbic.UUCP (Gil Kloepfer Jr.) (07/16/88)
In article <5301@ihlpf.ATT.COM> gmark@ihlpf.ATT.COM (Stewart) writes: |>Has anyone else had this experience? Using the same disks to |>bring up 7 machines so far, we have had 3 come up with a shell |>script file in place of the /usr/include directory and the subtended |>files. It's as though some disk randomly puts a file there, preventing |>what I assume is part of the development set (the /usr/include library |>files and that directory) from being installed. |> G. Mark Stewart |> ATT_BTL, Naperville, Ill. ix1g266 |> ixlpq!gms (312)979-0914 |> (please include phone in response) Yes, me too (I thought I did something wrong in the installation!). I ultimately wiped the file out and re-installed the development set and all was ok. An idea... perhaps it makes a difference which packages you install first. Do you install each machine's software in the same order each time (check the installed software list from the user agent). I believe it has something to do with that. Lenny (the (in)famous lenny@icus :-) gave me a hand with the installation and he had the same feeling about this, but again .. we didn't know what caused the problem. He just reloaded his OS about two months ago and it went fine. If anyone finds out, please satisfy my curiousity and let me know what happened! +------------------------------------+----------------------------------------+ | Gil Kloepfer, Jr. | Net-Address: | | ICUS Software Systems | {boulder,talcott}!icus!limbic!gil | | P.O. Box 1 | Voice-net: (516) 968-6860 | | Islip Terrace, New York 11752 | Othernet: gil@limbic.UUCP | +------------------------------------+----------------------------------------+
lenny@icus.UUCP (Lenny Tropiano) (07/16/88)
In article <162@limbic.UUCP> gil@limbic.UUCP (Gil Kloepfer Jr.) writes: |>In article <5301@ihlpf.ATT.COM> gmark@ihlpf.ATT.COM (Stewart) writes: |>|>Has anyone else had this experience? Using the same disks to |>|>bring up 7 machines so far, we have had 3 come up with a shell |>|>script file in place of the /usr/include directory and the subtended |>|>files. It's as though some disk randomly puts a file there, preventing |>|>what I assume is part of the development set (the /usr/include library |>|>files and that directory) from being installed. |> |>Yes, me too (I thought I did something wrong in the installation!). I |>ultimately wiped the file out and re-installed the development set and |>all was ok. |> |>An idea... perhaps it makes a difference which packages you install first. |>Do you install each machine's software in the same order each time (check |>the installed software list from the user agent). I believe it has something |>to do with that. |> |>Lenny (the (in)famous lenny@icus :-) gave me a hand with the installation and |>he had the same feeling about this, but again .. we didn't know what caused |>the problem. He just reloaded his OS about two months ago and it went fine. |> |>If anyone finds out, please satisfy my curiousity and let me know what |>happened! |> I was talking with Gil this evening and he mentioned that he followed up on this article. What I believe is the case (although I haven't verified it yet) is that installing the Curses/Terminfo Programming Pkg. before installing the Development Set will cause this problem. (Supporting Gil's posting above). The Curses/Terminfo Programming Pkg. has a copy of curses.h, term.h, unctrl.h on it, it then proceeds to link them into /usr/include. The Foundation Set should have a blank /usr/include directory (or the Curses Install should be a little dummy proof and check to see if /usr/include is there, if not mkdir /usr/include and /usr/include/sys). Excerpt from "Install" on the Curses Terminfo Progrmmming Package Disk. ... INSINC=/usr/include export BEEP INSLIB INSINC ... echo "*** Installing Curses/Terminfo header files : " echo "Installing curses.h in " $INSINC ; ln curses.h $INSINC echo "Installing term.h in " $INSINC ; ln term.h $INSINC echo "Installing unctrl.h in " $INSINC ; ln unctrl.h $INSINC ... If these files are linked in like they are above, and then you load the DEVELOPMENT SET 3.X it will fail to mkdir /usr/include. What the above Install should have is: if [ ! -d /usr/include ] then rm -f /usr/include mkdir /usr/include mkdir /usr/include/sys fi To avoid any problems in the future just install the DEVELOPMENT SET first before any tools related to it. Hope this helps, Lenny -- Paper-net: Lenny Tropiano | @-net: lenny@icus.UUCP ICUS Software Systems | !-net: ...att \ PO Box 1 | boulder \ Islip Terrace, NY 11752 | talcott !icus!lenny Vocal-net: (516) 582-5525 [work] | pacbell / (516) 968-8576 [home] | sbcs / Telex-net: 154232428 ICUS | Another-net: attmail!icus!lenny