Subject: that new setroot()
To: None <current-users@NetBSD.ORG>
From: Michael C. Richardson <mcr@sandelman.ottawa.on.ca>
List: port-sun3
Date: 06/15/1997 22:22:09
-----BEGIN PGP SIGNED MESSAGE-----
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
there.
:!mcr!: | Network security programming, currently
Michael Richardson | on contract with DataFellows F-Secure IPSec
WWW: mcr@sandelman.ottawa.on.ca. PGP key available.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQB1AwUBM6SjSaZpLyXYhL+BAQFWRgMAiFU41oXXNj8YuM9yeIqX9Hut+YtS4l2c
y/n+Y/oGzC1LaMSmZNcrvl0wgGoSrghqSHpc/tTNiowbTBuLRqXKYbENdTc89PDu
oAUVB8Gcd2fK1STEqNe+8dclBDgV/9qN
=fp39
-----END PGP SIGNATURE-----