Comment 6 for bug 1303903

Examining the code, there are several sgdisk calls, but two are relevant for this discussion. The first is the one reproduced in this initial bug report:

sgdisk --zap-all --clear --mbrtogpt

This call does not seem to have been changed as a result of bug #1257491. Upon further review, I think I see why it's written this way: When "sgdisk --zap-all --clear" is fed an MBR disk, sgdisk wipes the disk but then refuses to create a blank GPT because it still thinks it's dealing with an MBR disk. This is a bug and I'll fix it soon. Adding --mbrtogpt works around this bug and results in a blank GPT disk.

The call that bug #1257491 resulted in changing was elsewhere in the script, from lines 840 to 856 at http://ceph.com/git/?p=ceph.git;a=blob;f=src/ceph-disk;h=f771a68c2f9d873710cbe380d702fd0baa725da9;hb=HEAD#l840:

sgdisk --new={part} --change-name={num}:ceph journal --partition-guid={num}:{journal_uuid} --typecode={num}:{uuid} journal

It was to THIS call that --mbrtogpt was added, if I've backtracked it correctly. Again, I don't understand the context, but my guess is that sgdisk was being called on an MBR disk. By default, sgdisk will refuse to write data to an MBR disk. This is a safety feature, in case it's called carelessly on an MBR disk that should NOT be converted to GPT form; but of course if a script doesn't know whether the input will be GPT or MBR but the intent of the script is to write out a GPT disk, having sgdisk convert the data structures makes sense, so --mbrtogpt exists.

So in sum, sgdisk does have a bug, but it's not the one assumed. The charm described here was written to work around the bug, and I believe you've misinterpreted the expected output of the relevant sgdisk command.