[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Multiboot's boot_device field specification + implementation bug
From: |
Grégoire Sutre |
Subject: |
Multiboot's boot_device field specification + implementation bug |
Date: |
Tue, 26 Jan 2010 00:37:40 +0100 |
User-agent: |
Mozilla-Thunderbird 2.0.0.22 (X11/20090707) |
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
- Multiboot's boot_device field specification + implementation bug,
Grégoire Sutre <=