Bug 795206

Summary: parted should create GPT Linux filesystem partitions with Linux-specific GUID type code
Product: [Fedora] Fedora Reporter: Rod Smith <rodsmith>
Component: partedAssignee: Brian Lane <bcl>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 16CC: bcl, bugzilla, the.ridikulus.rat
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1021263 (view as bug list) Environment:
Last Closed: 2013-02-13 09:00:50 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: 1021263    
Attachments:
Description Flags
Screen shot of Windows, showing how easily it can destroy a Linux installation.
none
This is the patch to fix the problem (against parted 3.0) none

Description Rod Smith 2012-02-20 01:25:56 UTC 
Created attachment 564263 [details]
Screen shot of Windows, showing how easily it can destroy a Linux installation.

Description of problem:

When creating GPT partitions for Linux filesystems, libparted uses the Microsoft Basic Data partition type code GUID (EBD0A0A2-B9E5-4433-87C0-68B6B72699C7). This is fine as far as Linux is concerned, since Linux ignores partition type codes for the most part; but the result is that the Windows file manager shows Linux filesystem partitions as being unformatted but accessible disks. Attempting to access such partitions results in a prompt to format them. (See attached screen shot.) This behavior is potentially dangerous; a simple user error can easily result in trashing the Linux installation.

Note that libparted creates partitions with appropriate Linux-specific type codes when creating swap, LVM, or Linux RAID partitions. It also creates Linux-specific type codes on MBR ("msdos") disks; it's ONLY Linux filesystems on GPT disks that are affected.

I created a patch for this problem almost eight months (see below), but the libparted developers have been slow to add it to libparted. I recommend it be added as a bug fix in Fedora.

This problem is likely to become increasingly important as UEFI-based systems become more common, since UEFI installations of Windows necessarily use GPT rather than MBR, which is more common on BIOS-based computers.

Version-Release number of selected component (if applicable):

3.0 and earlier.

How reproducible:

Always

Steps to Reproduce:
1. Launch parted (or any other libparted-using tool, including anaconda) on a GPT disk.
2. Create a new partition with a Linux filesystem (ext#fs, ReiserFS, XFS, JFS, etc.).
  
Actual results:

The partition uses the Microsoft Basic Data type code.

Expected results:

The partition should use the Linux Filesystem Data type code (EBD0A0A2-B9E5-4433-87C0-68B6B72699C7)

Additional info:

I submitted a patch for this problem to the libparted developers in June of 2011, and they agreed to incorporate it into the mainstream libparted, but have yet to do so. The patch is available on the bug-parted mailing list or at http://www.rodsbooks.com/linux-fs-code/index.html.
Comment 1 Rod Smith 2012-02-21 01:20:19 UTC 
Created attachment 564547 [details]
This is the patch to fix the problem (against parted 3.0)
Comment 2 Chris Murphy 2012-02-29 20:36:21 UTC 
Is this a duplicate of Bug 746895? I think it should be a separate bug for RHEL 6 however, which uses parted 2.1 and has this same problem.
Comment 3 Chris Murphy 2012-02-29 20:41:19 UTC 
Oops, sorry, that's a negative, disregard comment#2. 

This bug is Linux file system having the Windows Basic Data GUID. Bug 746895 is /boot being given the parted 'boot' flag which causes it to have the EFI System GUID.
Comment 4 Chris Murphy 2012-03-13 07:34:36 UTC 
Still a bug in Fedora-17-Nightly-20120307.09-x86_64-Live-kde.iso. Version should be changed from 16 to 17.
Comment 5 Brian Lane 2012-03-13 17:53:05 UTC 
Thanks for the report, but is isn't expected to be any different. I'm not going to change this in parted until upstream adopts it.
Comment 6 Chris Murphy 2012-03-14 02:19:16 UTC 
Arguably they've already adopted it, in that they've agreed there needs to be a unique GUID and the two relevant teams have agreed on what that GUID should be. parted upstream just haven't incorporated the patch.

It's been 9 months since upstream's suggested patch modifications were made, and still no incorporation. In the meantime, partitions are assigned arguably bogus GUIDs, with a known and reproducible user gotcha.

Once upstream applies the patch, is this something that will be back ported to RHEL6's parted 2.1?
Comment 7 Fedora End Of Life 2013-01-16 10:22:18 UTC 
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 8 Fedora End Of Life 2013-02-13 09:00:55 UTC 
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.