Project

General

Profile

Bug #27128

Do not destroy volume if wizard import fails

Added by Eric Loewenthal 10 months ago. Updated 10 months ago.

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

Description

Reports are still trickling in that some cases can lead to FreeNAS destroying GELI metadata (for encrypted pools) or the partition table (for unencrypted pools) and issuing zpool destroy when cleaning up after a traceback, much like in #26834.

I don't have many details yet, but the following cases have been brought to my attention:

During an update from 9.10.2-U6 to 11.0-U4, the update got stuck. After installing 11.0-U4 to new media, the pool was gone - it was not encrypted, so it could be recovered with zpool import -D and zpool destroy had been issued. Another forum user tried this out in his test environment and reported that updating to 11.0-U4 will murder pools if the boot pool runs out of space during the process.

Importing a non-encrypted Corral pool on a fresh 11.1-RC3 install resulted in the partition tables being wiped and the pool being destroyed. This one also seems to be recoverable, though still unacceptable. I don't know what the actual error is that triggers this behavior.


Related issues

Related to FreeNAS - Bug #26834: Do not destroy GELI metadata on failed encrypted importResolved2017-11-25

Associated revisions

Revision 73d6b829 (diff)
Added by William Grzybowski 10 months ago

fix(gui): do not destroy volume on failed wizard form

Ticket: #27128

Revision 25a63629 (diff)
Added by William Grzybowski 10 months ago

fix(gui): do not destroy volume on failed wizard form

Ticket: #27128
(cherry picked from commit 73d6b8293a2784ea294c5151d9738ec61fbda96f)

Revision dc7d195f (diff)
Added by William Grzybowski 10 months ago

fix(gui): do not destroy volume on failed wizard form

Ticket: #27128
(cherry picked from commit 73d6b8293a2784ea294c5151d9738ec61fbda96f)

Revision 1c067735 (diff)
Added by William Grzybowski 10 months ago

fix(gui): do not destroy volume on failed wizard form

Ticket: #27128

History

#1 Updated by Eric Loewenthal 10 months ago

Correction: The first situation has not been reproduced after all, so the "out of space boot pool" bit is speculation.

#2 Updated by Dru Lavigne 10 months ago

  • Assignee changed from Release Council to William Grzybowski
  • Priority changed from No priority to Critical

#3 Updated by Dru Lavigne 10 months ago

  • Related to Bug #26834: Do not destroy GELI metadata on failed encrypted import added

#4 Updated by William Grzybowski 10 months ago

  • Subject changed from Pools are still being murdered when cleaning up certain tracebacks to Pool destroyed on Wizard error
  • Status changed from Unscreened to Screened
  • Priority changed from Critical to Blocks Until Resolved
  • Target version set to 11.1

I can reproduce pool destroying if Wizard fails.

I cannot reproduce the full boot pool issue, perhaps that should be a different issue.

#5 Updated by Eric Loewenthal 10 months ago

William: Could you guys go through every call of volume.delete() and make sure that they're not relying on defaults? That is, if you haven't already.

At that point, Allan Jude's fix from the other day should be free from side-effects, too, and mitigate the damage in this sort of scenario in new code.

#6 Updated by William Grzybowski 10 months ago

  • Status changed from Screened to Ready For Release

#7 Updated by Dru Lavigne 10 months ago

  • Subject changed from Pool destroyed on Wizard error to Do not destroy volume if wizard import fails

#8 Updated by Dru Lavigne 10 months ago

  • Status changed from Ready For Release to Resolved

Also available in: Atom PDF