Bug 855471 - Anaconda does not create a new disklabel
Anaconda does not create a new disklabel
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-07 18:37 EDT by Andrew McNabb
Modified: 2012-09-10 23:25 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-09-10 20:02:10 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
storage.log (137.85 KB, text/x-log)
2012-09-07 18:37 EDT, Andrew McNabb
no flags Details
storage.log with no existing partition table (78.81 KB, text/plain)
2012-09-07 19:01 EDT, Andrew McNabb
no flags Details

  None (edit)
Description Andrew McNabb 2012-09-07 18:37:49 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.
Comment 1 Andrew McNabb 2012-09-07 19:01:43 EDT
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.
Comment 2 Brian Lane 2012-09-10 20:02:10 EDT
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.
Comment 3 Andrew McNabb 2012-09-10 23:25:34 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.