| Summary: | Installer can't install over existing ZFS | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Jonathan Anderson <jonathan> |
| Component: | bin | Assignee: | Allan Jude <allanjude> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | CC: | allanjude |
| Priority: | --- | ||
| Version: | CURRENT | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Jonathan Anderson
2016-07-04 13:06:11 UTC
Also, "blow away this disk for my fresh install" should include de-activating GELI, where appropriate. This is necessary if, for example, the installer gets restarted on a partially-prepared disk. In that case, gpart can't destroy the geom until geli has been detached. (In reply to Jonathan Anderson from comment #0) The installer totally destroys the disk, including a pedantic zpool labelclear on the partition that the bootpool is going to be created in. Are you sure this was an error coming from your existing installation, or, more like your second comment, is caused by an aborted installation and restarting the installer without rebooting? Or was the bootpool on some other disk? (In reply to Jonathan Anderson from comment #1) Yes, the GELI blocking the disk from being blown away is a known issue. I have written a patch to detach all attached GELI providers and export all zfs pools before attempting to destroy the disk A commit references this bug: Author: allanjude Date: Sat Jul 16 19:35:04 UTC 2016 New revision: 302941 URL: https://svnweb.freebsd.org/changeset/base/302941 Log: A failed installation once restarted will often error out If an encrypted install is attempted and fails for any reason, the disk cannot be erased by the installer because the partition is in use by GELI At the start of the installation process, all ZFS pools are exported and all GELI instances are detached, to allow a restarted install to proceed PR: 210814 Reported by: jonathan MFC after: 10 days Changes: head/usr.sbin/bsdinstall/scripts/zfsboot I think you might be right: I only observed this issue on the second time I tried to set up the ZFS+GELI installation. The first time, I was blocked by another bug (which you have since fixed). This patch looks like it does the same things I had to manually complete before, so hopefully it's fixed now. I'm not currently able to re-test on the same machine (it's my primary FreeBSD machine that I would rather not blow away at the moment), but would it help for me to try and run through the same scenario on a VM? Thanks for improving our installer so much, Jon (In reply to Jonathan Anderson from comment #5) I would appreciate any testing you can do, to try to iron out any remaining bugs in time for 11.0-RELEASE A commit references this bug: Author: allanjude Date: Tue Jul 26 05:26:07 UTC 2016 New revision: 303330 URL: https://svnweb.freebsd.org/changeset/base/303330 Log: MFC: r302941 At the start of the installation process, all ZFS pools are exported and all GELI instances are detached, to allow a restarted install to proceed. PR: 210814 Approved by: re (gjb) Changes: _U stable/11/ stable/11/usr.sbin/bsdinstall/scripts/zfsboot |