Hi Anatoly,

I assume that TrueOS installed ZFS on the whole disk, and that
installing Archlinux over the top didn't clear the ZFS signatures before
writing the GPT partition table.  Please run the following as root to
confirm:
  blkid /dev/sda
  blkid | fgrep /dev/sda

(From GParted 0.28.0 it uses whole disk file system signatures in
preference to looking at the partition table and FS signatures they
contain.  This was to resolve bug 771244 to ensure iso9660 detection on
whole disks is detected properly).

Thanks,
Mike

Hi Mike,

root@debian:~# blkid /dev/sda
/dev/sda: TYPE="zfs_member" PTUUID="f80e1ce2-028f-4124-bdef-ce5a61ad4e72" PTTYPE="gpt"

root@debian:~# blkid | fgrep /dev/sda
/dev/sda1: UUID="7DB9-26ED" TYPE="vfat" PARTUUID="b751bd6a-2f8c-475c-97d3-021454093f3d"
/dev/sda2: LABEL="Boot" UUID="4e63deab-32a3-45bb-8040-a363578cac23" TYPE="ext4" PARTUUID="f15862bb-22d8-422c-8646-16059c04a698"
/dev/sda3: LABEL="Arch_root" UUID="d74637b0-31c0-4459-b34a-4b16f771f7bb" UUID_SUB="51efbd52-6371-4fe9-957f-eca0bde50f84" TYPE="btrfs" PARTUUID="ed7329a9-30a5-40aa-a2e6-ba468afb1d6d"
/dev/sda4: LABEL="Arch_var" UUID="124d87ea-de95-4efe-8e32-043ce0bc805a" UUID_SUB="e8577f31-383c-4866-87bc-8424229e182b" TYPE="btrfs" PARTUUID="c740998e-2bf1-45e4-95e2-dccec240a36f"
/dev/sda5: UUID="c4bd19ef-ef8c-4f7a-b541-3778c5bf058f" TYPE="swap" PARTUUID="362c3c7b-838c-493a-ada6-764ed538a149"
/dev/sda6: LABEL="Arch_home" UUID="b3edd0bf-8847-4e6c-9786-ca1c1f295198" UUID_SUB="e97963d7-fe27-48b2-8435-48c65aa2ab3e" TYPE="btrfs" PARTUUID="2dbb4824-6a82-4db5-9a37-9fc2e4b5a363"
/dev/sda7: LABEL="Data" UUID="f22fb899-7528-4e4d-89b8-19e2e9d25482" UUID_SUB="8427a6f0-e3af-486f-8867-5c1e2fdc71d0" TYPE="btrfs" PARTUUID="af781347-5698-4b58-88e9-2b89990ddfa2"
/dev/sda8: UUID="6027-C280" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="0db0ae6b-fdf3-484a-95f4-ee646f1cef4b"
/dev/sda10: UUID="BAB42EECB42EAB39" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="797d5265-c376-431a-be06-4fba1e50ef28"
/dev/sda11: UUID="3ce945e5-aa23-4602-9019-5587ca76ab5e" TYPE="ext4" PARTUUID="e40b396b-5ac4-4e30-8682-2d5b8da0402e"
/dev/sda9: PARTLABEL="Microsoft reserved partition" PARTUUID="df7a9b92-c57a-48d3-8643-d7334758652c"
root@debian:~#

Hi Anatoly,

> /dev/sda: TYPE="zfs_member"
This confirms blkid finds ZFS file system signatures on the whole disk
and this is why GParted is reporting this too.


To resolve this you will need to manually erase all the ZFS signatures.
1) Use wipefs to report the signatures.
      wipefs /dev/sda
2) Erase the ZFS signature.
      wipefs -b -o $offset /dev/sda
   Replace $offset with hex value from offset reported in step (1).
   -b is creating a backup of the erased signature bytes in
   $HOME/wipefs-sda-$offset.bak.
3) Repeat from (1) until there are no more ZFS signatures.  (ZFS has
   *many* copies of it's signature).


Below is the start of me doing a worked example.  For my test I had 21
ZFS signatures to erase which hadn't been overwritten by other data.

Mike
--


# wipefs /dev/sda
offset               type
----------------------------------------------------------------
0x200                gpt   [partition table]

0x24000              zfs_member   [filesystem]

# wipefs -b -o 0x24000 /dev/sda
/dev/sdc: 8 bytes were erased at offset 0x00024000 (zfs_member): 0c b1 ba 00 00 00 00 00

# wipefs /dev/sda
offset               type
----------------------------------------------------------------
0x200                gpt   [partition table]

0x23800              zfs_member   [filesystem]

# wipefs -b -o 0x23800 /dev/sda
/dev/sdc: 8 bytes were erased at offset 0x00023800 (zfs_member): 0c b1 ba 00 00 00 00 00

Hi Mike,

Thank you for advice and the manual, but it is still a bug of Gparted to not see a working partition table. Archlinux and Ubuntu work well on this disk.

And is it impossible to make Gparted automatically erase these signatures?

As I understand, there is also a bug on the Parted side, which didn't erase old signatures before creating new partition table.

Without knowing the exact reason why a disk device is configured or appears to be configured a certain way, I do not think it is wise to automatically erase signatures.  Doing so might result in loss of data.


There was a report in Debian which *might* be the root cause of this issue.

blkid reports whole disk as zfs pool when any partition is ZFS
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888114

More specifically the report seems to indicate that blkid is wrongly detecting the whole disk device as ZFS if at least one partition is formatted as ZFS.


Anatoly,

You might try raising this issue directly with the team that supports blkid.  The blkid command used to be part of e2fsprogs, but more recently I think it is util-linux.

util-linux
https://en.wikipedia.org/wiki/Util-linux


Curtis

Hi, Curtis

I looked at the report you mentioned.
I understand now, that Gparted relies on blkid to get information about disk layout and that blkid sometimes sees a ZFS pool where it doesn't exist. 

But in my case, blkid reported not only ZFS signature on the disk but also a GPT table. 
Why did Gparted choose the first variant and did not leave the choice to the user?
In my opinion, in case of contradictory data on the disk Gparted must ask the user which variant he considers the right one, then ask him if he wishes to erase all unwanted data, and if so, call wipefs and do the cleaning job on the user's behalf.


This is what wipefs shows on my disk:

root@debian:~# wipefs /dev/sda
offset               type
----------------------------------------------------------------
0x200                gpt   [partition table]

0x7f000              zfs_member   [filesystem]

There is indeed a ZFS signature. Parted did not remove it when creating GPT table.

The fact that Parted and Fdisk unanimously report GPT table, tells that they see no contradictory entries on the disk. Either they don't see the ZFS signature at all, or unconditionally give precedence to GPT table.

From the point of view of an ordinary user, if three operating systems (Archlinux, Ubuntu, Windows) successfully work and two partitioning programs (fdisk, parted) see the partitions, then this scheme is right, and there is something wrong with Gparted if it does not see any partitions at all.

Hi Anatoly,


When any whole disk or individual partition contains 2 or more
signatures for different file systems, raid arrays or partition tables
which is the correct signature to use?  Which was written last?  There
is no way to tell programmatically, hence why it is very important for
formatting and partition tools to ensure that all previous signatures
are erased before they write their new format.

GParted handles both whole disk file systems and partitioned devices.
It checks for whole disk file systems before looking for partition
tables to:

1) Avoid an old bug in libparted where it mis-recognised a whole disk
   FAT file system as an MSDOS partition table.  The bug is since fixed
   in libparted but still exists in older supported distributions.

https://git.gnome.org/browse/gparted/commit/?id=f8faee637787329c07771e495c9b26abc9ac1603
Avoid whole disk FAT being detected as MSDOS partition table (#743181)

2) Avoid ISO9660 images written to a whole disk device being detected as
   MAC partition table by the latest libparted.  The linux kernel even
   recognises the partitions in this.  (I wonder if the embedded
   partitioning is to do with making ISO images bootable on Apple
   hardware and/or EFI machines).

Bug 771244 - gparted does not recognize the iso9660 file system in
             cloned Ubuntu USB boot drives

https://git.gnome.org/browse/gparted/commit/?id=683dc9d1abd6a388e6f1eda7c7ba8465eb970756
Only read partition table after not finding a whole disk file system (#771244)

I don't see how we can change the order of detection in GParted.  As to
reporting the issue to the user and getting them to choose which
signatures to keep, that is a non-trivial change.  Patches for review
welcome.


I assume that partitioning tools like fdisk doesn't even consider whole
disk device file systems so would just ignore any other signatures and
only ever report the partition table.


The primary cause of this issue is various tools not properly clearing
signatures before writing their own formatting, be it a partition table,
raid array or file system.  Or documentation not informing users that
they need to do this themselves.

Because of this GParted is coded to obliterate all known signatures when
either formatting a partition, a whole disk device or writing a new
partition table.


Mike

Hi Mike,

I agree that in case of contradictory signatures we can't tell for sure which are correct. But we can detect discrepancies and surmise possible correct layouts. For example in my case, 

root@debian:~# blkid /dev/sda
/dev/sda: TYPE="zfs_member" PTUUID="f80e1ce2-028f-4124-bdef-ce5a61ad4e72" PTTYPE="gpt"

TYPE says there is a whole disk filesystem, while PTTYPE says there is a partition table. Now when we search for partitions, we see that there are no partitions of type "zfs_member", while if the whole disk was a zfs pool, there might not be partitions other than of type "zfs_member". So we may surmise two possible mutually exclusive variants: whole disk zfs pool and gpt table with partitions.
It is better to warn the user about this ambiguity and ask him if he sees the right variant among the two. If he's confirmed that one of them is right, then we must erase all traces of the other.

And yes, we first check for whole disk file system, then look for a partition
table.

I'm not a programmer, I can't propose patches. But I've sketched the algorithm in Python (it's just a sketch, not a working script). I'll upload it as an attachment.

Created attachment 369473 [details]
Sketch of algorithm for detecting discrepancies in disk partitioning signatures

An algorithm for detecting discrepancies in disk partitioning signatures. To make Gparted more robust when dealing with incorrectly partitioned disks. Just a sketch in Python.

Hi Anatoly,

As you pointed out in the output in comment #8 we can see there is an issue with the blkid command.

In my opinion the correct place to resolve this issue is upstream in the blkid code.

It would help us if you could raise the issue upstream with the team that manages blkid (now contained in the utils-linux package if I recall correctly).

Please also post a link the the upstream report in this bug report.

Thanks,
Curtis

Hi Curtis,
Hi Mike,

I reported the bug to kernel.org: https://bugzilla.kernel.org/show_bug.cgi?id=199079

I also sent a bug report to bug-parted@gnu.org about parted not properly erasing old signatures when creating a new partition table.

bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time.

If you still use gparted and if you still see this bug / want this feature in a recent and currently supported version, then please feel free to report it at
https://gitlab.gnome.org/GNOME/gparted/-/issues/
by following the guidelines at
https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines

Thank you for creating this report and we are sorry it could not be implemented so far (volunteer workforce and time is limited).