Multiboot's boot_device field specification + implementation bug

Multiboot's boot_device field specification + implementation bug

[Grégoire Sutre]

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

Re: Multiboot's boot_device field specification + implementation bug

[Grégoire Sutre]

Hi,

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

Out of curiosity, I tried equivalent commands with GRUB Legacy, and I 
get boot_device = 0x810100ff in both cases.

Best regards,

Grégoire

Re: Multiboot's boot_device field specification + implementation bug

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 2659 bytes --]

Grégoire Sutre wrote:
> 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.
>
Indeed multiboot1 doesn't specify which label was used. It simply
doesn't pass this information. I suggest to replace partition number
with 64-bit starting_byte field. This way you avoid problems with both
labels and sector sizes,
>
>
> 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.
>
OS developer doesn't care where the kernel was loaded from: disk,
network, flash or hyperspace. He cares only where the rest of the system
is (optionally containing a copy of the kernel). Consider following case:
You have an operating system O which recognises only filesystem FO and
bootloader B which recognises only filesystem FB. User wants to use O
with B. He copies kernel from FO to FB. But now kernel is loaded from FB
where no rest of the system is present so kernel still expects
boot_device to point to FO. To this end I think spec has to be adjusted.
It shouldn't give any backwards compatibility problems since OSes expect
boot_devices to point to their root.
> Best regards,
>
> Grégoire
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]