trebor@lkbreth.foretune.co.jp (Robert J Woodhead) (03/05/91)
I recently ran into the following nasty in SCO UNIX. Having just installed SCO TCP/IP I wanted to install SCO NFS. Unfortunately, my machine didn't have enough disk space. Going into CUSTOM, I noticed that there were several packages in the development system that I didn't need, like DOSDEV and OS2DEV, so I decided to deinstall them. This was, as they say, "A BAD IDEA!" Upon trying to deinstall OS2DEV, CUSTOM reported an error. I exited from the program back into the SYSADMSH, and attempted to run CUSTOM again. CUSTOM would not run. I exited SYSADMSH and tried to run it again. It would not run. The deinstallation had totally erased the entire of /usr (!!!!!!!) Fortunately, I had backups. Also, fortunately, TCP/IP was running and we were able to copy the contents of /u (oh lucky me that all my work files were not in /usr!) onto a remote machine. A fax was dispatched to SCO 5 days ago. As of yet, the denizens of SCO technical support have not been heard from. Needless to say, when one shells out the serious $$ one must for SCO's products, one expects support of a more prompt nature. (I would like to point out that this is not the case with the reseller who actually sold me SCO UNIX -- their tech support in this matter was admirable. Thanks LP...) Things were trashed enough that I had to reinitialize the HD and reinstall all the packages (sigh - an afternoon wasted). I decided that this time I would partially install the dev system. There were a few bobbles because SCO doesn't bother to mention the dependencies -- who would imagine that to run the C compiler you need the XENIX 386 cross development libraries? However, I did find it disturbing that doing a partial install of the SCO development system partially DEINSTALLS the extended utilties of the OS. In order to get things to work, you must then re-install the utilities. Did anyone at SCO ever bother to test their install/deinstall scripts? -- +--------------------------------------------------------------------------+ | Robert J. Woodhead, Biar Games / AnimEigo, Incs. trebor@foretune.co.jp | | "The Force. It surrounds us; It enfolds us; It gets us dates on Saturday | | Nights." -- Obi Wan Kenobi, Famous Jedi Knight and Party Animal. |
wht@n4hgf.Mt-Park.GA.US (Warren Tucker) (03/06/91)
In article <9113@lkbreth.foretune.co.jp> trebor@lkbreth.foretune.co.jp (Robert J Woodhead) writes: >However, I did find it disturbing that doing a partial install of the >SCO development system partially DEINSTALLS the extended utilties of the >OS. In order to get things to work, you must then re-install the utilities. > >Did anyone at SCO ever bother to test their install/deinstall scripts? I haven't experienced the problems you discuss, but there are some warnings in the release notes about certain deinstalls. None of them spoke of /usr going away in toto. ------------------------------------------------------------------------ Warren Tucker, TuckerWare emory!n4hgf!wht or wht@n4hgf.Mt-Park.GA.US "An ANSI C elephant: just like the real one, but the position, shape and length of the trunk and tail are left to the vendor's discretion." -- me
sef@kithrup.COM (Sean Eric Fagan) (03/06/91)
In article <9113@lkbreth.foretune.co.jp> trebor@lkbreth.foretune.co.jp (Robert J Woodhead) writes: >Going into CUSTOM, I noticed that there were >several packages in the development system that I didn't need, like DOSDEV >and OS2DEV, so I decided to deinstall them. I have deinstalled DOSDEV and OS2DEV on kithrup (several times, in fact, for reasons I won't get into here 8-)), and have never had any problems whatsoever. I don't know what your problem was, but it's the first that I (even as an SCO employee) have heard of something like that happening. >Upon trying to deinstall OS2DEV, CUSTOM reported an error. What error? Did you, perhaps, run out of disk space? (It tries to build a file list, according to its messages, and if it can only make a file that has "/usr" as the pathname...) >Things were trashed enough that I had to reinitialize the HD and reinstall >all the packages (sigh - an afternoon wasted). Ah. I suspect from that that your disk actually *died*. Not sco's fault. (Yes, such things happen occasionaly to disks. One of the reinstalls for kithrup, a few months ago [and when I upgraded to unix] was because the disk died. It reformated without problem, though, and a scan reported no bad tracks.) >There were a few bobbles because >SCO doesn't bother to mention the dependencies -- who would imagine that to >run the C compiler you need the XENIX 386 cross development libraries? You also have a *very* old version of the devsys. You probably want to upgrade... >Did anyone at SCO ever bother to test their install/deinstall scripts? Gee, no. Actually, we never install or deinstall internally, and you are, in fact, the first person to ever deinstall. (That was sarcasm.) -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
sysop@mixcom.COM (System Operator) (03/07/91)
>In article <9113@lkbreth.foretune.co.jp> trebor@lkbreth.foretune.co.jp (Robert J Woodhead) writes: >>Going into CUSTOM, I noticed that there were >>several packages in the development system that I didn't need, like DOSDEV >>and OS2DEV, so I decided to deinstall them. If you make /tmp a separate file system rather than leaving it a directory in the root file system, you must unmount /tmp before using SCO's "custom" to install and deinstall packages. Some installation scripts create links in /tmp. If /tmp is a file system, this will fail, though the script may not notice that and continue. (A link will fail in this case since SCO UNIX cannot create links across file systems. This is a characteristic of UNIX System V, not a "feature" created by SCO.) Dean Roth -- Milwaukee Information eXchange (MIX) World-wide Email, Usenet BBS MIX Communications, P.O. Box 17166, Milwaukee, WI 53217
trebor@lkbreth.foretune.co.jp (Robert J Woodhead) (03/07/91)
sef@kithrup.COM (Sean Eric Fagan) writes: >Did you, perhaps, run out of disk space? (It tries to build a >file list, according to its messages, and if it can only make a file that >has "/usr" as the pathname...) Nope, had about 3M left before the deinstall. >I suspect from that that your disk actually *died*. Not sco's fault. Get real, Sean. The disk was perfectly OK after the event, and the system was up and running (albeit crippled) for 24 hours before I reinstalled. I managed to FTP the whole of /u (not a seperate partition) off the machine. The reason I did a reinstall was 1) with /usr gone, all the installation sw was zapped from the HD, and given the good chance that other parts of the filesystem were MUNGed, it seemed like the prudent thing to do. >>There were a few bobbles because >upgrade... Well, lets see. My little red registration card says that it was printed 09/27/90, and I bought it in late November. I had to buy everything over again even though the machine was running SCO XENIX -- no discount for upgrades. Your new version of TCP/IP didn't support my Excelan ethernet board, so I had to buy another board (I was quite happy with SCO XENIX, btw - I had to upgrade because some new boards I needed to do work with would only talk to Unix, not XENIX) So now you are telling me that my software is obsolete and I need to upgrade? This is the extent of SCO tech support? "It wasn't our problem; your hardware blew up; and you need to upgrade!" Prithy tell me, kind sir, how much said upgrade will cost! >Gee, no. Actually, we never install or deinstall internally, and you are, >in fact, the first person to ever deinstall. (That was sarcasm.) Gee, I believe you. I also recall Hippocrates, who gave the following advice to physicians; "First, do no harm." The same is good advice to software companies. >Sean Eric Fagan | "I made the universe, but please don't blame me for it; >sef@kithrup.COM | I had a bellyache at the time." >-----------------+ -- The Turtle (Stephen King, _It_) >Any opinions expressed are my own, and generally unpopular with others. ^^^^^ Well, I'll agree with you there! -- +--------------------------------------------------------------------------+ | Robert J. Woodhead, Biar Games / AnimEigo, Incs. trebor@foretune.co.jp | | "The Force. It surrounds us; It enfolds us; It gets us dates on Saturday | | Nights." -- Obi Wan Kenobi, Famous Jedi Knight and Party Animal. |
rcd@ico.isc.com (Dick Dunn) (03/07/91)
I step further out on a thin limb (and I'm not a thin guy:-), as I get more fed up with the flame-every-vendor attitude of this newsgroup... Trying to figure out why an SCO de-install zapped /usr... > >I suspect from that that your disk actually *died*. Not sco's fault. > > Get real, Sean. The disk was perfectly OK after the event, > and the system was up and running (albeit crippled) for > 24 hours before I reinstalled... And of course, there's no chance of a disk error, and (from some text I deleted) no possibility that the process ran out of disk space anywhere along the way in spite of the fact that the purpose of the de-install was to gain some space. There can't *possibly* be any obscure explanation which will have to be arrived at by an extended discussion. Yep, must be that SCO isn't smart enough to write a de-install procedure that won't black-hole all of /usr. Yessir! Folks, get real! You hit a serious problem, so you post it...fine; that can help us all. Then, since you are (understandably) pissed, you start looking for a cause and a guilty party. Still fine...if I have to restore /usr, it's not beer time. So someone with the vendor steps up to try to ask some questions. Not surprisingly, he's reluctant to assume that he and all of his colleagues are complete idiots, so he postulates causes which include your actions and your hardware. Now, what do you do for this person who's stepped forward to try to help sort it out? You set the mertilizer on "medium well" and aim at him, of course! If someone pokes his head up, you lop it off. And naturally the next step is to flame the vendors for being unresponsive and not listening to the net! You can't understand why engineers don't want to take their free time to help you out when you flame them every time they speak. (I shouldn't be picking on this one posting, but it's hard to do a USENET followup to a hundred articles at once.) > ...I had > to buy everything over again even though the machine was running > SCO XENIX -- no discount for upgrades... Then there's the idea that if you ever give a vendor a dollar, they're in your debt forever. Let's see...an "upgrade" from Xenix to UNIX: different license, different software, different manuals and media, different support...what (except for the vendor) does it have in common? The response to an attempt to open a dialogue to help someone out goes something like this: > ...This is the extent of SCO tech support? "It wasn't > our problem; your hardware blew up; and you need to upgrade!" Is Sean in SCO tech support? I guess not. How much did you pay for the privilege of flaming him? Nothing. (If you expect something for nothing, you can at least ask nicely.:-) -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...But is it art?
rlb@bsts00.uucp (Ronald (Ron) L. Bolin 3945 snk=) (03/09/91)
In article <9113@lkbreth.foretune.co.jp> you write: >I recently ran into the following nasty in SCO UNIX. Having just installed >SCO TCP/IP I wanted to install SCO NFS. Unfortunately, my machine didn't >have enough disk space. Going into CUSTOM, I noticed that there were >several packages in the development system that I didn't need, like DOSDEV >and OS2DEV, so I decided to deinstall them. > >This was, as they say, "A BAD IDEA!" > >Upon trying to deinstall OS2DEV, CUSTOM reported an error. I exited from >the program back into the SYSADMSH, and attempted to run CUSTOM again. >CUSTOM would not run. I exited SYSADMSH and tried to run it again. It >would not run. > >The deinstallation had totally erased the entire of /usr (!!!!!!!) Say, I tried SCO ODT last year (Aug) with the same kind of results. I wrote a complaint letter to their their VP about this an other user support things; sent back ODT and bought another vendors product. SCO should be more responsive to users needs. Ron -- Ron Bolin (404) 529-3945 BellSouth Services Rm 25M64, 675 W. Peachtree St. Atlanta, Ga 30375 USENET EMAIL/Reply To: ..!gatech!sbmsg1!bsts00!rlb BellSouth EMAIL/Reply To: sbesac!!bsts00!rlb or aimsx!bsts00!rlb --- Ron Bolin (404) 529-3945 BellSouth Services Rm 25M64, 675 W. Peachtree St. Atlanta, Ga 30375 USENET EMAIL/Reply To: ..!gatech!sbmsg1!bsts00!rlb BellSouth EMAIL/Reply To: sbesac!!bsts00!rlb or aimsx!bsts00!rlb
wul@sco.COM (Wu Liu) (03/10/91)
I wanted to let somebody else answer this one first. Since nobody from SCO Support (busy guys and gals that they are) has replied yet, though... /--sef@kithrup.COM (Sean Eric Fagan) said... | In article <9113@lkbreth.foretune.co.jp> trebor@lkbreth.foretune.co.jp (Robert J Woodhead) writes: | >Going into CUSTOM, I noticed that there were | >several packages in the development system that I didn't need, like DOSDEV | >and OS2DEV, so I decided to deinstall them. | | I have deinstalled DOSDEV and OS2DEV on kithrup (several times, in fact, for | reasons I won't get into here 8-)), and have never had any problems | whatsoever. I don't know what your problem was, but it's the first that I | (even as an SCO employee) have heard of something like that happening. \-- I've done multiple installations and deinstallations (I lost count long ago...) of various SCO software products, at both the product and package level, and I've never run into a deinstallation which trashed the contents of /usr, like was reported. /-- | >Upon trying to deinstall OS2DEV, CUSTOM reported an error. | | What error? Did you, perhaps, run out of disk space? (It tries to build a | file list, according to its messages, and if it can only make a file that | has "/usr" as the pathname...) \-- Sean's on the right track here; the first step would be to determine what happened to custom here. There are two basic types of custom errors. The less severe type will print out some error message to the screen, while the nastier ones will cause custom to exit prematurely. The latter will also generate some nice, cryptic error messages like "custom: Internal error 10"... It would also help to know what versions of both the OS and Dev Sys you have installed are. /-- | >Things were trashed enough that I had to reinitialize the HD and reinstall | >all the packages (sigh - an afternoon wasted). | | Ah. I suspect from that that your disk actually *died*. Not sco's fault. | (Yes, such things happen occasionaly to disks. One of the reinstalls for | kithrup, a few months ago [and when I upgraded to unix] was because the disk | died. It reformated without problem, though, and a scan reported no bad | tracks.) | | >There were a few bobbles because | >SCO doesn't bother to mention the dependencies -- who would imagine that to | >run the C compiler you need the XENIX 386 cross development libraries? | | You also have a *very* old version of the devsys. You probably want to | upgrade... \-- I guess you've got version 3.2.0 of the Unix Dev Sys. That's pretty old stuff; I think the current shipping standalone version is 3.2.1, maybe 3.2.2. The version bundled with the Open Desktop Development System currently is 3.2.1. /-- | >Did anyone at SCO ever bother to test their install/deinstall scripts? | | Gee, no. Actually, we never install or deinstall internally, and you are, | in fact, the first person to ever deinstall. (That was sarcasm.) \-- Now, Sean, lay off the poor customer. After all, his money helps pay your salary... :-) As for the question itself; yes, we do bother to test the scripts. However, it's virtually impossible to test all of the various combinations of installations/deinstallations/mix of products. We also use our own products in-house, which catches quite a few bugs that otherwise might have slipped past both engineering and QA tests. Having said that, I feel pretty confident in saying that something this obvious and this serious would have been caught long before the product shipped. Perhaps Mr. Woodhead could post or e-mail more details about the problem he encountered?
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (03/11/91)
As quoted from <357@n4hgf.Mt-Park.GA.US> by wht@n4hgf.Mt-Park.GA.US (Warren Tucker): +--------------- | In article <9113@lkbreth.foretune.co.jp> trebor@lkbreth.foretune.co.jp (Robert J Woodhead) writes: | >However, I did find it disturbing that doing a partial install of the | >SCO development system partially DEINSTALLS the extended utilties of the | >OS. In order to get things to work, you must then re-install the utilities. | > | >Did anyone at SCO ever bother to test their install/deinstall scripts? | | I haven't experienced the problems you discuss, but there are some | warnings in the release notes about certain deinstalls. None of them | spoke of /usr going away in toto. +--------------- I did the same deinstall Robert spoke of (removing the DOS and OS/2 cross- development stuff) under 2.3.1 and /usr didn't vanish. We'll see what happens when 2.3.2 gets here. (I found out why it's taking so long, at least....) ++Brandon -- Me: Brandon S. Allbery Ham: KB8JRR on 40m, 10m when time Internet: allbery@NCoast.ORG permits; also 2m, 220, 440, 1200 America OnLine: KB8JRR // Delphi: ALLBERY AMPR: kb8jrr.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KB8JRR @ WA8BXN.OH
azakinthinos@lion.uwaterloo.ca (Aris Zakinthinos) (03/12/91)
In article <1991Mar10.174722.20568@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR) writes: >As quoted from <357@n4hgf.Mt-Park.GA.US> by wht@n4hgf.Mt-Park.GA.US (Warren Tucker): >+--------------- >| In article <9113@lkbreth.foretune.co.jp> trebor@lkbreth.foretune.co.jp (Robert J Woodhead) writes: >| >However, I did find it disturbing that doing a partial install of the >| >SCO development system partially DEINSTALLS the extended utilties of the >| >OS. In order to get things to work, you must then re-install the utilities. >| > >| >Did anyone at SCO ever bother to test their install/deinstall scripts? >| >| I haven't experienced the problems you discuss, but there are some >| warnings in the release notes about certain deinstalls. None of them >| spoke of /usr going away in toto. >+--------------- > >I did the same deinstall Robert spoke of (removing the DOS and OS/2 cross- >development stuff) under 2.3.1 and /usr didn't vanish. We'll see what happens >when 2.3.2 gets here. (I found out why it's taking so long, at least....) > A friend of mine did the same deinstall and everything seemed to work fine. Then we did a fsck (we had some wired problems) and low and behold nearly the whole #%$@&# file system was screwed. I can't exactly blame the deinstall but that was the only major thing that has happened to cause any type of file system failure. ------------------------------------------------------------------------------ Aris Zakinthinos uunet!watmath!lion!azakinthinos
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (03/16/91)
As quoted from <1991Mar11.163159.14640@watdragon.waterloo.edu> by azakinthinos@lion.uwaterloo.ca (Aris Zakinthinos): +--------------- | In article <1991Mar10.174722.20568@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR) writes: | >I did the same deinstall Robert spoke of (removing the DOS and OS/2 cross- | >development stuff) under 2.3.1 and /usr didn't vanish. We'll see what happens | >when 2.3.2 gets here. (I found out why it's taking so long, at least....) | | A friend of mine did the same deinstall and everything seemed to work fine. | Then we did a fsck (we had some wired problems) and low and behold nearly | the whole #%$@&# file system was screwed. I can't exactly blame the | deinstall but that was the only major thing that has happened to cause | any type of file system failure. +--------------- Well, my deinstall was some four months ago. *No* fsck problems, major or otherwise, before or since. ++Brandon -- Me: Brandon S. Allbery Ham: KB8JRR on 40m, 10m when time Internet: allbery@NCoast.ORG permits; also 2m, 220, 440, 1200 America OnLine: KB8JRR // Delphi: ALLBERY AMPR: kb8jrr.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KB8JRR @ WA8BXN.OH