kernel panic while booting from other than `/netbsd'

[Taylor R Campbell <campbell%mumble.net@localhost>]

Hello!  This morning I built new kernels from the netbsd-4-0 and
netbsd-4 tags, and tried to boot my PowerBook G4 with them.  I put
several kernels in /:

   netbsd40-release - what I installed to begin with from the CD
   netbsd40-stable - what I built from the netbsd-4-0 tag
   netbsd4-stable - what I built from the netbsd-4 tag

Pretty consistently, then, when I tried to boot from the Open Firmware
prompt with

   boot hd:9,\ofwboot.xcf hd:10,/netbsd...

for some text in the ellipsis, it would either hang after `console
type unknown; assuming ADB keyboard' or repeatedly panic while trying
to drop into DDB until I rebooted the machine.  The initial panic text
scrolled past too fast for me to see, and I didn't really want to
repeat the process enough times to patch together the fragments of
what my vision could manage.

On a whim, I tried moving the kernel I wanted to boot to /netbsd and
booting from that.  Now the machine boots.  I was told in #NetBSD on
Freenode that generally the system does not rely on the kernel's being
stored in a file called `/netbsd', save for a couple of small,
irrelevant parts, so this perplexes me.

There were some times when I was able to boot from a kernel named
something other than `/netbsd'.  Initially I put the distributed
kernel on the HFS+ boot partition under the name netbsd-GENERIC.gz,
and the three different effects of booting -- success, hang, or panic
-- seemed to alternate randomly, although to begin with it always
booted successfully.  With files on the NetBSD `a' partition (in
position 10 on the partiton map, hence the above Open Firmware
incantation), though, with names other than `/netbsd', it pretty
consistently failed.  So far I don't think it has failed with a kernel
in `/netbsd'.

I probably ought to do some more testing, although now that I can boot
from `/netbsd', I have upgraded to the netbsd-4 tag, which makes me
nervous about booting earlier versions of the kernel.  Am I tickling a
known bug, and is there a known workaround for it?  If not, is there a
convenient way to halt the panicking but record the text it spits out?