Bug 138563

Summary: [PATCH] RHEL4 U1: EFI GPT: reduce alternate header probing
Product: Red Hat Enterprise Linux 4 Reporter: Matt Domsch <matt_domsch>
Component: kernelAssignee: Jason Baron <jbaron>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0CC: davej, dledford, knoel, tburke, wwlinuxengineering
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-04-18 13:59:00 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 147461    
Attachments:
Description Flags
efi.patch none

Description Matt Domsch 2004-11-09 22:00:09 UTC
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:

Comment 1 Matt Domsch 2004-11-09 22:01:22 UTC
Created attachment 106378 [details]
efi.patch

patch sent to lkml

Comment 2 Matt Domsch 2004-11-10 17:30:38 UTC
This patch was committed to Linus's BK tree overnight.

Comment 4 Matt Domsch 2004-12-03 03:35:38 UTC
Not fixed in 2.6.9-1.849_EL yet.

Comment 5 Matt Domsch 2004-12-09 21:26:50 UTC
Not fixed in 2.6.9-1.871_EL yet.
As I believe this won't get applied for gold, change $subject to U1.

Comment 7 Amit Bhutani 2005-01-25 20:15:10 UTC
Changing the title to reflect the Update in which a fix for this 
issue has been committed or being tracked for..

Comment 8 Jason Baron 2005-02-10 16:44:48 UTC
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.


Comment 9 Matt Domsch 2005-02-10 17:21:25 UTC
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

Comment 12 Jay Turner 2005-04-16 18:02:30 UTC
Dell, are things better with the U1-candidate kernel?

Comment 13 Matt Domsch 2005-04-18 13:59:00 UTC
Confirmed fixed in 2.6.9-6.37, thanks!

Comment 14 Tim Powers 2005-06-08 15:12:51 UTC
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