Description of problem: Date: Tue, 9 Nov 2004 15:59:36 -0600 From: Matt Domsch <Matt_Domsch> To: Linus Torvalds <torvalds>, akpm Cc: davej, "Luck, Tony" <tony.luck>, linux-kernel.org, linux-ia64.org Subject: [PATCH 2.6] EFI GPT: reduce alternate header probing In-Reply-To: <20041109214935.GA617.dell.com> 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> Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 106378 [details] efi.patch 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. Thanks, Matt
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. http://rhn.redhat.com/errata/RHSA-2005-420.html