FreeBSD's GPT not recognized
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:
- create a VM with three disks
- install freebsd and openindiana in first disk
- create zfs pool from freebsd according to the method I used in attached file
- reboot to openindiana
- check partition with format > partition; and
- try zpool import
- zfs partition made by freebsd shown in format
- zfs pool imported successfully
- no partition defined (though the EFI partition shown properly in fdisk)
- zpool crashed
Updated by Edho Arief over 8 years ago
So I did:
- call fdisk to s2 part
- remove EFI part
- call normal fdisk, create EFI partition
- call format with
-eparameter, go to partition,
- do label, choose EFI
- recreate the label with sectors etc according to FreeBSD's gpart
- create a temporary directory (say
- symlink all the cXdYtZsN of zfs pool in there
zpool import -d . -f <poolname>
zpool export <poolname>
- 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.
Updated by Edho Arief over 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
Updated by Yuri Pankov over 8 years ago
- Difficulty set to Medium
- Tags set to needs-triage
I've done some testing.. and removed that assert():
# 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
# 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?
Updated by Albert Lee about 8 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.
Updated by Albert Lee almost 8 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.
Updated by Gordon Ross almost 8 years ago
- Status changed from New to Resolved
- Assignee set to Yuri Pankov
changeset: 13620:97ffb0d8de52 tag: tip user: Yuri Pankov <email@example.com> date: Thu Feb 23 07:11:44 2012 +0400 description: 934 FreeBSD's GPT not recognized Reviewed by: Alexander Eremin <firstname.lastname@example.org> Reviewed by: Garrett D'Amore <email@example.com> Reviewed by: Andrew Stormont <Andrew.Stormont@nexenta.com> Reviewed by: Richard Elling <firstname.lastname@example.org> Approved by: Gordon Ross <email@example.com> modified: usr/src/lib/libefi/common/rdwr_efi.c usr/src/uts/common/sys/efi_partition.h