gptid conflict FreeNAS 8.3

[dwoodard3950]

I recently configured a 4drive RAIDZ2 with varying size drives. I then replaced a 2TB drive in the pool. I then attempted to export the pool and failed. So, I decided to just start over (only installed 8GB at that time). Now, I can't get past the following error;

manage.py: [middleware.exceptions:38] [MiddlewareError: Disk replacement failed: "invalid vdev specification, use '-f' to override
the following errors:, /dev/gptid/532821dd-47a9-11e2-8734-6805ca09f08c is part of active pool 'tank', "]

I "solved" this by use -f from CLI and all seemed well except CLI zpool status reported a larger pool than the GUI. This seems to be of course the reason not to do it at CLI. I then figured I could solve it by "OFFLINE" the disk from the GUI and then "ONLINE" again from the GUI. The only option is to REPLACE, so that is what I have attempted to do. Now, I again get the conflicting gptid. I'd prefer to not return to CLI to get into the pool as that will leave me with a mismatch again. So, how do I flush the history of this disk from the pool so I can add it as though it is a new disk?

Some output results; zpool status
pool: tank
state: DEGRADED
status: One or more devices could not be opened. Sufficient replicas exist for
the pool to continue functioning in a degraded state.
action: Attach the missing device and online it using 'zpool online'.
see: http://www.sun.com/msg/ZFS-8000-2Q
scan: resilvered 128G in 0h52m with 0 errors on Sat Dec 15 23:53:48 2012
config:

NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
raidz2-0 DEGRADED 0 0 0
gptid/b7244e42-4625-11e2-9b3c-a0b3cce8945b ONLINE 0 0 0
3680965071244301353 UNAVAIL 0 0 0 was /dev/dsk/gptid/81da4300-47a0-11e2-9c47-6805ca09f08c
gptid/594fa4bb-474e-11e2-9c47-6805ca09f08c ONLINE 0 0 0
gptid/b27b2a10-4634-11e2-90da-a0b3cce8945b ONLINE 0 0 0

errors: No known data errors

glabel lsit
Geom name: ada0p2
Providers:
1. Name: gptid/532821dd-47a9-11e2-8734-6805ca09f08c
Mediasize: 1998251364352 (1.8T)
Sectorsize: 512
Stripesize: 4096
Stripeoffset: 0
Mode: r0w0e0
secoffset: 0
offset: 0
seclength: 3902834696
length: 1998251364352
index: 0
Consumers:
1. Name: ada0p2
Mediasize: 1998251364352 (1.8T)
Sectorsize: 512
Stripesize: 4096
Stripeoffset: 0
Mode: r0w0e0
Geom name: ada0p1
Providers:
1. Name: gptid/5313821a-47a9-11e2-8734-6805ca09f08c
Mediasize: 2147483648 (2.0G)
Sectorsize: 512
Stripesize: 4096
Stripeoffset: 0
Mode: r0w0e0
secoffset: 0
offset: 0
seclength: 4194304
length: 2147483648
index: 0
Consumers:
1. Name: ada0p1
Mediasize: 2147483648 (2.0G)
Sectorsize: 512
Stripesize: 4096
Stripeoffset: 0
Mode: r0w0e0

gpart show
=> 34 3907029101 ada0 GPT (1.8T)
34 94 - free - (47k)
128 4194304 1 freebsd-swap (2.0G)
4194432 3902834696 2 freebsd-zfs (1.8T)
3907029128 7 - free - (3.5k)

 

[jgreco]

I wonder if you're treating that the wrong way around. Why not blank the disk? Since the gptid stuff comes from the label gpt has placed on the disk, making the disk look blank seems like it'd be likely to work.

 

[dwoodard3950]

I wonder if you're treating that the wrong way around. Why not blank the disk? Since the gptid stuff comes from the label gpt has placed on the disk, making the disk look blank seems like it'd be likely to work.

Thanks! I tried clearing the disk (or at least the partition tables) by using gdisk on a linux machine and "zap" the tables. I had expected that would do the same as wiping the disk with the freenas gui. Nonetheless, wiping and clearing with zeros using the freenas gui was successful. It is resilvering now.

 

[jgreco]

Awesome. It's also great to know that it actually works from the GUI...