9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Thomas Riemer triemer@babbitt.bernstein.com
Subject: CPU server again...
Date: Wed, 27 Mar 1996 22:56:43 -0500	[thread overview]
Message-ID: <19960328035643.t8jmrHMOqINQy7x6d_vXU7hoqBKznXVc0GW8kQ4qXpc@z> (raw)

Ok, with a lot more investigation, I'm starting to get an inkling as to what
is going on.

I've been booting the CPU server via IL.  I'm not sure how it figures
out that its supposed to boot /386/9cpu instead of /386/9pc, but anyway,
it has been mounting its root directory from the file server.  It has not
been bothering to bind the hard drive devices.  This means that
even though I have two disks in place /dev/hd0disk, /dev/hd1disk simply
don't exist, include /dev/nvram ...  Essentially anything that has
to do with the local hard drives.  Small surprize that you can't read
the /dev/nvram device if it doesn't exist!
(I don't quite believe that I didn't notice this earlier...)

Now, I know that when I boot up a standalone 9pc kernel... 
The disk partitions exist for nvram.  

Let me note that the cpu kernel  (9cpu presumeably) is the one off the 
CD-ROM dist. 

I looked at the manual stuff about "rootdir" (plan9.ini man page) - is this 
the case where one would actually use the "rootdir" option?  

Again - this CPU server is a PC.

Let me ask the dumb question - has anyone else run a CPU server on 
IDE disks only (on a PC - whereelse does one find ide)?  I'm thinking, may 
the CPU code is only aware of scsi disks.  

I should also note that the like, bind -a '#H0' /dev 
seems to do nothing...  I don't happen to have a spare scsi in the
apartment at the moment, otherwise I'd try booting off the scsi drive...
Any ideas would be much appreciated. 
  
Ah, yes... for those interested in fileservers... The fs that I finally
got running was the fs compiled off the CD-ROM.  The fs's distributed on
plan9.att.com and the binary produced by the installation program - didn't
cut it.  Granted I made the one little change to lower the number of files
as mentioned here on the list - and maybe that was all it was. 

I'm starting to think the CPU authentication never worked at all... and
somehow I faked myself out.

-Tom
BTW - its been a long, long time since I struggled with an operating system
like this... last time was an AT&T 3B2 - my first Unix box.
Come to think of it... it was always complaining about NVRAM too.  mmm... 
haven't booted that puppy up recently.

---- Where theory and reality meet. 
---- Thomas Riemer, triemer@wesleyan.edu







                 reply	other threads:[~1996-03-28  3:56 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=19960328035643.t8jmrHMOqINQy7x6d_vXU7hoqBKznXVc0GW8kQ4qXpc@z \
    --to=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).