Red Hat Bugzilla – Bug 795206
parted should create GPT Linux filesystem partitions with Linux-specific GUID type code
Last modified: 2013-10-20 16:40:12 EDT
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.
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.).
The partition uses the Microsoft Basic Data type code.
The partition should use the Linux Filesystem Data type code (EBD0A0A2-B9E5-4433-87C0-68B6B72699C7)
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.
Created attachment 564547 [details]
This is the patch to fix the problem (against parted 3.0)
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.
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.
Still a bug in Fedora-17-Nightly-20120307.09-x86_64-Live-kde.iso. Version should be changed from 16 to 17.
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.
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?
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:
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.