Re: How to confuse geom_part_mbr

On Nov 11, 2009, at 8:55 PM, Julian Elischer wrote:

> Dag-Erling Smørgrav wrote:
>> Marcel Moolenaar <xcllnt_at_mac.com> writes:
>>> Dag-Erling Smørgrav <des_at_des.no> writes:
>>>> The machine won't boot, even though you have a valid partition table
>>>> on ad0 that points to a valid bsdlabel in ad0s1.
>>> No, you don't have a valid partition table on ad0, because
>>> you didn't remove the BSD disklabel in sector 2 on ad0.
>> Yes, I do have a valid partition table.  It is exactly byte-by-byte
>> identical to the one I get after I zero sector two and re-run fdisk.
>> The fact that there is unwanted data in sector 2 does *not* make it any
>> less valid.
>> What's more, this could have easily been avoided if geom_whatever gave
>> the partition table precedence over the label it found in sector 2.
>> DES
> 
> The dummy MBR on a disklabel can be relatively easily identified, and the regular MDR tasting code should note it and give it a lower priority than a real MBR. (and a disklabel)

Fuzzy logic. How do you distinguish an empty MBR from
a dummy one?

The exists of the BSD disklabel in sector 2 is obviously
and non-fuzzily a much better identifier.

The problem with tools like fdisk and disklabel is that
they work well to create metadata, but they don't deal
with the removal of metadata. Combine that with the
ignorance of one tool towards the other and you get
what des_at_ points out: stale data that cause problems.

Note also that there is no ordering or priority mechanism
between the old GEOM_MBR and GEOM_BSD. It just so happens
that GEOM_MBR tastes first. But this is not at all a given.
In fact, if you remove GEOM_MBR from your kernel config
you'll see that GEOM_BSD attaches.

The bottomline: gpart implements the correct algorithm
because it's the only one that stable and reliable.

-- 
Marcel Moolenaar
xcllnt_at_mac.com