Hi bmullan,

Can you be more specific about what the issue is with GParted.  A screen
shot showing "unknown" would be good.

Thanks,
Mike

Created attachment 328721 [details]
png of GParted screen showing /dev/sda when running on Ubuntu 16.04 with zfsonlinux

per request here is screenshot of gparted showing /dev/sda partitions under Ubuntu 16.04 installed on zfsonlinux formated pool of 4 disks.

Note the File System column as described in original bug filing.

GParted is not recognizing the Type codes used by zfsonlinux for the partitions.

@bmullan, would you be able to copy and paste the output of the following command into this report?

  sudo blkid

GParted uses blkid it recognize file zfs file systems and volume names.

$ sudo blkid

/dev/sda1: LABEL="rpool" UUID="11636568831387093787" UUID_SUB="858117753936108373" TYPE="zfs_member" PARTUUID="d7ae827e-4efa-40b3-af7e-ec1b85b6ce30"
/dev/sdb1: LABEL="rpool" UUID="11636568831387093787" UUID_SUB="11968232495702109924" TYPE="zfs_member" PARTUUID="916117c3-d7c4-4500-a0df-8984a394ee4c"
/dev/sdc1: LABEL="rpool" UUID="11636568831387093787" UUID_SUB="8143689488123080441" TYPE="zfs_member" PARTUUID="78e302b1-64c7-4bab-bd05-f4c427796de7"
/dev/sdd1: LABEL="rpool" UUID="11636568831387093787" UUID_SUB="2942019211495454868" TYPE="zfs_member" PARTUUID="af5c274f-e666-44ad-818a-d16e4a9dcced"
/dev/zd0: UUID="ab0bcd04-4e24-48e8-835c-f9a9451552dd" TYPE="swap"
/dev/sda2: PARTUUID="cebeb485-ee88-4126-8ac7-de9709ad5f7f"
/dev/sda9: PARTUUID="54a4418c-5793-457c-9b10-dd084e254aa8"
/dev/sdb2: PARTUUID="5d19fee3-ce9b-4b3c-82f9-81091f1e2016"
/dev/sdb9: PARTUUID="7298310b-fef8-45ff-8875-224f53d0a0cf"
/dev/sdc2: PARTUUID="e907d5fc-657b-4579-b3e0-31e9c1938cf9"
/dev/sdc9: PARTUUID="1137373f-e11b-462f-8cde-b69f92d96bf5"
/dev/sdd2: PARTUUID="12ebee89-47df-4bd8-8c4a-e0b48dc34ad1"
/dev/sdd9: PARTUUID="2bf68366-5fb0-47cf-9fe5-b5bdafad525d"


NOTE: in the orig bug post I gave the TYPE #'s that the specific zfs commands used to create the partitions... if that helps.

Hi bmullan,

From the output it appears that blkid does not recognized the sda2 and sda9 partitions as zfs, hence GParted lists these partitions as unknown.

The sda2 partition is recognized as an EFI boot partition and is listed in GParted as bios_grub.


If I understand correctly, the Type #'s you listed are GUID identifiers used on the partitions in a GUID Partition Table (gpt).  These identifiers do not enforce that the file system within matches the Type identifier.  A similar problem exists with the msdos (aka MBR) partition table and the file systems within the partitions.

As a result many partition tools, including GParted, check the underlying file system within the partition to determine the file system and volume label.

Q1) Out of curiousity, what do you use the sda2 and sda9 partitions for?

    The sda2 (1 MiB) and sda9 (8 MiB) partitions seem extremely small.

Q2) Have you ever formatted the sda2 and sda9 partitions with a file system?

    If not then this would explain why there is no recognized file system within the partition.  Instead the partition would be considered empty.


Curtis

@Curtis,

sda2 usage:

sgdisk partition type EF02 "BIOS boot partition" is GPT partition type
21686148-6449-6E6F-744E-656564454649 [1] and is used by boot loaders,
such as GRUB, to store the stage1.5 boot code [2].  (On MBR disks this
would be stored at sector offset 1, immediately after the MBR itself).

[1] GUID Partition Table, Partition type GUIDs
https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs

[2] BIOS boot partition
    https://en.wikipedia.org/wiki/BIOS_boot_partition
    https://en.wikipedia.org/wiki/BIOS_boot_partition

sda9 usage:

sgdisk partition type BF02 "Solaris reserved 1" is GPT partition type
6A945A3B-1DD2-11B2-99A6-080020736631.  This ZFS related document [1]
suggests it would get contain boot code, possibly /boot file system for
GRUB stage2 code.  If GRUB understands reading files from ZFS and it is
configured that way, sda9 wouldn't be needed.  Might be this case.

[1] ZFS root
    http://slackwiki.com/ZFS_root
"Make a partition for /boot that is about 512MiB of whatever partition
type you like (8300 "Linux filesystem" is fine), or make it type bf07
"Solaris Reserved 1" if you want ZFS to maybe see the disk as if it was
given as a whole disk to ZFS.  Make a second partition using the
remaining space with partition type bf01 "Solaris ZFS".  Currently, when
ZFSonLinux is given a whole disk device like /dev/sdb to use, it will
automatically GPT partition it with a bf01 partition #1 that is the
whole disk except a small 8MiB type bf07 partition #9 at the end of the
disk (/dev/sdb1 and /dev/sb9).  The small 8MiB type bf07 partition #9 is
most likely reserved for use by bootloaders, like lilo, to have a /boot
or other boot-related files kept there. For example, you might have
/dev/sda that is totally non-ZFS for booting and /dev/sdb passed to ZFS
whole where it automatically partitions sdb, but you can just use one
disk here and make partitions."

Thank you Mike for pointing out the use of these two partitions.

If I understand correctly, both of these types of partitions ("BIOS boot partition" and "Solaris Reserved 1") may contain raw boot code, and do not contain a file system.

What do you think of labeling these as file system "raw-code" using a shade of gray in the GUI as opposed to our currently handling of "unknown" file system?

Is there a better way to handle these?

Curtis

Mike... thanks.   

Keep in mind I'm just starting with ZFS having been using BTRFS for the past couple years I thought I'd try it with the new Ubuntu 16.04.   So I'm a long time Ubuntu & BTRFS user but a relative newbie with ZFS.

Here is what I "think" those partitions are:

= = = = = = 

Partition #9 is created and uses the special "bf07" hex type code to indicate that it's "Reserved". (This was copied from what zpool creates when using whole disks.) 
    
Partition #2 is created and uses the special "ef02" hex type code to indicate that it's a GRUB boot partition. 

Note: GRUB only needs enough space to hold the core.img file, which is currently < 1 MB I think.

Finally the rest of the available space on the disk is assigned to partition #1, which is used by ZFS. 

Partition #1 uses the "bf01" hex type code (again copied from ZFS whole disk). As you would expect, partition #1's name is set to "ZFS'.

= = = = = = = 

My guess is that Partition #9 should possibly be labelled "Reserved"
and
Partition #2 should be labelled "GRUB"

As I've got to get a workable system up & running so I can restore my old Home from my BTRFS backup I've got a 2nd reference for installing ZFSonlinux on Ubuntu 16.04 and am going to blow this current one away & reinstall using this 2nd guide.

Note:  this 2nd guide uses the same TYPE numbers as the 1st but adds some extra steps during the partitioning so I'll see if GParted ends up reporting "unknown" again or not and add an additional comment here as to what I find so you guys know too.

@Curtis

Question: How to determine the GPT (and MBR) partition types?

References where both you and I say libparted doesn't currently support
accessing the partition types:

* Bug 337008 - Allow changing of the MBR partition type label (without
               otherwise altering the partition)
  https://bugzilla.gnome.org/show_bug.cgi?id=337008#c3

* Red Hat 1066194 - hex value of partition type is not shown
  https://bugzilla.redhat.com/show_bug.cgi?id=1066194#c12

> Question: How to determine the GPT (and MBR) partition types?

Great question Mike.  Following are my thoughts.

A)  For GPT and the "BIOS boot partition" (sda2) we could use a combination of three pieces of information to determine when a BIOS boot partition is in play.

    1. The partition table is GPT
    2. No file system was detected -- we currently display "unknown"
    3. The bios_grub flag is set.

If all three conditions are met then GParted could indicate this is a BIOS (grub) boot partition.


With regards to MBR and "BIOS boot partition", the core.img portion of the GRUB boot process is stored in unallocated space immediately following the MBR.  In this situation there is no BIOS boot partition, and hence we do not need to concern ourselves with a "BIOS boot partition".


B)  For the "Solaris reserved 1" partition (sda9) I agree there is no easy solution as referenced in the bug reports in comment #10.

One small consolation is that I don't think the "Solaris reserved 1" partition issue will be encountered by the majority of GParted users.


Curtis

Hi Curtis,


I have looked at the libparted source [1].  PED_PARTITION_BIOS_GRUB
"bios_grub" flag is how libparted reports GPT partition type
"BIOS Boot partition" 21686148-6449-6E6F-744E-656564454649.


"Solaris reserved 1" will likely be seen by everyone who uses ZFS.


I am a little uneasy about assuming partition content just based on not
recognising a file system in a BIOS Boot type partition.  Looking at how
GRUB2 creates core.img (stage 1.5), it starts with diskboot.img which I
think is raw 16-bit Intel instructions.  No magic to find.  However if
GParted is run on a non-x86 compatible CPU the start of core.img.  (Not
sure if non-x86 compatible machines have BIOSs and could use GRUB2 to
boot from GPT hard drive).  Such a partition might contains:
1) valid GRUB core.img code;
2) be blank;
3) something else unrecognised.
   (How many file systems does GParted not recognise?
    How many other types of content does (lib)blkid recognise that
    GParted doesn't handle? [2]
    How many other types of file systems can the linux kernel mount?
    [3])

I think that we should also check that the first sector is non-zero and
try asking the GRUB2 developers is there is a way to identify core.img
when written to a raw partition or directly following the partition
table.

Thanks,
Mike


[1] Search for PED_PARTITION_BIOS_GRUB and PARTITION_BIOS_GRUB_GUID in
    libparted/labels/gpt.c
http://git.savannah.gnu.org/cgit/parted.git/tree/libparted/labels/gpt.c?id=v3.2

[2] (lib)blkid recognised signatures
https://git.kernel.org/cgit/utils/util-linux/util-linux.git/tree/libblkid/src/superblocks

[3] Linux supported file systems
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs

Hi Mike,

You are absolutely correct.  The BIOS boot partition determination method I proposed is based on an *assumption*.  Basing partitioning decisions on this assumption could result in unforeseen issues for our users and is a poor design choice.

With that in mind I agree that it is best to only base partition content determination on actual evidence read from within the partition.

If there is a way to identify the GRUB core.img code in the partition, then using such a method would be in alignment with all the other file system determination code in GParted.

If there is not a consistent way to determine the existence of the GRUB core.img code, then this might be an unfixable issue with our use of libparted as it currently exists.

On the topic of BIOS GRUB, I do believe that it is only used on IBM PC Compatible computers with legacy BIOS [1].  This should mean that it is limited to the x86 CPU instruction set, but I do not have definitive proof of this.

[1]:  https://en.wikipedia.org/wiki/BIOS

Curtis

I've ask the grub-help email list if core.img can be recognised:

  Subject: Does core.img have a magic signature?
  http://lists.gnu.org/archive/html/help-grub/2016-06/msg00001.html

@bmullan

Can you run a few commands please.  I want to confirm the contents of
those unknown partitions as I have an idea of how to make GParted
recognise the BIOS boot partition.

Thanks,
Mike

sudo sgdisk -p /dev/sda
sudo dd if=/dev/sda2 bs=512 count=1 | hexdump -C | head
sudo dd if=/dev/sda9 bs=512 count=1 | hexdump -C | head

Created attachment 329101 [details] [review]
Recognise GRUB2 core.img (v1)

Hi Curtis,

Here's a patch to recognise GRUB2 core.img written to a partition.

Testing:
If you use GRUB2 and GPT partitioning core.img may already be written to
a partition.  If not, write /usr/lib/grub/i386-pc/diskboot.img to a
partition.  (GRUB2 uses it as the first 512 bytes of the core.img it
constructs).

I've tested it on Ubuntu 16.04 LTS and Fedora 23.  Resulted it testing
2 of the 4 different possible signatures.

Just need to confirm the colour and text are okay?

Thanks,
Mike

(In reply to Mike Fleetwood from comment #15)
> @bmullan
> 
> Can you run a few commands please.  I want to confirm the contents of
> those unknown partitions as I have an idea of how to make GParted
> recognise the BIOS boot partition.
> 
> Thanks,
> Mike
> 
> sudo sgdisk -p /dev/sda
> sudo dd if=/dev/sda2 bs=512 count=1 | hexdump -C | head
> sudo dd if=/dev/sda9 bs=512 count=1 | hexdump -C | head


Mike...

I decided to build another system using ZFS for Ubuntu 16.04 and here are the outputs of the Commands you asked me to run for you...


$ sudo sgdisk -p /dev/sda

[sudo] password for bmullan: 
Disk /dev/sda: 3907029168 sectors, 1.8 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 9388ADBC-07ED-44A2-A58C-CCA119178C25
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 3907029134
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048      3906994175   1.8 TiB     BF01  ZFS
   2      3906994176      3907012607   9.0 MiB     EF02  GRUB
   9      3907012608      3907029134   8.1 MiB     BF07  Reserved



$ sudo dd if=/dev/sda2 bs=512 count=1 | hexdump -C | head

1+0 records in
1+0 records out
512 bytes copied, 0.0271078 s, 18.9 kB/s
00000000  52 e8 28 01 74 08 56 be  33 81 e8 4c 01 5e bf f4  |R.(.t.V.3..L.^..|
00000010  81 66 8b 2d 83 7d 08 00  0f 84 e9 00 80 7c ff 00  |.f.-.}.......|..|
00000020  74 46 66 8b 1d 66 8b 4d  04 66 31 c0 b0 7f 39 45  |tFf..f.M.f1...9E|
00000030  08 7f 03 8b 45 08 29 45  08 66 01 05 66 83 55 04  |....E.)E.f..f.U.|
00000040  00 c7 04 10 00 89 44 02  66 89 5c 08 66 89 4c 0c  |......D.f.\.f.L.|
00000050  c7 44 06 00 70 50 c7 44  04 00 00 b4 42 cd 13 0f  |.D..pP.D....B...|
00000060  82 bb 00 bb 00 70 eb 68  66 8b 45 04 66 09 c0 0f  |.....p.hf.E.f...|
00000070  85 a3 00 66 8b 05 66 31  d2 66 f7 34 88 54 0a 66  |...f..f1.f.4.T.f|
00000080  31 d2 66 f7 74 04 88 54  0b 89 44 0c 3b 44 08 0f  |1.f.t..T..D.;D..|
00000090  8d 83 00 8b 04 2a 44 0a  39 45 08 7f 03 8b 45 08  |.....*D.9E....E.|



$ sudo dd if=/dev/sda9 bs=512 count=1 | hexdump -C | head

1+0 records in
1+0 records out
512 bytes copied, 0.000441268 s, 1.2 MB/s
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200

Thanks bmullan,

Your data confirms:

* sda2 DOES contain GRUB2 core.img boot code.
  (sgdisk code EF02, GPT partition type
   21686148-6449-6E6F-744E-656564454649 "BIOS boot partition).
  The first 4 bytes of x86 instructions are 1 of the 4 known bytes
  sequences which bootinfoscript [1][2] recognises, and I have added to
  GParted in earlier attached patch "Recognise GRUB2 core.img (v1)".

* sda9 does NOT contain GRUB2 core.img and with the earlier blkid output
  also does NOT contain any recognised data.
  (sgdisk code BF07, GPT partition type
  6A945A3B-1DD2-11B2-99A6-080020736631 "Solaris reserved 1").
  As GRUB2 supports ZFS [3][4] this partition is expected to be empty
  unused.

Mike


[1] bootinfoscript
    https://github.com/arvidjaar/bootinfoscript

[2] bootinfoscript v0.74 line 1963  [GRUB2 core.img possible staring 4 bytes]
https://github.com/arvidjaar/bootinfoscript/blob/b1f711e39d7aa4021f4ad3d31468a8b1e1b3fda7/bootinfoscript#L1963
    
[3] GRUB Manual 2.00  [Search for ZFS]
    https://www.gnu.org/software/grub/manual/grub.html

[4] Ubuntu 16.04 Root on ZFS
    https://github.com/zfsonlinux/zfs/wiki/Ubuntu%2016.04%20Root%20on%20ZFS
    "5.2 Verify that the ZFS [GRUB2] module is installed:

     # ls /boot/grub/*/zfs.mod"

Created attachment 329348 [details]
GParted screen shot of my ZFS /dev/sda (1 disk of 4 disk "pool"

This is a new screen shot of the /dev/sda on my current ZFS Ubuntu 16.04 system that was the source of the "debug" info Mike requested & which I'd uploaded a couple days ago.

Hi Mike,

Thank you for persevering to discover a solution to detect the GRUB2
core.img file.  Thanks also for the tip on testing using the file
/usr/lib/grub/i386-pc/diskboot.img.

I've successfully tested patch v1 from comment #16 on the following
distos:

DISTRO          CORE.IMG LOCATION
=============   ===================================
  debian  8     /usr/lib/grub/i386-pc/diskboot.img
openSUSE 13.2   /usr/lib/grub2/i386-pc/diskboot.img

The dark grey colour and "grub2 core.img" file system name look good to me.

If there are no objections then I will commit this patch to the git
repository tomorrow.

Thanks,
Curtis

Hi Curtis,

(In reply to Curtis Gedak from comment #20)
> Thank you for persevering to discover a solution to detect the GRUB2
> core.img file.

I was keen for GParted to continue to only use signature recognition to
determine partition content, rather than assume content based on
partition types.

From comment 4, bmullan has 4 hard drives all partitioned the same as:
  Ptn Size  Type
  1   1.8T  6A898CC3-1DD2-11B2-99A6-080020736631 "ZFS"
  2   1M    21686148-6449-6E6F-744E-656564454649 "BIOS boot partition"
  9   8M    6A945A3B-1DD2-11B2-99A6-080020736631 "Solaris reserved 1"
From comment 17, is is almost certains that ptn 9 on every drive is
empty and likey that ptn 2 only containg GRUB2 core.img on the first
drive.  I want GParted to correctly report this situation rather than
make assumptions based on partition types.

Thanks,
Mike

Mike/Curtis

Every "guide" I've seen online including those on the zfsonlinux website use that same partitioning.   I hope the following helps you with this.  Partition #9 is marked as RESERVED because the ZFS command ZPOOL utilizes it (see below).

Here's 2 references:

https://github.com/zfsonlinux/zfs/wiki/Ubuntu-16.04-Root-on-ZFS

http://dotfiles.tnetconsulting.net/articles/2016/0327/ubuntu-zfs-native-root.html


NOTE:  

In the 2nd reference above it describes the 3 partitions this way...
The above commands create the following partitions, in the following order:

    Partition #9 is created at the end of the disk and is 8 MB * in size. The partition uses the special "bf07" hex type code to indicate that it's "Reserved". (This was copied from what zpool creates when using whole disks.) Similarly, the partition name is set to "Reserved".

    Partition #2 is created at in the last available 8 MB * of the disk, just before partition #9. Partition #2 uses the special "ef02" hex type code to indicate that it's a GRUB boot partition. Similarly partition #2's name is set to "GRUB".

    Finally the rest of the available space on the disk is assigned to partition #1, which is used by ZFS. Partition #1 uses the "bf01" hex type code (again copied from ZFS whole disk). As you would expect, partition #1's name is set to "ZFS'.



for UEFI booting there may be 1 difference...

    Run this for UEFI booting (for use now or in the future):
    # sgdisk     -n3:1M:+512M -t3:EF00 /dev/disk/by-id/scsi-SATA_disk1

Thank you Mike and bmullan for your work on this report.

Patch v1 from comment #16 has been committed to the git repository master branch for inclusion in the next release of GParted.

The relevant git commit can be viewed at the following link:

Recognise GRUB2 core.img (#766989)
https://git.gnome.org/browse/gparted/commit/?id=8ac3a0e4ad335171cc67c4b8bc37e0d344ccb199

Curtis

Hi Curtis,

Thanks for the feedback.  Agreed, I'll implement option (2): Use class
with major, minor comparison.  I think it's going to take a little
while.


On the needed feature (B) appropriate device name for commands (e.g.
btrfs show) ...

Not yet sure if I want to add this.  The btrfs failure from comment #3
is also a proxy for another subtle issue found on Fedora 23, also
documented in bug 760080 comment 1, in which btrfs show does work with
alternate names.  Btrfs on CentOS 6 is ancient and unsupported.

However from the recent ZFS related partition identification question,
bug 766989, ZFS document recommends using /dev/disk/by-id/ names [1] so
it might become necessary to better support ZFS in the future.

[1] Ubuntu 16.04 Root on ZFS
    zpool create ... /dev/disk/by-id/...
https://github.com/zfsonlinux/zfs/wiki/Ubuntu%2016.04%20Root%20on%20ZFS


Thanks,
Mike

Woops.  Wrong bug report.  Actually for bug 767842.

This enhancement was included in the GParted 0.27.0 release on October 19, 2016.