From: "Laszlo Ersek" <lersek@redhat.com>
To: "Xu, Wei6" <wei6.xu@intel.com>
Cc: "devel@edk2.groups.io" <devel@edk2.groups.io>,
"Kinney, Michael D" <michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] Question about the Protective MBR in RedHat/Ubuntu
Date: Wed, 24 Apr 2019 20:11:22 +0200 [thread overview]
Message-ID: <5cb3f755-6485-fe4f-26a7-6a60f43dcb4a@redhat.com> (raw)
In-Reply-To: <59B8EAB3797CDB4091332F0685A110ED50D6B722@SHSMSX104.ccr.corp.intel.com>
On 04/24/19 13:36, Xu, Wei6 wrote:
> Hi,
>
> I have a question about protective MBR. Thanks a lot for your time.
> Why is the StartingCHS of protective MBR partition record set to 0x000100 in RedHat / Ubuntu? While UEFI spec defines it as 0x000200.
>
> Problem Statement:
> I met a problem when trying to use FatPei to fetch a file on the GPT partition of RedHat/Ubuntu in TCB.
> FatPei has a check about Partition Record of protective MBR: StartingCHS should to 0x000200.
> But I find the StartingCHS in both RedHat and Ubuntu is 0x000100, so that the check fails.
>
> According to UEFI spec, StartingCHS should be 0x000200.
>
> [cid:image001.png@01D4FACC.71570DF0]
>
Anaconda (the RHEL & Fedora installer) uses GNU Parted for creating GPT
partitions. This utility creates the protective MBR as well.
GNU Parted used to have a bug in setting the sector in "StartingCHS" --
in C/H/S, sectors are 1-based, not 0-based.
The problem was fixed in upstream parted commit df6770d213b6
("libparted: Fix starting CHS in protective MBR", 2016-12-22):
http://git.savannah.gnu.org/cgit/parted.git/commit/?id=df6770d213b6
As far as I can determine, this fix has been included in Fedora 27 and
later. (The oldest supported Fedora release at this point is Fedora 28,
so I think we can consider "Fedora" fixed.) The fix is also included in
RHEL-8.0.
RHEL-7.7 however lacks the fix (as of build "parted-3.1-31.el7"). I've
now filed a Red Hat Bugzilla for you:
https://bugzilla.redhat.com/show_bug.cgi?id=1702778
Please register in the Red Hat Bugzilla instance, subscribe to the bug,
and assist with testing the fix, if the BZ assignee requests that.
Thank you for reporting this issue,
Laszlo
prev parent reply other threads:[~2019-04-24 18:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-24 11:36 [edk2-devel] Question about the Protective MBR in RedHat/Ubuntu wei6.xu
2019-04-24 16:07 ` Andrew Fish
2019-04-25 1:40 ` chao.b.zhang
2019-04-25 1:59 ` Andrew Fish
2019-04-24 18:11 ` Laszlo Ersek [this message]
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-list 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=5cb3f755-6485-fe4f-26a7-6a60f43dcb4a@redhat.com \
--to=devel@edk2.groups.io \
/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