Red Hat Bugzilla – Bug 747497
parted gpt partition_duplicate does not copy flags
Last modified: 2011-10-31 19:45:07 EDT
Description of problem:
Install DVD's anaconda, when creating or modifying a GPT disk, causes parted to set the 'legacy_boot' attribute on the EFI System partition.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Any installation type that causes parted modify a GPT disk with an existing EFI System partition; or when creating a new EFI System partition on EFI computers.
1. Apple computer with pre-existing EFI System partition and free space to install Fedora.
2. Install using either "Use Free Space" or "Custom" installation types, that cause modification to the GPT.
The EFI System partition is flagged with the 'legacy_boot' parted flag.
The 'legacy_boot' attribute doesn't apply to EFI System partitions.
Regression using Fedora-16-Beta-x86_64-Live-Desktop.iso 28-Sep-2011. The described actual results do not occur. Neither 'hidden' nor 'legacy_boot' attributes are set on the EFI System partition.
anaconda does not set the legacy_boot flag.
The only place in fedora that I know of that uses legacy_boot is in recent versions of livecd-iso-to-disk when making usb sticks with gptmbr.
Preinstall a pre-existing 'EFI System' partition does not have parted 'legacy_boot' flag enabled.
Post install with Install DVD only (not Live CD) using CSM boot, that same EFI System partition does have parted 'legacy_boot' enabled.
dlehman is reporting that he is seeing this on seemingly random partitions. May be a parted problem.
1. 2 disk KVM setup.
2. Install using autopart and non-lvm
3. reboot and install again with custom, adding a /home to the disk with just swap on it.
hidden and legacy_boot flags are now on when you view them using parted -s /dev/sda p
Reproduced with the pre-TC3 spin for new glibc.
It sometimes comes up with only hidden set, so it isn't 100% consistent in the results.
The core problem here is that the partition_duplicate function in libparted/labels/gpt.c does not copy any of the flags when duplicating the partiton.
So the impact assessment here is as follows:
The flags of partitions on install target disks that are not being re-formatted as part of the installation could be set to just about anything.
Example - you install into free space on a disk which already has another OS or Linux distribution installed: the flags for the partitions belonging to the other OS could be messed up.
Also if you, say, re-use without re-formatting an existing /home or /boot partition its flags could be messed up. Can also affect the EFI system partition, which is a one-per-disk kind of thing.
Given that this could have unpredictable negative effects on pre-existing user data, I'm definitely +1 blocker: best criterion is probably "All known bugs that can cause corruption of user data must be fixed or documented at Common F16 bugs", but you could wiggle it into various others too. Adding CCs for blocker votes.
Fedora Bugzappers volunteer triage team
also +1 blocker
parted-3.0-4.fc16 has been submitted as an update for Fedora 16.
Three +1 blocker votes, AcceptedBlocker.
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing parted-3.0-4.fc16'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
parted-3.0-4.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.