[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 (X11/20090707)


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,


reply via email to

[Prev in Thread] Current Thread [Next in Thread]