Project

General

Profile

Bug #934

FreeBSD's GPT not recognized

Added by Edho Arief about 8 years ago. Updated over 7 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
lib - userland libraries
Start date:
2011-04-19
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
zfs, efi, gpt, freebsd

Description

When migrating my main desktop from FreeBSD few days ago, I found out that OI doesn't recognize my GPT partitions and hence, the zpool (there were four partitions: freebsd-boot, freebsd-ufs, freebsd-swap, zfs).

Later today, I tried under VirtualBox and experienced similar problem.

Steps to reproduce, in virtualbox:
  1. create a VM with three disks
  2. install freebsd and openindiana in first disk
  3. create zfs pool from freebsd according to the method I used in attached file
  4. reboot to openindiana
  5. check partition with format > partition; and
  6. try zpool import
Expected result:
  • zfs partition made by freebsd shown in format
  • zfs pool imported successfully
Instead I got:
  • no partition defined (though the EFI partition shown properly in fdisk)
  • zpool crashed

Files

freebsd-zfs.txt (2.02 KB) freebsd-zfs.txt Edho Arief, 2011-04-19 11:56 PM
oi-zfs.txt (7.14 KB) oi-zfs.txt Edho Arief, 2011-04-19 11:56 PM

Related issues

Related to illumos gate - Bug #2170: format(1M) and prtvtoc(1M) need to handle all EFI GUIDsNew2012-02-23

Actions
Related to illumos gate - Bug #1778: Assertion failed: rn->rn_nozpool == B_FALSE, file ../common/libzfs_import.c, line 1077, function zpool_open_funcClosed2011-11-15

Actions

History

#1

Updated by Edho Arief about 8 years ago

After more messing around, I discovered that one of the reason was the efi label (or whatever it was) was on cXdYtZs2 instead of cXdYtZp0. Apparently I remembered it wrong. fdisk was complaining unable to read p0 for mysterious reason.
So I did:
  1. call fdisk to s2 part
  2. remove EFI part
  3. call normal fdisk, create EFI partition
  4. call format with -e parameter, go to partition,
  5. do label, choose EFI
  6. recreate the label with sectors etc according to FreeBSD's gpart
  7. create a temporary directory (say /a)
  8. symlink all the cXdYtZsN of zfs pool in there
  9. do zpool import -d . -f <poolname>
  10. do zpool export <poolname>
  11. do normal zpool import - now everything should be shown correctly

I guess the main problem was because OI reading partition table from s2 instead of p0 which massively confused OI.

#2

Updated by Edho Arief about 8 years ago

if my hypothesis is correct, oi doesn't recognize gpt partitions with non-solaris gptid.

Steps (not tested):
- create gpt labels/partitions under oi
- boot to freebsd
- change the partition type to freebsd's (with eg. gpart modify i N -t freebsd-zfs ad0)
reboot to oi
- check the partitions

#3

Updated by Yuri Pankov about 8 years ago

  • Difficulty set to Medium
  • Tags set to needs-triage

I've done some testing.. and removed that assert():

FreeBSD:

# gpart create -s GPT da1
da1 created
# gpart add -t freebsd-zfs da1
da1p1 added
# gpart show da1
=>      34  16777149  da1  GPT  (8.0G)
        34  16777149    1  freebsd-zfs  (8.0G)
# zpool create testpool da1p1
# zpool export testpool

Illumos:

# zpool import
  pool: testpool
    id: 10222332569722823059
 state: ONLINE
status: The pool is formatted using an older on-disk version.
action: The pool can be imported using its name or numeric identifier, though
        some features will not be available without an explicit 'zpool upgrade'.
config:

        testpool    ONLINE
          c2t1d0s0  ONLINE
# zpool import testpool
# zpool status testpool
  pool: testpool
 state: ONLINE
status: The pool is formatted using an older on-disk format.  The pool can
        still be used, but some features are unavailable.
action: Upgrade the pool using 'zpool upgrade'.  Once this is done, the
        pool will no longer be accessible on older software versions.
 scan: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        testpool    ONLINE       0     0     0
          c2t1d0s0  ONLINE       0     0     0

errors: No known data errors
# /usr/gnu/bin/dd if=/dev/urandom of=/testpool/123 bs=1M count=128
128+0 records in
128+0 records out
134217728 bytes (134 MB) copied, 4.46097 s, 30.1 MB/s
# md5sum /testpool/123
8436df602d0a0d188f899f095d5b9432  /testpool/123
# zpool export testpool

Back on FreeBSD:

# gpart show da1
=>      34  16777149  da1  GPT  (8.0G)
        34  16777149    1  freebsd-zfs  (8.0G)
# zpool import
  pool: testpool
    id: 10222332569722823059
 state: ONLINE
action: The pool can be imported using its name or numeric identifier.
config:

        testpool                                      ONLINE
          gptid/0939011f-7795-11e0-b72c-000c29c76076  ONLINE
# zpool import testpool
# zpool status testpool
  pool: testpool
 state: ONLINE
 scrub: none requested
config:

        NAME                                          STATE     READ WRITE CKSUM
        testpool                                      ONLINE       0     0     0
          gptid/0939011f-7795-11e0-b72c-000c29c76076  ONLINE       0     0     0

errors: No known data errors
# md5 /testpool/123
MD5 (/testpool/123) = 8436df602d0a0d188f899f095d5b9432

So it looks like nothing changed.. and everything worked correctly.

So the question is - what that assert should protect from?

#4

Updated by Albert Lee over 7 years ago

  • Category set to lib - userland libraries
  • Tags changed from needs-triage to zfs, efi, gpt, freebsd

There's bogus label information coming from somewhere. This might also affect unlabeled devices.

The only instance where the rn_nozpool flag is set to B_TRUE is in libzfs' check_one_slice when it determines a slice is too small to contain a pool.

check_one_slice is never called unless either read_extvtoc from libadm or efi_alloc_and_read from libefi return success to check_slices in libzfs.

check_slices should immediately return if the device name does not contain 's<digit>', so we must be successfully opening a slice as reported by the kernel. Given the above success, the slice boundaries are probably correct.

libefi is probably returning bad information to both format(1) and libzfs.

#5

Updated by Albert Lee over 7 years ago

If you need to import a FreeBSD ZFS pool, do not follow the advice in the first comment. Do:
gpart <device> # to examine the GPT/EFI label
gpart modify -i <number> -t '!6A898CC3-1DD2-11B2-99A6-080020736631' <device> # to change the GUID
This may not work if there are multiple GPT partitions. You can change the GUID back to its previous type (e.g. 'freebsd-zfs') afterward. The gpart man page has a list of types as well, but does not include Solaris/illumos GUIDs.

#6

Updated by Gordon Ross over 7 years ago

  • Status changed from New to Resolved
  • Assignee set to Yuri Pankov
changeset:   13620:97ffb0d8de52
tag:         tip
user:        Yuri Pankov <yuri.pankov@nexenta.com>
date:        Thu Feb 23 07:11:44 2012 +0400

description:
    934 FreeBSD's GPT not recognized
    Reviewed by: Alexander Eremin <alexander.r.eremin@gmail.com>
    Reviewed by: Garrett D'Amore <garrett@damore.org>
    Reviewed by: Andrew Stormont <Andrew.Stormont@nexenta.com>
    Reviewed by: Richard Elling <richard.elling@richardelling.com>
    Approved by: Gordon Ross <gwr@nexenta.com>

modified:
   usr/src/lib/libefi/common/rdwr_efi.c
   usr/src/uts/common/sys/efi_partition.h
#7

Updated by Andrew Stormont about 4 years ago

  • Related to Bug #1778: Assertion failed: rn->rn_nozpool == B_FALSE, file ../common/libzfs_import.c, line 1077, function zpool_open_func added

Also available in: Atom PDF