grub-devel
[Top][All Lists]
Advanced

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

Re: Are BSD partitions not supported?


From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: Are BSD partitions not supported?
Date: Mon, 31 May 2010 23:16:09 +0200
User-agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109)

Grégoire Sutre wrote:
> On 05/19/2010 09:20 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>
> [snip]
> -  delta = grub_partition_get_start (disk->partition);
> +      delta = grub_le_to_cpu32 (whole_disk_be.offset);
>
> As dicsussed on irc, this makes the delta completely dependent on the
> c: entry of the disklabel, which could be bogus.
>
Looks like we have to have different behaviour for different BSDs. Since
it looks like generic code would fail for ThisBSD or ThatBSD, I propose
to go by as-needed basis. So I think we should:
-restrict bsdlabel to being embed into msdos partitions of types a5, a6
or a9.
-conditionalise the behaviour and use my patch for a5 (FreeBSD) and
current behaviour for a6 (OpenBSD) and a9 (NetBSD).
I recognise that it's ugly.
Another possibility is to have both (hdX,msdosY,freebsdZ) and
(hdX,msdosY,netbsdZ) syntax but it would result in many confusing ghost
partitions. But since bsdlabel is so disorganised and ugly I prefer to
limit its support to minimum.
> For instance, on NetBSD/i386, the system seems to work fine with random
> entries for c: in the disk label stored on the disk. Even a null offset
> is fine.  The in-core disklabel shown by the command disklabel (without
> -r) is the correct one.  I give an example below, which was obtained on
> system booted from wd0.
>
> IMHO, the current code is better for the cases where the offsets in the
> disklabel are absolute addresses, since it performs exactly the inverse
> translation of the one done in grub_partition_get_start(), which AFAICS
> is supposed to return the absolute address.
>
> What we want here is to diverge from that code when the disklabel
> offsets are relative.  I believe that testing whether c: has a null
> offset gives the answer.  I changed Vladimir's second patch to do that.
>
> We still have the problem that NetSBD uses c: for the whole-disk
> partition on many ports (but it's d: on i386 and amd64), see [1].  For
> those ports, the normal offset for c: is 0.  But maybe it's fair to
> assume that, on those ports, the NetBSD slice is never embedded in
> another partition?
>
> Grégoire
>
> [1] http://nxr.netbsd.org/source/s?defs=RAW_PART&project=/src
>
> On-disk label
> niagara# disklabel -r wd0
> 16 partitions:
> #        size    offset     fstype
>  a:    263088  10233405     4.2BSD
>  b:   2097648  10496493       swap
>  c:  82345673         0     unused
>  d: 117210240         0     unused
> .
> .
> .
>
> -------------------------------------------------------------------------
> In-core label
>
> niagara# disklabel wd0
> # /dev/rwd0d:
> .
> .
> .
> 16 partitions:
> #        size    offset     fstype
>  a:    263088  10233405     4.2BSD
>  b:   2097648  10496493       swap
>  c:  58605120  10233405     unused
>  d: 117210240         0     unused
> .
> .
> .
> ------------------------------------------------------------------------
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel


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


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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