Comment 4 for bug 1737556

Some feedback from the sgdisk author on this scenario is below. Would the Ironic team be interested in simply changing Ironic's behavior based on the return code of the sgdisk -Z?

---------- Forwarded message ---------
From: Rod Smith
Date: Tue, Aug 7, 2018 at 9:38 AM
Subject: Re: Should sgdisk -Z return an error code if the CRC check doesn't pass?
To: John Fulton

On 08/06/2018 09:33 PM, John Fulton wrote:
> Rod,
>
> First of all thank you for sgdisk; it's a great tool. I ran into an
> issue with it and I am curious if you consider it a bug.
>
> I ran `sgdisk -Z /path/to/dev` and though I received a message that
> the GPT data structures were destroyed, there was a warning that the
> CRCs don't match and the command returned an error code as per echo
> $?.
>
> I would think that if I used -Z that it shouldn't bother with a CRC
> check because it's deleting the GPT data structures anyway but I might
> be mistaken. I'm able to work around it by using gdisk with option 2
> to create a blank GPT, but the sgdisk use in this case is part of a
> larger automation project and the error code causes a failure in the
> larger system [1]. I looked for an option to sgdisk to have it ignore
> the CRC check but couldn't find one.
>
> If you think this is a bug I would be happy to file it. I looked for a
> bug tracker but couldn't find one on the project's sourceforge page.

The design of GPT fdisk is such that it ALWAYS tries to read partition
data structures from the disk; the code to read the command line
arguments comes AFTER the program tries to parse the partition table
data. Changing this is not simply a matter of moving a block of code,
either; it's fundamental to the design of the C++ class structures used
by the program.

As to the return code, that could more easily be changed; however, I'm
reluctant to do so because sgdisk is used by a large number of scripts,
some of which may rely on the current behavior. Thus, although changing
sgdisk to not return an error code when you wipe a damaged disk with
"-Z" makes conceptual sense, that change could cause problems for others.

In practice, these issues are both easily overcome -- if you expect your
script will be calling sgdisk on a disk that has no valid partition
table, you can redirect the output to /dev/null and ignore the return code.