On Fri, Mar 20, 2015 at 1:02 PM, Roderick Smith <rod.sm...@canonical.com> wrote:
> 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. > OK. There wasn't much context in the changelog to charm-helpers for that change, but I'm assuming one of the ceph tools didn't like getting a non-blank GPT disk and appending mbrtogpt resolved that. But that left the case where a GPT disk was fed to lvm2 pvcreate which will refuse to work with a disk that has any partition table (MBR or GPT) Which led to filing this bug. > > 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. > Indeed. In our use-case the physical disks on the machine get reused for different purposes from run to run, so we definitely encountered the case where sgdisk performed as requested, but ultimately we needed something to handle clearing the entire disk regardless of initial state and leaving nothing behind (no MBR, no GPT). Is there such a call to sgdisk to do so? > > 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. > OK. The end goal was to have a call to sgdisk (or something else) that would ensure that the disk looked blank/unused such that the different tools used to initialize the disk all worked correctly. If there is a correct call to sgdisk to handle both MBR and GPT disks and to cleaning wipe the drive then we can mark this bug as invalid (I'll leave you to open the other bug you mentioned) Ryan -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to gdisk in Ubuntu. https://bugs.launchpad.net/bugs/1303903 Title: sgdisk zap/clear doesn't wipe all GPT tables To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdisk/+bug/1303903/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
