Is anything being done to un-break partition names?

[Marcel Moolenaar]

On Jun 5, 2009, at 1:05 PM, Pawel Jakub Dawidek wrote:

> On Fri, Jun 05, 2009 at 12:26:04PM -0700, Marcel Moolenaar wrote:
>>
>> On Jun 4, 2009, at 10:12 PM, Pawel Jakub Dawidek wrote:
>>
>>> On Thu, Jun 04, 2009 at 04:18:09PM -0700, Juli Mallett wrote:
>>>> Hey folks,
>>>>
>>>> If I install 7.2 (or old 8-CURRENT) and partition a drive
>>>> "dangerously
>>>> dedicated" and answer No when asked if I want to create a true
>>>> partition entry, and then install as normal, my system is set up  
>>>> with
>>>> partitions named like da0s1a.
>>
>> That's your problem. In a DD setup, you don't have slices.
>>
>>>> Newer 8-CURRENT instead names the
>>>> devices da0a,
>>
>> This is correct.
>>
>>>
>>> I don't think it was. For me it's a bug in GEOM_PART_MBR, which has
>>> problems detecting MBRs properly.
>>>
>>> Shame on you, Marcel!:)
>>
>> The bug is on your disk and as such in sysinstall. GEOM_PART_MBR
>> detects the MBR just fine. If you don't have GEOM_PART_BSD in
>> your kernel your will in fact get the MBR slices. The problem
>> for you is in the fact that you have a BSD disklabel in sector
>> 2, which takes precedence. A disk partitioned as a BSD disklabel
>> nested in an MBR slice can *NEVER* have a BSD disklabel in the
>> 2nd sector on the disk. The fact that there is a BSD disklabel
>> in sector 2 means that the disk is DD and that is what you get
>> for gpart.
>
> This is interesting:
>
> bridge:root:~# bsdlabel /dev/ad0
> # /dev/ad0:
> 8 partitions:
> #        size   offset    fstype   [fsize bsize bps/cpg]
>  a: 10497792       16    unused        0     0
>  b:  2097152 10497808      swap
>  c: 12594960        0    unused        0     0         # "raw" part,  
> don't edit
> bridge:root:~# bsdlabel /dev/ad0s1
> # /dev/ad0s1:
> 8 partitions:
> #        size   offset    fstype   [fsize bsize bps/cpg]
>  a: 12070609   524288    4.2BSD     2048 16384 28552
>  b:   524288        0      swap
>  c: 12594897        0    unused        0     0         # "raw" part,  
> don't edit
>
> Anyway, why BSD disklabel takes precedence over MBR for gpart?

The BSD disklabel has an MBR immediately preceding it. While the
MBR by definition has no valid partition information, there are
2 reasons not to take this too seriously during the taste:
1.  By design GPT can only have a PMBR, but this has not been
     enforced in practice. As such, the existence of valid MBR
     slices is not a reason to ignore the GPT. The BSD disklabel
     follows this principle by virtue of having a MBR compliant
     boot record immediately ahead of it, like GPT.
2.  False negatives cannot not be eliminated when ignoring the
     BSD disklabel when the MBR has slices. It's better to bank
     on the fact that there cannot be a BSD disklabel immediately
     following the MBR when that disklabel is actually nested and
     inside a MBR slice. Thus the existence of the BSD disklabel
     in sector 2 is enough proof that the MBR is part of the BSD
     disklabel and not on its own. Just like with GPT.

> Are you happy with users upgrading their system and finding it no  
> longer
> boots?

I'm not happy about it, but I haven't found an acceptable
solution until this discussion (but see below).

> I think that even a note in UPDATING is not enough, we should really
> make it to just work after the upgrade. Why not to change priorities  
> and
> accept MBR first?

That introduces significant breakages in normal setups.
The priority should not be changed. It's resulting in
the right behaviour and any exceptions to that (i.e.
we need the wrong behaviour) should be coded explicitly.

The closest we can get is by having the BSD disklabel
code check if there are valid MBR partitions defined
and if yes, back-off. This covers exactly the problem
case and doesn't introduce false negatives in other
scenarios.

But: we should fix sysinstall as well. Either we should
finally rip out DD or we should have it create proper
DD images...

-- 
Marcel Moolenaar
xcllnt at mac.com