Do not destroy GELI metadata on failed encrypted import
A user contacted me on the forums because he had seen ticket #26507 and could reproduce it with non-Corral pools - which makes sense, because pools could be recovered from Corral's weird format with the instructions the reporter of #26507 used on FreeNAS 11.0.
tl;dr - trying to import an encrypted pool can have destructive consequences for the pool.
The sequence of steps for reproducing this is as follows:
1) Create an encrypted pool on 11.0-U3
2) Backup the key, as per the manual
3) Update to 11.0-U4 and import the pool with the key - everything works
4) Update to 11.1-RC1 and try to import the pool: Errors will be thrown and the GELI metadata will be deleted. To add insult ot injury, opening the disks with backed-up GELI metadata shows that the pool was destroyed.
This almost certainly blocks RELEASE.
#2 Updated by Eric Loewenthal about 3 years ago
Okay, so we've been doing some investigation with help from Allan Jude.
There seem to be two issues here:
1) Any exception during pool import will be handled by destroying the pool. (!!!)
2) Several scenarios with encrypted pools seem to trigger this database error (example below):
Request Method: POST
Request URL: http://192.168.0.2/storage/auto-import/
Software Version: FreeNAS-11.1-RC1 (ff06285bd)
Exception Type: IntegrityError
UNIQUE constraint failed: storage_encrypteddisk.encrypted_provider
Exception Location: ./freenasUI/freeadmin/sqlite3_ha/base.py in locked_retry, line 389
Server time: Sat, 4 Nov 2017 23:05:23 -0700
Presumably due to multiple keys being available?
GELI itself seems to operate normally without issues - if the import wizard is used up until (before) the actual pool importing happens, zpool import shows a healthy pool available for importing.
A patch should be incoming from Allan.