barrett@jhunix.HCF.JHU.EDU (Dan Barrett) (07/29/90)
I wrote: >>I can't get troff to work under Ultrix 3.1D or 4.0. farhad@sunburn.stanford.edu (Farhad Shakeri) wrote: >Do: file /usr/lib/font/* and see if they are still VAX binaries! Ugh! Yes they ARE!!!! No wonder troff isn't working. >"troff" is an unsupported program in ULTRIX... Why the hell do they include a program that is guaranteed not to work at all? This isn't the first time, either... though it's the first time I've seen it in a major application. (Ultrix 2.0 version of the game "zork" crashes immediately, due to an illegal instruction.) FLAME_ON() I'm very unhappy about this. No, make that "furious." Since we decided to "upgrade" from a VAX to a network of DECstations, this is the FIFTH little "surprise" I have encountered. Software that was supplied with our VAX Ultrix, software that we DEPEND ON AND USE EVERY DAY, is totally broken or missing in RISC Ultrix. And guess what? Our network of DECstations is not up and running yet, over a month since it was delivered. Why? Because of one of the "little surprises", our DS3100's won't boot. Not only that, but if they WOULD boot, we could not use them in the configuration we wanted because (surprise!) DEC's diskless boot environment (DMS) requires an ENORMOUS amount of server disk space... far more than we can afford to waste on our server. Our salesperson never said a thing about this, of course. I call this lying by omission. This is completely unacceptable. As systems administrator for our department, I can say that my experiences with our new DECstations has brought my opinion of DEC to a new low. I have had excellent interaction with DEC hardware service, and a few notable people in software (Fred Avolio, Jody Patilla), so there is still hope for DEC in my good graces. But right now, I am ready to knock some heads. FLAME_OFF() Dan //////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ | Dan Barrett, Department of Computer Science Johns Hopkins University | | INTERNET: barrett@cs.jhu.edu | | | COMPUSERVE: >internet:barrett@cs.jhu.edu | UUCP: barrett@jhunix.UUCP | \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\/////////////////////////////////////
stefan@wheaton.UUCP (Stefan Brandle ) (07/31/90)
Sympathy re your flames. > And guess what? Our network of DECstations is not up and running > yet, over a month since it was delivered. Why? Because of one of the > "little surprises", our DS3100's won't boot. Not only that, but if they > WOULD boot, we could not use them in the configuration we wanted because > (surprise!) DEC's diskless boot environment (DMS) requires an ENORMOUS > amount of server disk space... far more than we can afford to waste on our > server. I recently (2 weeks ago) got a DS3100 and it wouldn't boot. In that case, the problem was that the ris(8) software didn't quite set everything up correctly on the server. When the machine tries to boot, there are three files that get sent -- the primary, secondary, and tertiary (sp?) -- that progressively get the machine up and running. The problem was that the symbolic link to that file that's supposed to be in the /usr/lib/dnet directory wasn't there. I caught on to the problem when I took a peek in /usr/spool/mqueue/syslog and found the server complaining about not being able to find that file. The file name that the server was looking for was `vmunixudt030.sys' and it's supposed to be pointing to `/usr/sys/MIPS/SAS/vmunix' or else to the appropriate generic vmunix that comes in the base software set on the tapes. I further ran into the problem that when I pointed the `vmunixudt030.sys' to the /usr/sys/MIPS/SAS/vmunix for the DECsystem 5400, we kinda booted but had problems with device drivers not seeing the SCSI RZ-stuff (I had expected that to be a problem but hoped it might work). So I extracted the correct vmunix from the ris subsets (base system, I believe) and set the link to that, and everybody lived happily ever after (or for at least another hour or so until I tried installing some 3rd party software). Your problem may or may not be related; I'm posting this in the hope that it may benefit you or somebody else. When I finally talked to a person from DEC (we kept missing each other until after I solved the problem) it was suggested that the problem was that I had a tape for stand-alone installation (tape unit attached to the machine) and needed a different tape for remote installation. Sounds possible -- maybe our sales rep got us the wrong part number or something. In case anybody wonders, our server is a DECsystem 5400 running 3.1C and the workstation is a DECsystem 3100 running 3.1D. Good luck to us all, Stefan -- ---------------------------------------------- MA Bell: (708) 260-4110 --------- Stefan Brandle UUCP: ...!{obdient,uunet!tellab5}!wheaton!stefan Wheaton College or stefan@wheaton.UUCP Wheaton, IL 60187 "But I never claimed to be sane!"