Red Hat Bugzilla – Bug 138563
[PATCH] RHEL4 U1: EFI GPT: reduce alternate header probing
Last modified: 2013-03-06 00:57:59 EST
Description of problem:
Date: Tue, 9 Nov 2004 15:59:36 -0600
From: Matt Domsch <Matt_Domsch@dell.com>
To: Linus Torvalds <firstname.lastname@example.org>, email@example.com
Cc: firstname.lastname@example.org, "Luck, Tony" <email@example.com>,
Subject: [PATCH 2.6] EFI GPT: reduce alternate header probing
EFI partitioning scheme was reading the last reported sector of the
block device to look for the alternate GPT header, before it had
confirmed that it should. This causes problems for devices with the
following problems: a) those who misreport their size (typically
off-by-one), and b) those who fail when asked to read a block
outside their range.
This patch moves the test for the Protective Master Boot Record (PMBR)
ahead of the tests for the Primary and Alternate GPT headers. If the
PMBR is not valid, the disk is assumed to not be a GPT disk. This can
be overridden with the 'gpt' kernel command line option. If the
Primary GPT header is not valid, the Alternate GPT header is not
probed automatically unless the 'gpt' kernel command line option is
passed. If the both the PMBR and Primary GPT header are valid, then
the Alternate GPT header at the end of the disk is probed.
Also re-enables CONFIG_EFI_PARTITION for all architectures.
Signed-off-by: Matt Domsch <Matt_Domsch@dell.com>
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Created attachment 106378 [details]
patch sent to lkml
This patch was committed to Linus's BK tree overnight.
Not fixed in 2.6.9-1.849_EL yet.
Not fixed in 2.6.9-1.871_EL yet.
As I believe this won't get applied for gold, change $subject to U1.
Changing the title to reflect the Update in which a fix for this
issue has been committed or being tracked for..
I don't see this work in upstream 2.4. Is it not needed there for some reason?
or just not merged? The basic question is whether we should merge this back to
rhel2.1 and rhel3. thanks.
I never submitted it to upstream 2.4, you're correct. Essentially because
CONFIG_EFI_PARTITION is not enabled on any architecture except IA64, and given
the scarcity of IA64 hardware, it's unlikely that people will plug broken
iPods (or other similarly broken yet not-on-the-quirks-list storage) devices
into such systems.
If you're adding the iPods to the USB "unusual_devs.h" list, then I don't need
to fix the partition code. If you're not, and we care about people plugging
broken iPods into IA64 systems, then yes, I should fix it. I'm inclined
against it though.
The fix *does* need to make it into RHEL4 though.
Dell, are things better with the U1-candidate kernel?
Confirmed fixed in 2.6.9-6.37, thanks!
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.