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