Red Hat Bugzilla – Bug 855471
Anaconda does not create a new disklabel
Last modified: 2012-09-10 23:25:34 EDT
Created attachment 610852 [details] storage.log With `clearpart --all --drives=sda --initlabel` in the kickstart script, Anaconda removes existing partitions but does not create a new disklabel. This machine has an existing msdos partition table on sda, so `clearpart --all --drives=sda --initlabel` would be expected to create a new GPT disklabel. I have also tried `clearpart --all --initlabel` to rule out `--drives=sda` as a potential cause. I am attaching storage.log.
Created attachment 610855 [details] storage.log with no existing partition table Hmm. I don't seem to get a new GPT disklabel even if I zero out the existing partition table (see the newly attached storage.log-2). I dug up a mailing list message hinting that the default might be msdos again in Fedora 17 (http://lists.fedoraproject.org/pipermail/test/2012-May/107665.html), but I carefully rechecked the Fedora 17 Release Notes and found no mention of disklabels. So now I'm not sure whether there was an undocumented change or if this bug is somehow hardware-specific. In any case, there doesn't seem to be any way to force the disklabel to be GPT (see bug #647810 and bug #834709) if msdos disk labels are the new default.
Pass gpt on the kernel cmdline to force it to use GPT. Beware that some BIOS's won't boot this, even with the boot flag set on the PMBR. For F18 we are changing the behavior so that if it removes all partitions it will also create a new disklabel.
This stuff should seriously be in the release notes. These are major changes in behavior, and it's extremely frustrating to spend hours tracking down undocumented changes.