>> You guys rock.  If I could get a 1.5U kernel bound to root on sd0a, swap on
	>> sd0b, file system type ffs (vs. generic) - i.e., so it doesn't ask at boot
	>> time every time - and with the "hme0: invalid packet size 2048; dropping"
	>> error commented out, I'd be a *very* happy camper.
	> 
	> Hm.  That's not fixed yet?  Damn.  I need to rewrite the bootpath code
	> from scratch one of these days.  And I will too, if I ever get another
	> machine that has that problem.

	What's not fixed yet?  The root/swap/fs questions?  That only seems to
	work if I build a custom kernel with them hardwired; all the test GENERIC
	kernels always ask.

The kernel should be able to determine the device it booted from and
unless you specified the `-a' option automatically use that for root
and swap.  This works right on SBus machines and IDE disks, but the
kernel is unable to identify SCSI disks on PCI contollers.

	The "hme0: invalid packet size 2048; dropping" problem, though, is another
	kettle of fish.  Right now I'm copying a new /emul/svr4 setup over from
	a Solaris 7 system (poll: which is the best Solaris release to use the
	libraries from, so that compat_svr4 will work best?  2.6?  7?).  I'm
	doing the "tar -cf - | rsh netbsdsystem 'cd /emul/svr4/usr/lib ; tar -xpBf -'"
	step now, and I'm getting a GAJILLION of those "invalid packet size" errors.
	<Sigh>  I never see them when the Ultra 5+ is booted as a Solaris 7 AutoClient.
	I think NetBSD really is seeing them as 2048-byte packets when they're really
	not ...

I have tested it with solaris 2.6 and 2.8.

	Otherwise, though, I'm a happy camper - if this new /emul/svr4 tree will make
	Acrobat Reader 4 for Solaris run without core dumping like it has been, I'll
	be even happier  :-)

Acrobat is a 32-bit application so you will need to use /emul/svr4_32.

Eduardo