[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 2.0.0.22 (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
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
signature.asc
Description: OpenPGP digital signature
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: Multiboot's boot_device field specification + implementation bug,
Vladimir 'φ-coder/phcoder' Serbinenko <=