Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1484406

Summary: fdisk printing partition table/label even after clearing disk label with wipefs tool
Product: Red Hat Enterprise Linux 7 Reporter: John Pittman <jpittman>
Component: util-linuxAssignee: Karel Zak <kzak>
Status: CLOSED WONTFIX QA Contact: qe-baseos-daemons
Severity: low Docs Contact:
Priority: unspecified    
Version: 7.4CC: ovasik, rskvaril
Target Milestone: rcKeywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-06-08 09:21:27 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1546552    

Description John Pittman 2017-08-23 13:30:45 UTC
Description of problem:

fdisk is printing a partition table with label type dos and System GPT even after clearing the 8 byte GPT label with the wipefs tool.  If I clear the '55 aa', it ceases to report it.  I don't know whether fdisk needs to identify GPT partitions differently or wipefs needs to clear the '55 aa', but we should not be seeing a partition table after wiping the label.  Just looking for clarity, would be glad to change the component if needed.

Version-Release number of selected component (if applicable):

kernel-3.10.0-693.el7.x86_64
util-linux-2.23.2-43.el7.x86_64

How reproducible:

[root@localhost ~]# parted /dev/sdd u s p
Model: QEMU QEMU HARDDISK (scsi)
Disk /dev/sdd: 4194304s
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start  End       Size      File system  Name     Flags
 1      2048s  4192255s  4190208s               primary

[root@localhost ~]# wipefs /dev/sdd
offset               type
----------------------------------------------------------------
0x200                gpt   [partition table]

[root@localhost ~]# wipefs -o 0x200 /dev/sdd
/dev/sdd: 8 bytes were erased at offset 0x00000200 (gpt): 45 46 49 20 50 41 52 54
/dev/sdd: calling ioclt to re-read partition table: Success

[root@localhost ~]# parted /dev/sdd u s p
Error: /dev/sdd: unrecognised disk label
Model: QEMU QEMU HARDDISK (scsi)                                          
Disk /dev/sdd: 4194304s
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags: 

[root@localhost ~]# fdisk -l /dev/sdd

Disk /dev/sdd: 2147 MB, 2147483648 bytes, 4194304 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sdd1               1     4194303     2097151+  ee  GPT

I realize that both tools are likely doing what they are intended to do.  But when a user wipes a label, they are expecting a clear disk.  I'd say the expected results are the printing results we get from parted.  The fdisk tool says that GPT support is in experimental phase.  Perhaps this can be a RFE for not printing the table if the EFI PART label is not there.

Comment 2 Karel Zak 2017-08-24 08:32:20 UTC
It seems fdisk behaviour is correct and expected. 

There are two tables on the device PMBR and PGT. You have removed GPT by wipefs. The valid PMBR is still on the device and fdisk provides opportunity to use it.

Note that "wipefs" from RHEL7 is not smart enough show all magic strings permutations and delete all. Unfortunately, sometimes is necessary to call wipefs more than once if there is more magic strings (more partition tables, backup superblocks, etc.). This disadvantage has been already fixed in Fedore/upstream versions. The change is relatively invasive, so I'm not sure we want to backport it to RHEL7.

And note that "wipe -o" really erases only specified offset and nothing more, for example GPT has another table at the and of the device, etc.

So, it's more wipefs issue than fdisk issue.

Comment 3 John Pittman 2017-08-24 12:24:23 UTC
Thanks for the explanation Karel.  Added "FutureFeature" keyword in the hopes this can be a RFE.  Right now, is what I've done the best option to keep fdisk from printing the table?  Removing the '55 aa' I mean.  Or is there a better way that you know of?

Comment 4 Karel Zak 2017-08-30 08:01:45 UTC
Don't use "-o", but specify wanted type by "-a -t <list>". For example:

# wipefs -a -t gpt,PMBR /dev/sdc
/dev/sdc: 8 bytes were erased at offset 0x00000200 (gpt): 45 46 49 20 50 41 52 54
/dev/sdc: 8 bytes were erased at offset 0x063ffe00 (gpt): 45 46 49 20 50 41 52 54
/dev/sdc: 2 bytes were erased at offset 0x000001fe (PMBR): 55 aa
/dev/sdc: calling ioclt to re-read partition table: Success

works for me. It removes primary, backup gpt headers and PMBR too.

Comment 5 John Pittman 2017-08-30 13:22:20 UTC
Thanks Karel, that works perfectly.  I will update the knowledgebase solution.  I suppose the confusion comes from the 'wipefs /dev/sdc' command.  It only prints out the one offset, so it would seem there is only the one label to remove.  Instead, I would think the command should print all 3 offsets; giving the end user a clearer picture of what is actually on the disk and will need to be removed to completlely wipe.  Since the -a works with no problem, it seems wipefs is already aware of the labels and they can just be added to the print?

Possibly expected output:

[root@host]# wipefs /dev/sdc
offset                   type
-------------------------------------------
0x200                    gpt
0x63ffe00                gpt
0x1fe                    PMBR

Comment 6 Karel Zak 2017-08-31 09:56:11 UTC
It's implemented since v2.31 (not released yet) where it returns all available offsets. It would be possible to backport it to RHEL7, but I'd like to test by Fedora first -- it's not trivial change in important libblkid code.

Maybe RHEL7.6.

Upstream commits:
d2b0c6587d729a8e838821cb70d4de18c6969868
92296e9ba2bf95259520fa7537ff8edc2aa9edbc
193d6f27fb37497669ed429e70b19b11f2b6d4fa
2cd417ea71127e5fbaf43e9c27bd2fa86b3c5100

Comment 8 Karel Zak 2018-06-08 09:21:27 UTC
This feature request has not been requested by any customer and all the necessary changes seem too invasive for RHEL7 update. 

I'm going to close this as WONTFIX and remove dev ACK.

All the functionally will be available for RHEL8.