jal@acc.flint.umich.edu (John Lauro) (07/09/90)
I recently upgraded some 3500s to SR 10.2. All went fine, and
everything worked including vt100. I then installed the following
patches for 10.2:
patch_m0101.v.1.0
patch_m0107.v.1.0
patch_m0108.v.1.0
patch_m0111.v.1.0
patch_m0114.v.1.0
patch_m0116.v.1.0
patch_m0118.v.1.0
patch_m0119.v.1.0
patch_m0121.v.1.0
patch_m0124.v.1.0
patch_m0126.v.1.0
patch_m0129.v.1.0
patch_m0130.v.1.0
patch_m0131.v.1.0
patch_m0136.v.1.0
patch_m0137.v.1.0
patch_m0139.v.1.0
patch_m0140.v.1.0
patch_m0141.v.1.0
patch_m0142.v.1.0
patch_m0145.v.1.0
patch_m0147.v.1.0
patch_m0152.v.1.0
patch_m0153.v.1.0
patch_m0154.v.1.0
patch_m0156.v.1.0
patch_m0157.v.1.0
patch_m0158.v.1.0
Any ideas why this would break vt100?
The patch tape mentions patches prior to the first of the year
on a different patch tape. Can someone please mail or post the
index of that tape?
Thanks...
- John_Lauro@ub.cc.umich.edu
University of Michigan - Flintzeleznik@cs.utah.edu (Mike Zeleznik) (07/10/90)
In article <1990Jul9.162841.26541@caen.engin.umich.edu> jal@acc.flint.umich.edu (John Lauro) writes: >... I then installed the following patches for 10.2: > > [list of 30 or so patches...] > >... Any ideas why this would break vt100? My feeling about patches is to only install what you ABSOLUTELY NEED, else you are asking for trouble. (If I'm off base on this one, please let me know). If you really needed all those patches, then I guess you had no choice. After all, each patch fixes a particular problem, but can not have been tested well within the entire system. In order to be so, it would have to wait til the next release and all its beta testing. Thus, while it may fix one problem, it may well cause another; and certainly the interaction of LOTS of these relatively untested things only increases the odds of more problems which could really seem unrelated to the patches. Just my opinions... Mike Michael Zeleznik Computer Science Dept. University of Utah zeleznik@cs.utah.edu Salt Lake City, UT 84112 (801) 581-5617
bep@quintro.uucp (Bryan Province) (07/10/90)
In article <1990Jul9.162841.26541@caen.engin.umich.edu> jal@acc.flint.umich.edu (John Lauro) writes: >I recently upgraded some 3500s to SR 10.2. All went fine, and >everything worked including vt100. I then installed the following >patches for 10.2: > > patches ... patches ... patches >patch_m0142.v.1.0 > ... more patches ... > >Any ideas why this would break vt100? > In case you haven't figured it out by now your problem is patch 142. I had loaded this myself and also broke vt100. When I called the hotline the guy said "Don't even load that patch. I don't know why it was even on the patch tape. It doesn't work." Your solution it to copy the old version of /sys/vtserver from another node or from your authorized area. The following is the timestamp of the proper file: 3 % ts /sys/vtserver Ver Name Time Stamp File Name -------------------------------------------------------------- c 1 vte_server 1989/07/06 13:16:04 CDT (Thu) /sys/vtserver We have been saying on the net here for a while that we should be provided with a list of patches so that we can decide if we need to load them to solve our problems. I still agree with that idea. However here is an argument against indiscriminately (sp?) loading patches without first talking to the hotline about the problem. I think this is one reason why Apollo doesn't provide tapes automatically. They don't want us to shoot ourselves in the foot. Just a thought. I'm an optimist. I like to think that Apollo means well. -- --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-- Bryan Province Glenayre Corp. quintro!bep@lll-winken.llnl.gov Quincy, IL tiamat!quintro!bep@uunet "Surf Kansas, There's no place like home, Dude."
krowitz%richter@UMIX.CC.UMICH.EDU (David Krowitz) (07/10/90)
Good God man! The patch tape release notes explicitly tell you *not* to install patches unless you absolutely need them! This (obvious) reason is that the individual patches have rarely had sufficient testing in a complete OS environment on all hardware models. Start with a clean OS release and install *only* the patches you *absolutely* need. We've been a beta-test site for new OS releases for years now. A large chunk of SR10.3 will be all of the patches for SR10.2 integrated into a complete OS release. I can't tell you how *bad* the initial beta-test releases tend to be, I don't have the room here. Let it suffice to say that some models of hardware are usually completely unusable with the first, second, or even the third beta release in the test sequence. Every single patch has got to be tested on sau2 (DN3xx), sau3 (DSP80/90), sau4 (DN460/660), sau5 (DN5xx), sau6 (DN5xx-Turbo), sau7 (DN3500/4000/4500), sau8 (DN3000/3010), sau9 (DN2500), and sau10 (DN10000) machines AND IN ALL POSSIBLE COMBINATIONS ! (IE. diskless DN330 booted from DN560 is different from diskless DN320 booted from DN3000). This bring me to my final plea ... if you have particular problems with the OS, volunteer to be a beta-test site. It's a *painful* process. Sometimes the initial releases are so bad that my user's will stay away from the machines with the beta-software on them, and I wind up having to spend a couple of days running quick tests on whatever I can think of before I remove the beta-release, re-install the old OS, and call in the problems ... but the only way the bugs will be fixed is if YOU find the bugs that affect YOUR usage of the system and call them in BEFORE the *&&^%! thing is released to the public. Thhis This is particularly true of older systems ... The R&D people have the latest and greatest hardware, not the older stuff, and they don't (and won't) find the errors on the systems that they don't use. Take note that "older stuff" means any DN560/570/580/590 (including 32MB Turbo systems), any DN3000, any DSP80/90, any DN3xx -- practically anything except DN3500/4500 and maybe DN2500 (the R&D people tend to get machines with larger internal disks that the DN2500 holds). If you want the OS tested with YOUR hardware, YOU have to do it 'cause R&D does not have your hardware in house anymore. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)