> Now looking at pbr.S, it seems to look for that in the 3rd sector (so pbr is 
> in sector 0, a disklabel should be in sector 1 and the second stage should 
> be in sector 2?  Also, I am assuming sector=512 bytes)
> 
> I tried zeroing sector 0 of /dev/rwd0a (equal to /dev/rwd0c? Kernel claims 
> that rwd0c is not configured but it is in the disklabel),

You can't read/write the disk using wd0c.....

> and then verified 
> that installboot puts the pbr in there. Good. I tried zeroing sector 2 (dd 
> if=/dev/null of=/dev/rwd0a bs=512 count=1 seek=2) and again verified that 
> installboot wrote there.  Also good.  But it still won't run.  Not Good.  
> (At each stage, including after zeroing, I verified with hexdump)
> 
> So, pbr just doesn't like the second stage - my question now is, what is the 
> magic number (I'll check the sources later) and where should it be?  I'll 
> look for it using hexdump.

The second sector should start:
00000400  eb 3a 89 f6 d1 b6 86 78
Followed by the boot parameters.
The 'magic' number is the last 4 bytes:
	'x' << 24 | 0x86 << 16 | 0xb << 12 | 'm' << 4 | 1
	(x86 boot magic 1)

> The NetBSD mbr bootselector did boot the interactive bootloader properly...
> why?  Is it bypassing the pbr?

No, it reads the pbr.

One possibility is that there is a bug in the way the pbr.S code scans
the mbr (and extended partition list) looking for the netbsd partition.
The netbsd mbr code passes the base address of the partition in %esi,
grub won't so the pbr.S code will scan the partition table twice.

Try the following patch:

Index: pbr.S
===================================================================
RCS file: /cvsroot/src/sys/arch/i386/stand/bootxx/pbr.S,v
retrieving revision 1.9
diff -u -p -r1.9 pbr.S
--- pbr.S	2003/10/13 06:08:28	1.9
+++ pbr.S	2003/12/20 22:02:42
@@ -207,6 +207,7 @@ no_netbsd_ptn:
 	set_err(ERR_PTN)
 	jz	error
 	xorl	%esi, %esi
+	movl	%esi, lba_sector
 	jmp	start
 
 /*


	David

-- 
David Laight: david@l8s.co.uk