Bug #934
closed
FreeBSD's GPT not recognized
0%
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:- 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
Files
Related issues
Updated by Edho Arief almost 12 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
/a) - symlink all the cXdYtZsN of zfs pool in there
- do
zpool import -d . -f <poolname> - do
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 almost 12 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 almost 12 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?
Updated by Albert Lee over 11 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 about 11 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 about 11 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
Updated by Andrew Stormont almost 8 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