rwright@novavax.UUCP (Ronald K. Wright) (08/09/89)
I received AT&T 3.51 Fix Disk ver 1.0 Fix 1014.
I installed it on one of my 3B1s with:
3.51
Development set
Voice Mail
Telephone manager
HoneyDanBear UUCP
HoneyDanBear Administration
3 megabytes RAM
Expansion RS232
40 megabytes HD
I installed the whole works...there are 8 fixes.
uucp stopped.
I uninstalled HDB and HDB administration.
During the latter process, all control stopped.
I hit reset and after 2 Fsck dumps got to the
place where I should get a login: No login.
Let the machine sit and it gave out some "panic double bus errors"
I just reinstalled everything.
I conclude that the fix disk is not a wise thing to do if you are
lucky enough to have HDB Uucp.
If I get up the courage {and strength} I may try again leaving Uucp
off of the fix list.
However, I keep remembering an old political slogan "If it ain't broke
do'n fix it"
rkwrjg@sialis.mn.org (Robert J. Granvin) (08/10/89)
>I received AT&T 3.51 Fix Disk ver 1.0 Fix 1014. > >I installed it on one of my 3B1s with: > >HoneyDanBear UUCP Only this is significant. >I installed the whole works...there are 8 fixes. > >uucp stopped. Of course it will. HDB is not a supported package, and the fixdisk only cures problems with the stock UUCP. I'm very likely wrong on this, but I think it may make note of that in the descriptions section for that fix, and tell you not to install this fix if you are running HDB. >I uninstalled HDB and HDB administration. Not actually necessary, as I believe only uucico was replaced. >During the latter process, all control stopped. >I hit reset and after 2 Fsck dumps got to the >place where I should get a login: No login. >Let the machine sit and it gave out some "panic double bus errors" This is something different. I can't see how uucp/uucico/whatever would cause this, and I know for a fact that Fixdisk 1.0 is not damaging in and of itself. Here, I'd say, you had a "fluke". Fixdisk 1.0 isn't to blame, unless you made an installation that was clearly marked as something not to do. However, I don't recall anything from Fixdisk 1.0 that was that ingrained to cause panics. >I just reinstalled everything. One solution, but may have been drastic. >I conclude that the fix disk is not a wise thing to do if you are >lucky enough to have HDB Uucp. ERROR! The fixdisk solves some definately significant (and insignificant) problems. If you ever plan on installing (the future) Fixdisk 2.0, it's possible that you'd be required to install Fixdisk 1.0 first. However, to expand on the next statement: >If I get up the courage {and strength} I may try again leaving Uucp >off of the fix list. The fixdisk provides 8 fixes. Each fix has a description of the repairs (short yes, but a description none-the-less) and asks you whether you want to install each fix. You are forced to make a yes/no decision. The installation also warns you on other fixes that if you do not have certain packages or features installed to NOT install that particular fix. In the case of the UUCP fix, if you use HDB, do not install this fix. Installing the other fixes just isn't going to do you any harm, and just may do you some good. No matter what you do, it's always good form to read everything that's made available to you, and consider what you have in that process. Having installed Fixdisk 1.0 on many machines, all of different configurations, and having watched it run for a couple of eons, I know for a fact that 1.0 isn't a problem in and of itself. >However, I keep remembering an old political slogan "If it ain't broke >do'n fix it" And if you don't fix it, you won't improve it. "Broke" is relative. I found I had real problems with stock 3.51. Fixdisk 1.0 repaired them. To me, 3.51 is broke, and 3.51a (incorrect term :-) is "less broke". Fixdisk 2.0 will be even a lot more "less broke", and in many respects "really wayfar fixed up" (Even though some of it may not actually be apparent. Neat how that works, huh? :-) As far as the fixdisks go, having had some external involvement, I can see the work that goes in to repairing something either exceedingly obscure or best described by the phrase "blah blah is broke." The work involved to fix some things, some things that people out there are seeing today, and a large number of people aren't (yet :-), is not trivial. I'm never squeamish to complain about AT&T support when it's bad, but in this area, I know for a fact that it's quite exceptional (and it's not widely seen). Good job, folks! (You know who you are). -- ________Robert J. Granvin________ INTERNET: rjg@sialis.mn.org ____National Computer Systems____ BITNET: rjg%sialis.mn.org@cs.umn.edu __National Information Services__ UUCP: ...amdahl!bungia!sialis!rjg "Insured against Aircraft, including self-propelled missiles and spacecraft."
david@ms.uky.edu (David Herron -- One of the vertebrae) (08/10/89)
One of the files the fixdisk replaced was
/usr/lib/uucp/uucico
it's no wonder that UUCP stopped working for you.
--
<- David Herron; an MMDF guy <david@ms.uky.edu>
<- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<-
<- "So raise your right hand if you thought that was a Russian water tentacle."pat@rwing.UUCP (Pat Myrto) (08/12/89)
In article <12385@s.ms.uky.edu>, david@ms.uky.edu (David Herron -- One of the vertebrae) writes: > One of the files the fixdisk replaced was > > /usr/lib/uucp/uucico > > it's no wonder that UUCP stopped working for you. In the above, the uucico was a Version 2, which overwrote HDB uucico. The above example is why I have formed the habit of examining the contents of an archive (disk or otherwise) and save things I am unsure about before I let it overwrite anything. In the case of cpio archives on floppies, this is by doing (from a shell prompt): cpio -iBctv </dev/rfp021 and watching the listing. The "t" option prevents an actual write, and causes a listing instead, the "v" makes the listing in long form. If its an "auto-install", I also like to extract into a test directory, and look over the install script before I commit and actually install the package. This has saved me headaches on a number of occasions. Even if "Install" scripts save things, often it is not complete, so by doing this I get a chance to save - usually as a tar file - anything I may want to recover if the install doesn't go as expected. -- pat@rwing ...!nwnexus!mltco!camco!happym!\ (Pat Myrto), Seattle, WA ...!uunet!pilchuck!rwing!pat ...!uw-beaver!sumax!polari!/ WISDOM: "Travelling unarmed is like boating without a life jacket"
rjg@sialis.mn.org (Robert J. Granvin) (08/13/89)
>> One of the files the fixdisk replaced was >> >> /usr/lib/uucp/uucico >> >> it's no wonder that UUCP stopped working for you. > >In the above, the uucico was a Version 2, which overwrote HDB uucico. > >The above example is why I have formed the habit of examining the >contents of an archive (disk or otherwise) and save things I am unsure >about before I let it overwrite anything. In the case of cpio >archives on floppies, this is by doing (from a shell prompt): > >cpio -iBctv </dev/rfp021 > >and watching the listing. The "t" option prevents an actual write, >and causes a listing instead, the "v" makes the listing in long form. To repeat... In the case of the AT&T Fixdisks, it is not necessary to go through any convoluted gyrations or "pre-verifications". Each fix is a separate and completely user controlled installation. Each installation of each fix requires the installer to answer "yes" to the request of whether he or she wants it. Each fix also comes with a short description of the fix, and why not to install it, should that be a concern. While not foolproof, or always complete, it's there none-the-less. In the case of HDB, receiving it knowing that it is an unsupported unreleased software package, should at least have been a hint that a UUCP fix would probably be damaging, even if there were no notes about HDB with it. >If its an "auto-install", I also like to extract into a test >directory, and look over the install script before I commit and >actually install the package. This has saved me headaches on a number >of occasions. Even if "Install" scripts save things, often it is not >complete, so by doing this I get a chance to save - usually as a tar >file - anything I may want to recover if the install doesn't go as >expected. Not an unwise thing to do when you are unaware of the contents or installation. But back to the fixdisks, if you read what is made available on the screen, you won't make a mistake (and if you do make a mistake, you're not as familiar with your system anyways, so you'd still make the same mistake even IF you looked at the archive (how's that for a run-on sentence? :-)) -- ________Robert J. Granvin________ INTERNET: rjg@sialis.mn.org ____National Computer Systems____ BITNET: rjg%sialis.mn.org@cs.umn.edu __National Information Services__ UUCP: ...amdahl!bungia!sialis!rjg "Insured against Aircraft, including self-propelled missiles and spacecraft."