Date: Wed, 11 Nov 2009 22:05:30 -0800 From: Marcel Moolenaar <xcllnt@mac.com> To: Julian Elischer <julian@elischer.org> Cc: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= <des@des.no>, current@freebsd.org Subject: Re: How to confuse geom_part_mbr Message-ID: <8DB6C1EB-939D-4128-A15B-A86F4FA63F65@mac.com> In-Reply-To: <4AFB953C.8030607@elischer.org> References: <86tyx0mxjw.fsf@ds4.des.no> <94D5F246-3413-4256-A0FB-6DF2D3BFE9D0@mac.com> <86d43omsb0.fsf@ds4.des.no> <4AFB953C.8030607@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 11, 2009, at 8:55 PM, Julian Elischer wrote: > Dag-Erling Sm=F8rgrav wrote: >> Marcel Moolenaar <xcllnt@mac.com> writes: >>> Dag-Erling Sm=F8rgrav <des@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 >=20 > 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@ 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. --=20 Marcel Moolenaar xcllnt@mac.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8DB6C1EB-939D-4128-A15B-A86F4FA63F65>