Date: Sun, 07 Mar 2010 11:13:14 -0800 From: Marcel Moolenaar <xcllnt@mac.com> To: Andriy Gapon <avg@icyb.net.ua> Cc: freebsd-geom@freebsd.org Subject: Re: another gpt vs mbr (sanity) check Message-ID: <E336C0C7-C92F-4F30-A091-E3B3517E9B54@mac.com> In-Reply-To: <4B9389C1.9000102@icyb.net.ua> References: <4B9389C1.9000102@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 7, 2010, at 3:10 AM, Andriy Gapon wrote: > > Please consider the following scenario: > - GPT scheme is used on a disk > - the disk changes hands > - the disk is repartitioned with MBR without explicitly wiping out any of old > data and thus GPT > - GPT data survives undamaged > > So now we have the valid GPT but it points to wrong offsets and we have the > valid and correct MBR. > Currently FreeBSD would pick GPT scheme over MBR scheme when presented which > such a disk. I think that this is incorrect. Sorry. That ship has sailed. Originally GEOM_GPT at the time checked for the protective MBR before accepting the GPT. This was changed to support Apple setups. There's no turning back now. People just need to learn to wipe out old partitioning information before writing select sectors in order to create a new one. This, BTW, is exactly why gpart was designed the way it was. It makes sure that you properly clean all the meta-data of the old scheme before new meta-data is written. Legacy tools like fdisk and bsdlabel only write their meta-data without any consideration of the possible existence of meta-data corresponding to other schemes. Now that I think of it, it wouldn't necessarily be a bad feature to extend gpart with a verb, like "wipe", that calls G_PART_DESTROY() for all the schemes it knows about and then erases all the sectors in the sector map, wiping out any and all meta-data that gpart could ever interpret (with the caveat that this is limited to the schemes the kernel knows about at the time). -- Marcel Moolenaar xcllnt@mac.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E336C0C7-C92F-4F30-A091-E3B3517E9B54>