Multiboot's boot_device field specification + implementation bug

["Grégoire Sutre" <gregoire.sutre@gmail.com>]

Hi,

I'm trying to understand the specification of the multiboot boot_device 
field.  How should this information be interpreted by a kernel that uses 
a native (non-DOS) disk label?  For instance, if the MBI passed to the 
NetBSD kernel says part1=5 and part2=part3=0xFF, does this mean:

- 6th partition in the NetBSD disk-label, or
- 6th partition in the DOS disk label (MBR)?

The specification says that part1 specifies the top-level partition 
number.  However there may be several top-level disk-labels.  For 
instance: take a disk with a DOS disk-label (in the MBR) but without any 
  UFS partition in it, and install a NetBSD disk-label on the disk.  The 
NetBSD disk-label will be written in the second sector of the disk, and 
both disk-labels will be independent and top-level.  For a NetBSD 
kernel, the top-level disklabel will be the NetBSD one, and for other 
kernels the top-level disk-label may be the DOS one.


On a related note, experiments with the multiboot example kernel show 
that setting root in GRUB has an impact on the value of the boot_device 
field:

(a) set root=(hd1,2,a) ; multiboot /mbtest ; boot
     --> boot_device = 0x810100ff

(b) multiboot (hd1,2,a)/mbtest ; boot
     --> boot_device = 0x8000ffff

According to the spec, (a) is correct but (b) is wrong.  It looks like 
the boot_device field of MBI is set using the value of $root.

Best regards,

Grégoire