[Bug 1303903] Re: sgdisk zap/clear doesn't wipe all GPT tables
** Also affects: charm-helpers (Ubuntu) Importance: Undecided Status: New ** Changed in: gdisk (Ubuntu) Status: Confirmed => Invalid -- 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/charm-helpers/+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
[Bug 1303903] Re: sgdisk zap/clear doesn't wipe all GPT tables
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.
--
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
Re: [Bug 1303903] Re: sgdisk zap/clear doesn't wipe all GPT tables
On Wed, Mar 18, 2015 at 12:59 PM, Roderick Smith rod.sm...@canonical.com wrote: This is not a bug in sgdisk; it's either a bug in the charm or an incorrect use of same. Specifically, the sgdisk command shown is: sgdisk --zap-all --clear --mbrtogpt /dev/vdb This command does four things, in sequence: - It zaps all GPT and MBR data structures (--zap-all). - It creates an empty GPT data structure (--clear). - It OKs the conversion of any MBR data structure to GPT form (--mbrtogpt). - It writes the resulting changes to disk. (This is implicit in most uses of sgdisk.) The first and second of those options are both used to wipe data, but in different ways -- --zap-all zeroes out all the sectors of the disk used by the GPT data structures, whereas --clear erases the partitions but leaves the data structures intact. Using --clear after --zap-all should therefore have the same effect as using --clear alone. (There may be cases where --zap-all would be necessary if you're dealing with a damaged disk, but I'd need to study this some more to be sure.) In any event, the end result of those two commands is a GPT disk with no partitions defined, not a disk without a partition table. The --mbrtogpt option is useless in this context. It should be used when you want to convert an MBR disk to GPT form, but as the preceding options set the disk up as GPT, --mbrtogpt does nothing. If the goal is to completely erase all partition data, including the partition table itself, the following command should be used: sgdisk --zap-all /dev/vdb Thanks for the clarification. Looking into the charm-helpers history it appears there was some creep in use of the command. Originally it was as above, --zap-all DEVICE, This bug was encountered: https://bugs.launchpad.net/ubuntu-advantage/+bug/1257491 Which then introduced the use of --mbrtogpt Further errors were encountered and --clear was added, which resulted in re-writing of an empty, but clear partition. Knowing now that it writes out an empty, but present GPT table then issues manifested itself in a separate case; when this disk was re-used to create an LVM, the empty but present GPT table prevented LVM from using the device. Backing up then, the question is why doesn't --zap-all work for bug 1257491? If that can be resolved then we can remove the mbrtogpt and clear altogether and ensure that nothing is present on the disk so it can be used for ceph or lvm block services. 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
Re: [Bug 1303903] Re: sgdisk zap/clear doesn't wipe all GPT tables
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
[Bug 1303903] Re: sgdisk zap/clear doesn't wipe all GPT tables
This is not a bug in sgdisk; it's either a bug in the charm or an incorrect use of same. Specifically, the sgdisk command shown is: sgdisk --zap-all --clear --mbrtogpt /dev/vdb This command does four things, in sequence: - It zaps all GPT and MBR data structures (--zap-all). - It creates an empty GPT data structure (--clear). - It OKs the conversion of any MBR data structure to GPT form (--mbrtogpt). - It writes the resulting changes to disk. (This is implicit in most uses of sgdisk.) The first and second of those options are both used to wipe data, but in different ways -- --zap-all zeroes out all the sectors of the disk used by the GPT data structures, whereas --clear erases the partitions but leaves the data structures intact. Using --clear after --zap-all should therefore have the same effect as using --clear alone. (There may be cases where --zap-all would be necessary if you're dealing with a damaged disk, but I'd need to study this some more to be sure.) In any event, the end result of those two commands is a GPT disk with no partitions defined, not a disk without a partition table. The --mbrtogpt option is useless in this context. It should be used when you want to convert an MBR disk to GPT form, but as the preceding options set the disk up as GPT, --mbrtogpt does nothing. If the goal is to completely erase all partition data, including the partition table itself, the following command should be used: sgdisk --zap-all /dev/vdb Adding --clear and --mbrtogpt will be useless at best, and as you've discovered, --clear adds an (empty) partition table back. Note also that parted does *NOT* show that the disk is all clear, as described in the bug report: # parted shows that it's call clear % parted /dev/vdb print Model: Virtio Block Device (virtblk) Disk /dev/vdb: 21.5GB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags Note the line that reads Partition Table: gpt, which indicates that a valid GPT is present on the disk. No partitions are listed because that was the effect of the --clear option to sgdisk. Naturally, fdisk also notes the GPT data structures in the protective MBR. -- 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
[Bug 1303903] Re: sgdisk zap/clear doesn't wipe all GPT tables
** Tags added: cloud-installer -- 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
[Bug 1303903] Re: sgdisk zap/clear doesn't wipe all GPT tables
Related to: http://tracker.ceph.com/issues/3344 -- 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
[Bug 1303903] Re: sgdisk zap/clear doesn't wipe all GPT tables
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: gdisk (Ubuntu) Status: New = Confirmed -- 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
[Bug 1303903] Re: sgdisk zap/clear doesn't wipe all GPT tables
** Tags added: landscape -- 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
