simon@groucho (Mike Simon) (06/01/90)
Fellow Apollo admin persons:
I'm trying to install SR 10.2 on a DN3500 for
the first time (both it and myself are virgins
at this point.) All goes well through system testing
and so forth until I try to actually load some of
the kernal from the CRTG_STD_SFW_BOOT_1 tape.
(Command from the installation instructions is
EX DOMAIN_OS, from this tape.) The behavior
that I'm seeing is as follows:
It searches through the tape for domain_os,
finds and begins to execute same.
Tells me that is is loading numberous files
onto the winchester.
**Stops with the following error message:
**UID in block header does not match
those read from earlier blocks.
This is followed by the correct UID number and
the incorrect (new) one, which appear to be the
same only shifted right 8 bits:
Correct UID: 4699DC2F.800181BE
bad UID 804699DC.2F800181
My question is: Should I consider this to be a tape
error, or should I look for some basic error that I
am introducing in the installation process?
I'll be working with HP/Apollo techs directly on this,
of course, but I'm really interested in what's actually
happening here. I'm an experienced HP 9000 series
system manager, but just NOW starting to learn the
Apollo way of life.
Speaking of the Apollo way of life. I don't see a really
thorough explanation of EXACTLY WHAT is HAPPENING throughout
the load of the OS anywhere. Have I missed the box with
all the goodies?
Thanks in advance for any information you direct my way, I
guess I had forgotten what it's like to do parallel system
loads; Domain OS -> DN3500 ; Domain OS -> my brain.
Mike Simon
System Manager
Computer Science Dept.
University of Idaho
simon@ted.cs.uidaho.eduandrews@afflatus.trl.OZ.AU (Murray Andrews) (06/13/90)
In article <1990May31.202114.18004@groucho>, simon@groucho (Mike Simon) writes: > Fellow Apollo admin persons: > > I'm trying to install SR 10.2 on a DN3500 for > the first time (both it and myself are virgins > at this point.) All goes well through system testing > and so forth until .... ... > > **Stops with the following error message: > **UID in block header does not match > those read from earlier blocks.... > > My question is: Should I consider this to be a tape > error, or should I look for some basic error that I > am introducing in the installation process? We have seen this problem on most (but not all) of the stuff Apollo have sent us for 10.2 installation. It didn't happen on the OS installation but has happened on everything we have received since (including DSEE, Framemaker, patch tapes). Suspecting the tape drive or the 10.2 version of rbak we tried to read it on the following machine/OS combinations and all failed: DN570 + SR10.1 DN3000 + SR10.1 DN3000 + SR10.2 DN10000 + SR10.1.p Apollo made another copy of the tapes for us and (not bothering to test them first) sent them to us. We wasted more time trying to read these but they were just as faulty as the first batch. This process happened a couple of times. The fact that most of the tapes were sent out untested when there was a known problem was particularly irritating. Apollo wasted our time unnecessarily. The whole process has dragged out over a period of months and we are pretty sick of it. Finally we managed to get them to send us the tapes they were copying from and these loaded fine. I assume these were their orignal distribution tapes. It seems whatever they are using to copy the tapes is broken. We can copy tapes with no problem. We still can't get Apollo to supply us with some of the things we have paid for and constantly have to chase them to get the latest versions of software. In particular they have proved unable to supply us with 10.2.p, NFS version 2.1 (for SR10.2) and Domain X.25 version 2.3. God knows when we will get these and if we will be able to read the tapes when we do :-( I also found the problems people were having with their Omniback/exabyte stuff amusing. I wish we had such problems. We tried to buy one for a DN10000 many months ago. Apollo assured us they could supply one and an order was placed. Months went by with no word from Apollo. After many phone calls from us trying to find out what was going on and being promised that it would be delivered on a particular date etc etc still no tape unit. Eventually we discovered that the thing hadn't left the US yet and we could get no definite information on what the hold up was and when it would ship. The order was then cancelled. We now use an exabyte attached to a SUN and `wbak -stdout | rsh ... dd'. We can actually buy a SPARC 1+ and an exabyte for about the same money Apollo wanted for the tape unit alone. > I'll be working with HP/Apollo techs directly on this, Good luck. Murray Andrews (andrews@afflatus.trl.oz.au) Principal Engineer Telecom Australia Research Labs. *My opinions are my own and not necessarily those of Telecom Australia*
root@evtprp0b.UUCP (Eric T. Smith) (06/13/90)
In article <1789@trlluna.trl.oz> andrews@afflatus.trl.oz.au writes: >In article <1990May31.202114.18004@groucho>, simon@groucho (Mike Simon) writes: >> >> I'm trying to install SR 10.2 on a DN3500 for >> the first time (both it and myself are virgins >> at this point.) All goes well through system testing >> and so forth until .... >> >> **Stops with the following error message: >> **UID in block header does not match >> those read from earlier blocks.... > >We have seen this problem on most (but not all) of the stuff Apollo have >sent us for 10.2 installation. It didn't happen on the OS installation >but has happened on everything we have received since (including DSEE, >Framemaker, patch tapes). Suspecting the tape drive or the 10.2 version >of rbak we tried to read it on the following machine/OS combinations and >all failed: The problem appears to be with the SR10.2 version of cptape, found in the /systest/ssr_util directory. I called Apollo/HP on it and they stated for the record that the utility is A) unsupported, as if that's anything new, and, B) that is was a much missused utility so if it goes away so much the better. The solution is to save an SR10.1 version of the utility and to use it instead. Since I recovered the old version I have had no problems whatsoever with block header errors. The SR10.2 version does, however, seem to work on some nodes but not others. I suspect it is a problem with the type of tape drives SCSI, vs the old type as well as the node type. -- |----------------------------------------------------------------| |Eric Smith (206) 342-9681 (wk) | |Boeing Computer Services ....uunet!bcstec!evtprp0b!root | |M/S 03-87, P.O. Box 24346, Seattle, WA 98124-0346 | |----------------------------------------------------------------| |The answer is 42... | | --but-- | | What was the question? | |----------------------------------------------------------------| | Needless to say my opinions are MINE, not Boeings... | |----------------------------------------------------------------|