Subject: that new setroot()
To: None <current-users@NetBSD.ORG>
From: Michael C. Richardson <>
List: current-users
Date: 06/15/1997 22:22:09

  I finished building a sun3 kernel this afternoon (it takes a long
time to build a kernel... on a sun3). It was supposed to be a ramdisk
kernel with your basic network diag tools: it will boot across the
net, and let me do network protocol testing.

  Something about the way that kern_subr.c:setroot picks the root disk
is not working right.
  If I had CVS read access, I'd revert my tree to just prior to the
kern_subr.c changes and see if this made a difference. As it is, I
have a May 1-ish sup (which I update as required), and the bleeding
edge one. 

  First, most superficially obvious: it appears that the way that
md_attach_hook() is different now. Comparing i386's and sun3's
md_root.c shows that md_attach_hook used to be called from somewhere
that the stock "xx0 at ..." was going to be printed. While this is
cosmetic, it may point to a larger problem.

obmem0 at mainbus0
enabling interrupts
 fixed, 4096 blocksboot device: le0
device md0 (0xd00) not configured
root device (default md0a): 
dump device (default md0b): 
file system (default ffs): 
root on md0a dumps on md0b
warning: no /dev/console
init: not found

  The md0 .. not configured is strange. This is coming from setroot.
  If in fact, it is not properly configured, that would explain why
the /dev/console is missing... but how come the "disk" got mounted
properly? I'm pretty sure that the image that got copied into the
kernel is good, and I know it has a /dev/console.
  Any ideas? I'm out of time, and will have to just do NFS, but that
isn't ideal for later... I'd like to tftp a ramdisk kernel.
  I may try and build a SSTO/i386 kernel and see if md0 still works

   :!mcr!:            |  Network security programming, currently
   Michael Richardson | on contract with DataFellows F-Secure IPSec
 WWW: PGP key available.

Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface