In addition to wipefs [0], could Ironic disk_utils also call `sgdisk -Z` or similar? This issue affects TripleO Ceph deployments as `ceph-disk prepare` is called which in turn calls `sgdisk --mbrtogpt`. While testing a 1020 disk deployment with TripleO, when `sgdisk --mbrtogpt` was called it failed for 143 of the disks but succeeded for the other 877 of the disks; all 1020 of the disks had gone through Ironic cleaning [1]. The 143 disks all had unrecognised disk labels and the issue was worked around by labeling the disks and resuming the deployment to get all 1020 disks activated. I've verified also that `ceph-disk prepare` works with disks which have had `sgdisk -Z` run on them. Using something like `ceph-disk zap` in a preboot script can achieve the same effect, but it seems preferable for TripleO users to just let the Ironic cleaning take care of it. AFAICT, `wipefs --all` removes partitions but not disk labels. Is there any reason why Ironic cleaning should leave pre-existing GPT/MBR (or even EFI) labels on a disk if the user already opted to have the disk cleaned? [0] https://github.com/openstack/ironic-lib/commit/042aa9ab5a27e251c8fb2f1855695cf5e791ecf5 [1] As implemented in https://bugs.launchpad.net/ironic/+bug/1603411
If both, ‘wipefs —all' + 'sgdisk -Z' is the right way to wipe all the partition table and file system metadata for MBR and GPT, then the missing 'sgdisk -Z’ command needs to be added when wiping the disk metadata. If confirmed, I'd suggest to treat this as a regular bug, not a RFE.
Removing RFE from title. Wiping disk the metadata relied on the 'wipefs' command but the goal is to really wipe the disk metadata which includes partitions and disk labels making it a bug rather than a new feature in my view.
patch was merged upstream -> POST https://review.openstack.org/#/c/469155/
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2017:3462