public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Matt Porter <matt.porter@linaro.org>
To: Davidlohr Bueso <davidlohr@hp.com>
Cc: Karel Zak <kzak@redhat.com>,
	Matt Fleming <matt.fleming@intel.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	torvalds@linux-foundation.org
Subject: Re: GPT detection regression in efi.c from commit 27a7c64
Date: Fri, 13 Sep 2013 13:01:58 -0400	[thread overview]
Message-ID: <52334506.9030802@linaro.org> (raw)
In-Reply-To: <1379089736.2197.14.camel@buesod1.americas.hpqcorp.net>

On 09/13/2013 12:28 PM, Davidlohr Bueso wrote:
> Cc'ing Linus.
>
> On Fri, 2013-09-13 at 10:50 -0400, Matt Porter wrote:
>> The commit, "27a7c64 partitions/efi: account for pmbr size in lba", that
>> was just merged in 3.12-rc caused a regression on my system with a GPT
>> formatted eMMC device. In 3.11, the GPT partition table was detected
>> fine but now a partition table is not detected.
>>
>> Not being a GPT expert, I did some research and found that the tool used
>> to create the PMBR on my system shares characteristics with what is
>> mentioned in an explanation of Microsoft created PMBRs [1]. In short,
>> the size_in_lba field incorrectly has 0xffffffff even though I have a
>> <2TiB drive (16GiB eMMC).
>
> *sigh*. So Microsoft decided to do its own version of the GPT specs.

Don't sound so surprised. :)

> Up until now, Linux was incorrectly enforcing pMBR checks: not
> recognizing valid labels and vice versa, as with the case you are
> mentioning now. The changes that went in the 3.12 merge window attempt
> to address those concerns, enforcing the correct checks - which is also
> how Linux partitioning tools do it (fdisk, parted).

Understood, and we are fixing our own manufacturing tool that was used 
to prepopulate the eMMC. I definitely prefer to have this correct for my 
case.

>> I get that this is not compliant with UEFI. I bring this up because
>> before this commit the is_pmbr_valid() check was less pedantic. In 3.11
>> a PMBR formatted this way did not fail the check. For my particular
>> case, I simply dded out LBA 1 and whacked the SizeInLBA field to comply
>> with the spec and this patch and I'm back in business. We're updating
>> the tools that we inherited to prepopulate our boards with a GPT to be
>> compliant. However, I wondered if this would be a problem for all the
>> people with Windows-generated GPTs as noted in [1].
>
> I guess this comes down to choosing whether or not we want Linux to be
> more UEFI compliant or not. Should we care if Microsoft decides to go do
> things out of the official spec? I don't know the policy here. The fact
> is that *they* should update their partitioning tools and create valid
> pMBRs. Any way, I'm ok with reverting this commit if deemed necessary.

I can't say first-hand that Windows 7/8 does what is claimed in this 
description as I simply don't have access to any Windows machines here. 
If it's true, I would have to agree with Linus that meeting reality if 
more important than meeting the spec.

Hopefully somebody can confirm that Windows does indeed produce these 
special PMBRs that need to be handled as an exception to the spec.

-Matt


  reply	other threads:[~2013-09-13 17:02 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-13 14:50 GPT detection regression in efi.c from commit 27a7c64 Matt Porter
2013-09-13 16:28 ` Davidlohr Bueso
2013-09-13 17:01   ` Matt Porter [this message]
2013-09-13 17:37     ` Davidlohr Bueso
2013-09-13 18:17       ` Matt Porter
2013-09-13 18:07     ` Davidlohr Bueso
2013-09-13 18:09       ` Matt Porter
2013-09-13 18:17         ` Karel Zak
2013-09-13 18:29           ` Davidlohr Bueso
2013-09-13 18:33             ` Matt Porter
2013-09-13 19:26               ` Davidlohr Bueso
2013-09-13 21:36                 ` Matt Porter
2013-09-13 22:02                   ` Davidlohr Bueso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52334506.9030802@linaro.org \
    --to=matt.porter@linaro.org \
    --cc=davidlohr@hp.com \
    --cc=kzak@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt.fleming@intel.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox