9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: John Floren <slawmaster@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] have installed plan 9 on many hosts, can't get any of them to "share".
Date: Thu,  9 Dec 2010 19:54:17 -0500	[thread overview]
Message-ID: <AANLkTimOBZuqFLNG+ZYH_rexWRnJr1rvY+H3bBKBHxi4@mail.gmail.com> (raw)
In-Reply-To: <09B9A3AC-3D0C-4562-92C0-1B373B31DADA@xmission.com>

On Thu, Dec 9, 2010 at 7:39 PM, Lloyd Caldwell <lmc@xmission.com> wrote:
>
> John, thanks,
>
>>
>> If you follow the standalone CPU installation instructions on the wiki
>> to the letter, you will have a cpu/auth/file server. It's then easy to
>> export fossil to clients, just set up the configuration to listen on
>> the appropriate port (the document you want is linked from the
>> standalone instructions).
>
> I followed it to the letter. It has mistakes or inconsistencies (i think?).
> for example it says:
>        proto=il - recommended (isn't this obsolete?)
>        bootf=/386/9pc (It should be bootf=/386/9pxeload)

il is obsoleted, although a few people do still use it. I have never
used the proto= attribute, don't think you need it. You want to set
bootf=/386/9pxeload for the systems that you want to netboot, for the
others you don't have to set the attribute.

> the bind loop doesn't work with 9pccpuf kernel from install cdrom (circa dec
> 2009):
>        for (i in m i S t)
>                bind -a '#'^$i /dev >/dev/null >[2=1]
> fails, complains of no frame buffer (this is from the installation kernel
> /386/9pccpuf).  This means no rio on server console so fixing things
> requires rebooting into a terminal kernel (I actually know sed quite well
> but one gets tired of sed 's/foo/bar/'  filename >j ; mv j filename :-).
>

I put this in the wiki a bit ago: "In this case we have m (mouse), i
(draw), S (sd - disk), and t (uart - serial); if you get errors about
/dev/realmode, include P in this list". If you're not getting
/dev/realmode complaints, I guess it must be something else.

> there is no file /rc/bin/service/tcp567 (install image from dec 2009)

If it's not there, don't worry about it! I think this might be a
double-check thing, or it might just be an old instruction.

> The example of a combined cpu/auth server, is not consistent, it actually is
> not combined, unless I'm reading it wrong auth is different then cpu. An
> excerpt from the 'Configuring a standalone CPU server' wiki page (cut and
> pasted at 5:17pm mst today):
>
> A simple example for a combined cpu/auth server, the 192.168.1.100 machine,
> could be:
>
> ipnet=mynet ip=192.168.1.0 ipmask=255.255.255.0
>        auth=bouncer
>        cpu=cycles
>        dns=lookup
>        dnsdom=9fans.net
>
> authdom=9fans.net auth=bouncer
>
> ip=192.168.1.100 sys=bouncer dom=bouncer.9fans.net
> ip=192.168.1.101 sys=cycles dom=cycles.9fans.net
> ip=192.168.1.102 sys=lookup dom=lookup.9fans.net
>

What that configuration says is that the *default* cpu server is
cycles. That doesn't necessarily mean bouncer isn't a cpu server too.

>
>>
>> Then, once you've got that set up, you install a terminal on another
>> machine. When it asks for a root, say "tcp" then give it the IP for
>> your standalone server when it asks. Boom, your terminal now has
>> remote root. You'll probably want to configure /lib/ndb/local to keep
>> track of all your systems...
>>
>> Configuring PXE isn't that tricky but I don't want to run through the
>> setup process right now, let me know if you need a rundown.
>
>
> If I boot this box from install cdrom and it can obtain ip address from
> dhcpd server running on cpu/auth/fs box and see that fs and auth are setup
> correctly.  If I attempt to use cpu command from cdrom booted terminal I get
> the following error when attempting to connect to 10.0.1.6 (my combined
> cpu/auth/fs server).
>
> term% cpu -h 10.0.1.6 -u lmc
> cpu: can't authenticate: 10.0.1.6: auth_proxy rpc write: p9sk1@p9-net:
> auth_getkey: no /factotum or /boot/factotum: didn't get key !password?
> dom=p9-net proto=p9s
>
> the cpu/auth/fs server /lib/ndb/local file is:
>
> #--- start of /lib/ndb/local
> ip=127.0.0.1 sys=localhost dom=localhost
>
> ipnet=p9-net ip=10.0.1.0 ipmask=255.255.255.0
>        auth=xeon0.p9.net
>        cpu=xeon0.p9.net
>        fs=xeon0.p9.net
>
> authdom=p9-net auth=xeon0.p9.net
>
> ip=10.0.1.6 sys=xeon0 dom=xeon0.p9.net ether=0007e933c735
>
> ip=10.0.1.7 sys=xeon1 dom=xeon1.p9.net ether=0007e933ca35
>        bootf=/386/9pxeload
>
> #--- end of /lib/ndb/local
>
> the plan9.ini file for xeon1 is in /cfg/pxe/0007e933ca35 and contains:
>
> #--- start of xeon1 plan9.ini diskless boot config
>
> nobootprompt=ether0!/386/9pc
> mouseport=ps2intellimouse
> monitor=xga
> vgasize=1024x768x16
>
> #-- end of /cfg/pxe/0007e933ca35

I'm not sure if this is going to work with the cdrom-booted machine.
It isn't going to have the /lib/ndb/local file, right? So it doesn't
know what the auth server is...

I might be mis-reading the situation.



>
>>
>> Basically, "> Where might I go for a walk thru in setting up a simple
>> plan9 installation one cpu/auth/fs and one terminal?" is answered by
>> "Use the standalone install instructions... and that's basically it."
>>
>> If you'd give us the errors you're seeing from cpu, we might be able
>> to help. "Weird errors" isn't very informative!
>>
> --> Error message from net booting.
>
> Intel(R) Boot Agent FE v4.1.16
> Copyright (C) 1997-2004, Intel Corporation
>
> CLIENT MAC ADDR: 00 07 E9 33 CA 35 GUID: 18B58355 0CDA DA11 0080
> 35CA33E90700
> CLIENT IP: 10.0.1.7  MASK: 255.255.255.0  DHCP IP: 10.0.1.6
>
> Plan 9 from Bell Labs by PXE
> ELCR: 0E20
> pcirouting: 8086/2483 at pin 2 irq 9
> FLAGS=10292 TRAP=e ECODE=0 PC=8000a9b3
>  AX f000eef3   BX 00000200  CX 00000000    DX 80802798
>  SI 80057e3c  DI 00000000   BP 00000000
>  CS 0010 DS 0008   ES 0008   FS 0008  GS 0008
>  CR0 80000011 CR2 f000eefb CR3 00094000
> panic: exception/interrupt 14
>
> Press almost any key to reset.._
>
> <-- End error message from net booting.
> I can successfully net boot, linux, freebsd and msdos on this box.  I get
> roughly the same errors (different register values) on other boxes.  I have
> via epia-m boxes, intel dual xeon boxes, amd64 dual processor boxes and
> older pentium 4 boxes. 9pxeload fails similarly on all of them.  I swapped
> out the network switch and also tried a "dumb" hub.
>
> I tried net loading 9pxeloaddebug but the box hangs after getting it's ip
> address, i.e. no 'Plan 9 from Bell Labs by PXE' banner.
>
>> If it comes down to it, I can exchange some of my config files with
>> you. I have a standalone cpu server running, with PXE boot working
>
> Maybe instead of focusing on net booting.  Are there instructions on how to
> connect from one standalone system to another?  cpu doesn't seem to work.
>  If I knew I could actually login to a remote box that would probably help?
>  Maybe not?  I'm probably thinking about plan 9 all wrong.
>
> anyway thanks.
> Regards
> Lloyd
>
>>
>> John
>>


I'm not exactly sure what's going on with the netbooting problem. The
other best solution is this:
* Install Plan 9 on your terminal machine (to the hard drive)
* When you boot, tell it to get root from TCP and give it the
appropriate IPs (10.0.1.6 in your case)
* Now you have a terminal sharing the root of the server. You can also
cpu if you need, but it's not as big of a deal when you share a root.


John



  parent reply	other threads:[~2010-12-10  0:54 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-09 22:53 Lloyd Caldwell
2010-12-09 23:01 ` erik quanstrom
2010-12-09 23:06 ` John Floren
2010-12-10  0:39   ` Lloyd Caldwell
2010-12-10  0:50     ` erik quanstrom
2010-12-10  0:54     ` John Floren [this message]
2010-12-09 23:26 ` Steve Simon
2010-12-10  3:59 ` Corey
2010-12-10 14:13 ` John Stalker
2010-12-10 15:34   ` Steve Simon
2010-12-10 15:42     ` erik quanstrom
2010-12-10 15:42     ` John Floren
2010-12-10 16:31       ` ron minnich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AANLkTimOBZuqFLNG+ZYH_rexWRnJr1rvY+H3bBKBHxi4@mail.gmail.com \
    --to=slawmaster@gmail.com \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).