[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Multiboot's boot_device field specification + implementation bug

From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: Multiboot's boot_device field specification + implementation bug
Date: Thu, 11 Feb 2010 04:07:06 +0100
User-agent: Mozilla-Thunderbird (X11/20091109)

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
> address@hidden

Vladimir 'φ-coder/phcoder' Serbinenko

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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