[parted-devel] [PATCH 01/14] Preserve first 446 bytes of the pmbr in gpt.

Joel Granados jgranado at redhat.com
Tue Jun 9 08:09:29 UTC 2009


On Fri, Jun 05, 2009 at 03:25:29PM +0200, Jim Meyering wrote:
> Joel Granados Moreno wrote:
> > * libparted/label/gpt.c (_write_pmbr) : Make sure we read the first 446
> >   bytes of the device when we are creating the pmbr.
> > ---
> >  libparted/labels/gpt.c |   13 ++++++++++++-
> >  1 files changed, 12 insertions(+), 1 deletions(-)
> >
> > diff --git a/libparted/labels/gpt.c b/libparted/labels/gpt.c
> > index 765c8a5..89e46fc 100644
> > --- a/libparted/labels/gpt.c
> > +++ b/libparted/labels/gpt.c
> > @@ -958,7 +958,18 @@ _write_pmbr (PedDevice * dev)
> >  {
> >  	LegacyMBR_t pmbr;
> >
> > -	memset(&pmbr, 0, sizeof(pmbr));
> > +	/* The UEFI spec is not clear about what to do with the following
> > +	 * elements of the Protective MBR (pmbr): BootCode (0-440B),
> > +	 * UniqueMBRSignature (440B-444B) and Unknown (444B-446B).
> > +	 * With this in mind, we try not to modify these elements.
> > +	 */
> > +	if(ped_device_read(dev, &pmbr, 0, GPT_PMBR_SECTORS) < GPT_PMBR_SECTORS)
> > +		memset(&pmbr, 0, sizeof(pmbr));
> > +
> > +	/* Make sure we zero out all the legacy partitions.
> > +	 * There are 4 PartitionRecords.  */
> > +	memset(&(pmbr.PartitionRecord), 0, sizeof(PartitionRecord_t) * 4);
> 
> In isolation, I'd say this looks fine.
> I really appreciate the accompanying test.
> 
> However, this change conflicts directly with bug-fix changes on "next"
> that allow GPT support to work with >512-byte sectors.  In that case,
> a larger sector cannot be read into a fixed-size "pmbr" buffer.
> 
> What do you think about applying it only to next?

This is ok with me.  I'll work on the patch for the next branch and post
it.

> The alternative is to apply it here, rebase and
> adjust "next" accordingly.

Yet another reason to get 1.9.0 out the door and start the next merge.
IMO, the more we wait for that merge, the more painful it is going to
be.

> 
> If there are too many changes like this,
> we may have to start working on "next" in earnest.

Which, after 1.9.0, is not a bad idea.

-- 
Joel Andres Granados
Brno, Czech Republic, Red Hat.



More information about the parted-devel mailing list