Project

General

Profile

Bug #26834

Do not destroy GELI metadata on failed encrypted import

Added by Eric Loewenthal about 1 year ago. Updated about 1 year ago.

Status:
Resolved
Priority:
Critical
Assignee:
William Grzybowski
Category:
Middleware
Target version:
Seen in:
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
No
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:
ChangeLog Required:
No

Description

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.


Related issues

Related to FreeNAS - Bug #26507: 11.1-RC1 and 11-nightlies fail to import volume from encrypted drives, nuke GELI metadata and destroy volumeClosed: Duplicate2017-11-05
Related to FreeNAS - Bug #27128: Do not destroy volume if wizard import failsResolved2017-12-10
Has duplicate FreeNAS - Bug #26838: Add QA for encrypted poolsClosed: Duplicate2017-11-26

Associated revisions

Revision aa5a6d76 (diff)
Added by William Grzybowski about 1 year ago

fix(gui): do not destroy geli metadata on failed encrypted import

Ticket: #26834

Revision 7cc14d65 (diff)
Added by William Grzybowski about 1 year ago

fix(gui): do not destroy geli metadata on failed encrypted import

Ticket: #26834
(cherry picked from commit aa5a6d76fc1c662f57f44300af16ea695085f300)

Revision ae205df4 (diff)
Added by William Grzybowski about 1 year ago

fix(gui): do not destroy geli metadata on failed encrypted import (#507)

Ticket: #26834

Revision 3d7ae5b7 (diff)
Added by William Grzybowski about 1 year ago

fix(gui): do not destroy geli metadata on failed encrypted import

Ticket: #26834
(cherry picked from commit aa5a6d76fc1c662f57f44300af16ea695085f300)

History

#1 Updated by Eric Loewenthal about 1 year ago

Another reproduction of this:

https://youtu.be/6r1zcQPYb0s

#2 Updated by Eric Loewenthal about 1 year 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
Exception Value:
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.

#3 Updated by The m0nkey_ about 1 year ago

  • File debug.log_20171125 added

Please find attached debug.log. See line 751, you can see 'zpool destroy' was executed, along with 'gpart destroy' during the import of the encrypted pool.

#4 Updated by Eric Loewenthal about 1 year ago

See https://github.com/freenas/freenas/pull/505 for dealing with 1).

2) still needs work, as it will prevent many/most encrypted pools from being mounted (but no longer straight up murder them).

#5 Avatar?id=14398&size=24x24 Updated by Kris Moore about 1 year ago

  • Assignee changed from Release Council to William Grzybowski
  • Priority changed from No priority to Critical
  • Target version set to 11.1

#6 Updated by Dru Lavigne about 1 year ago

  • Private changed from No to Yes

#7 Updated by Dru Lavigne about 1 year ago

  • Has duplicate Bug #26838: Add QA for encrypted pools added

#8 Updated by Eric Loewenthal about 1 year ago

  • Private changed from Yes to No

This doesn't need to be private, the debug tarball comes from m0nkey's test VM and shouldn't contain anything sensitive.

#9 Updated by William Grzybowski about 1 year ago

  • Status changed from Unscreened to Screened

#10 Updated by William Grzybowski about 1 year ago

  • Target version changed from 11.1 to 11.1-RC2

#11 Updated by Dru Lavigne about 1 year ago

  • Subject changed from 11.1-RC1 murders innocent encrypted pools to Do not destroy GELI metadata on failed encrypted import

#12 Updated by William Grzybowski about 1 year ago

  • Status changed from Screened to Ready For Release

#13 Updated by Nick Wolff about 1 year ago

Hotpatch tested successfully will retest with rc2 when available and pass test at that point

#14 Updated by Dru Lavigne about 1 year ago

  • Related to Bug #26507: 11.1-RC1 and 11-nightlies fail to import volume from encrypted drives, nuke GELI metadata and destroy volume added

#15 Updated by Nick Wolff about 1 year ago

  • Needs QA changed from Yes to No
  • QA Status Test Passes FreeNAS added
  • QA Status deleted (Not Tested)

Tested with rc2. Test passes

#16 Updated by Dru Lavigne about 1 year ago

  • Target version changed from 11.1-RC2 to 11.1-RC3

#17 Updated by Dru Lavigne about 1 year ago

  • Status changed from Ready For Release to Resolved

#18 Updated by Dru Lavigne 12 months ago

  • Related to Bug #27128: Do not destroy volume if wizard import fails added

#19 Updated by Dru Lavigne 12 months ago

  • File deleted (debug.log_20171125)

Also available in: Atom PDF