Stale zpool from a prior life in "zpool import"

Chris Stankevitz cstankevitz at toyon.com
Tue Feb 14 20:56:08 UTC 2017


I have some drives whose "entire disk" was used to create a pool -- then 
they were repurposed to create a different pool with the same name on 
encrypted geli partitions:

#==========

# create zpool using entire disk

zpool create tank mirror /dev/da5 /dev/da6

zpool export tank

# use same disks to create zpool using geli on a partition

gpart create -S GPT /dev/da5
gpart create -S GPT /dev/da6

gpart add -t freebsd-zfs -a 1M -l tank-1 /dev/da5
gpart add -t freebsd-zfs -a 1M -l tank-2 /dev/da6

geli init -e AES-XTS -l 256 -P -s 4096 -K /path/to/key /dev/gpt/tank-1
geli init -e AES-XTS -l 256 -P -s 4096 -K /path/to/key /dev/gpt/tank-2

geli attach -p -k /path/to/key /dev/gpt/tank-1
geli attach -p -k /path/to/key /dev/gpt/tank-2

zpool create tank mirror /dev/gpt/tank-1.eli /dev/gpt/tank-2.eli

#==========

Nowadays "zpool import" shows two pools.  One on the encrypted geli 
paritions (which is available) and another from the remnants of the the 
unencrypted "full disk" (which are UNAVAIL and corrupted).  They both 
share the same name but of course have different ids.

How do I remove the UNAVAIL zpool?

Thank you,

Chris

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5946 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20170214/5a3a03bd/attachment.bin>


More information about the freebsd-questions mailing list