[9fans] AUTH, FS, etc.

[Lucio De Re <lucio@proxima.alt.za>]

I have encountered a few seemingly unrelated problems, some are
leftovers from a 2nd edition installation I am not yet ready to
sacrifice.

- A long time ago, I lost the AUTH/CPU server's ability to figure
  out or retain the IP information.  Today, I presume it would
  obtain the info using DHCP.  I'd like to know, however, where
  a PC-based CPU server saves this information.  Currently, I have
  it in the plan9.ini file, but I have to accept each entry before
  the server can start.  That's a pain.  I tried destroying the
  NVRAM partition, but that only prompted me for the authentication
  information.  From the 2ed manual:

    If you've just done the installation, the installer will already
    know the pertinent IP addresses for this machine; if not, you'll
    have to provide them. ...

  Nowhere can I find where the installer would have put them in the
  first place :-(

- My 2ed file server is also being obstructive (and, once again, it is
  quite likely that I'm missing a significant bit of information).  I
  have an "other" filesystem I created long ago on a separate drive
  and would now be very useful to hold the 3ed stuff until I can
  migrate everything.

  My problem is that I can't create files at the root of "other", I
  had to "create" a directory "3ed" in which I then unwrapped the
  various bits of distribution.  This would be quite acceptable,
  except that mounting il!muddle!other/3ed seems much more difficult
  than just il!muddle!other (or is it just me?  I'll come back to
  that, anyway) and in any case I would like to know _why_ I can
  write to the hierarchy from 3ed down, only.

  I used "ream" to drop restrictions on "other" but they really
  seemed to apply only a level below the root.

- Coming back to CPU servers, I'm sticking to the 2ed one because it
  works.  Just trying to boot a 3ed kernel on it goes no further than
  the CPU identification (i486DX-4/100) and reboots.  It takes keen
  observation to catch the CPU id line, as the machine seems to reset
  immediately.

  Now, all I would want, is to bootp a different CPU kernel on the
  same hardware, but I can't determine what's causing the immediate
  reboot.  As you can imagine, the 2ed kernels seem perfectly at home
  with the hardware.  I think it's a motherboard thing, having swapped
  out a few adapters, but I'm willing to try a few other tricks if
  anyone can suggest them.

- I also tried to boot a workstation nearly diskless by pointing its
  plan9.ini along the lines of

	bootfile=sdC0/9fat/9pcdisk
	rootdir=3ed
	rootspec=other
	bootdisk=il!192.96.32.134

  I hadn't set my heart on success here, the man page for plan9.ini is
  a little unconvincing; the pain was to get the system restarted so
  I could restore the plan9.ini file to the point where the system
  would reboot correctly (and without a panic about not finding the
  file server or the specified file).

  I presume I should rather change the plan9.ini file on a floppy in
  future, I seem to recall someone pointing out that it would get
  priority in some fashion (someone care to expand on that?).

  I think it is moderately clear from the above that I was trying to
  bypass the problems with my 2ed file server, and I presume that with
  a little bit of hacking it can be done, but it must be easier to
  work with some help from the experts :-)

  The section on the root* and boot* entries in plan9.ini(8) can use
  some corrections, too.

- Another point I'd like some help with is getting DHCP and BOOTP to
  cooperate - presently, to boot the 2ed CPU server, I have to switch
  off Ted Lemon's DHCPd and start the hacked version of CMU's BOOTPd
  which understands the P9 vendor extensions.  I know it is none of
  this forum's business to deal with DHCP, but I wonder if it is
  possible, while I'm still stuck with limited boot capabilities, to
  persuade ISC DHCPd to handle the 2ed boot requirements.  I'm caught
  in a bit of a chicken-and-egg situation, here.

Thank, everyone, for your patience.

++L