[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: System crashes in 7.2



    Date: Wed, 1 Jun 88 16:43 EDT
    From: miller@ACORN.CS.ROCHESTER.EDU (Brad Miller)

	Date: Wed, 1 Jun 88 10:48:00 PDT
	From: timelord@eos.arc.nasa.gov (G. Murdock Helms)


	I'm trying to load 7.2 at our site, and I'm having some difficulty with
	setting the site on the fileserver.  I have been able to set the site
	correctly to Barracuda (our fileserver) and have done an incremental 
	save.   However, if I reboot the incremental world and attempt to 
	Restore Distribution, the file server complains that "DIS-LOCAL-HOST
	does not support rtape services".  If I ask for a menu to respecify
	which host the tape is mounted on, and ask for either "Local" or type
	in "Barracuda" for "Other", the menu highlights "Local" and will then
	let me proceed (rtape services do indeed exist on Barracuda).

The real problem is that the default tape spec offered is incorrect.
The default should be Local:Cart, instead of DIS-LOCAL-HOST:CART.  We
are aware of this problem, and it's on the list to be fixed.  In the
meantime, for any Restore Distributions, make sure you specify the tape
host as either the local machine, or another machine at your site, once
you have done a Set Site.   Sorry for the difficulty.

    We ran into a similar problem. DIS-LOCAL-HOST is in the DISTRIBUTION
    namespace, which your machine knows about, though it won't necessarily tell
    you simply if DISTRIBUTION isn't on your local namespace's search list (no
    reason it should be, either). To prove it: just edit object host
    DISTRIBUTION|DIS-LOCAL-HOST.

    Anyway that isn't the problem. The problem seems to be more related to the
    fact that you did the set-site on the primary namespace server/file server
    (at least, that's how I ran into it). To work around it:

    1. Bring up the distribution 7.2 on a non-server host (neither namespace nor file).

    2. do the set site on this host, either letting it get the info it needs
    from the network, or tell it explicitly who the namespace server is.

    3. Save this world (incremental).

    This world can then be booted on your server, and it will discover it is the
    (primary) server and update it's idea of the namespace from the files. You
    should then save this resulting world for this machine.

    What we do locally is:

    Build a site-configured world (from #3, above).

    Add Comm software (e.g. TCP, NNTP) software, and the site system and save this
    world. 

    Then build other worlds. ONe for the file/name server just tells itself it
    is a server (see previous notes on this subject in this list), but you could
    boot the comm world on your server and load any local server hacks you want
    there (i.e. server-finger), then save it's world. Similarly for secondary
    namespace servers, since they should store a version of the namespace in the
    booted world too (full updates of entire namespaces take too long, esp. if
    you are not going from a file). You can build your normal user worlds on top
    of the comm world too at this point. Everything can be incremental, though
    there is some reason for making your namespace servers do a full-gc and
    complete save (since only a full-gc will collapse multiple references to the
    same object in different namespaces).

    Hope this helps,

    ----
    Brad Miller		U. Rochester Comp Sci Dept.
    miller@cs.rochester.edu {...allegra!rochester!miller}