Hi Pavel,

> > It's probably my lack of experience, but I was unable to see a way
> > to get config (kernel file) to do the wiring. Since my previous
> > experience
> 
> Maybe http://www.netbsd.org/Documentation/kernel/#scsi_device_numbers
> will help you.

Right, that's what I'm trying to do, hard wire it in the config file,
since I am not able to see how to do it using config interactively on
the kernel binary.

> > with *BSD has been in OpenBSD, I was comfortable with compiling a
> > kernel with a rewired configuration file, or at least, I thought I
> > was.
> 
> But, why did you do it with -current kernel sources instead of the
> same version that you were using (2.0RC4)?

Because I'm stupid? :-) Seriously, though, I did not use a tag when I
updated via CVS, and when I reviewed several files in -current, they
seemed to generally match 2.0RC4, at least the ones I was interested in.
On the one hand, that was a mistake, but on the other hand, I was
expecting to go into cross-compiling eventually...(and at least I
managed to find both a kernel panic and a problem with the default
partitioning scheme in sysinst - the use of a memory file system
for /tmp, as has been noted elsewhere as a cause of kernel crashes, can
also fill up during a userland build and cause the build to fail w/
128M of RAM).

I am debating the wisdom of continuing this path instead of pulling the
2.0RC4 tag.

> > 
> > With two identical NetBSD installs on two separate hard drives on
> > the same Mac, there appears to be a problem with properly
> > identifying the boot device and the assumption is sd0; however, if
> > the boot device is actually a higher target ID in the SCSI chain, it
> > gets attached as sd1 while the kernel appears to go looking for
> > /sbin/init on sd0. Changing
> 
> To temporary fix this you should be able to boot with the -a flag and
> when the kernel asks for the root filesystem, enter sd1.

Ah! Thanks! I will try this.

> In general, unconsolidated kernel and userland shouldn't cause panics
> and if they do, it's a bug, not your error.

I like this perspective, and not because it absolves me of blame ;-) It
just makes for a more user-friendly attitude.

> After install, no. But this probably doesn't help you, because you
> need to have a working kernel first to install the -current userland.
> (newer kernel is compatible with older userland, but not vice versa,
> so if you install -current userland while you are still using old
> kernel, you are lost.)

Yikes. You know, this goes back to the

http://www.netbsd.org/Documentation/current/

documentation having different build instructions depending on how you
obtain the source code. Since I was not obtaining via ftp and tarballs,
I did not read the warning about this because it does not appear in the
instructions on how to build when obtaining from cvs. If the build
command listed in the cvs portion of the document does not install a
-current kernel, I would have been hosed.

> > http://www.netbsd.org/Documentation/current/#using-anoncvs
> 
> The document seems confusing at least.

Probably only to idiots like me ;-)

tim