Date: Sun, 19 Apr 2020 05:39:38 -0700 From: Mel Pilgrim <list_freebsd@bluerosetech.com> To: Allan Jude <allanjude@freebsd.org>, freebsd-current@freebsd.org Subject: Re: OpenZFS port updated Message-ID: <895bf7c8-d154-8f80-b0a3-50b54919d6f1@bluerosetech.com> In-Reply-To: <dc2b85cb-ed82-802d-9b34-61e626ec9ef6@freebsd.org> References: <A61E33DF-96D0-449D-8665-9089599F0583@FreeBSD.org> <ec813ec5-1d6a-c679-bca5-f21b516ad47e@bluerosetech.com> <CACNAnaF3qAy3_kk_%2BDE5T4shDG97=ZD%2BGb-cokBYJQ3fyn7p6w@mail.gmail.com> <8abb14b2-7426-559d-af7e-c339fa130515@bluerosetech.com> <dc2b85cb-ed82-802d-9b34-61e626ec9ef6@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-04-18 18:16, Allan Jude wrote: > If you still have a bootpool, you can migrate to a single pool (so boot > environments work), using these instructions: > https://ftfl.ca/blog/2016-09-17-zfs-fde-one-pool-conversion.html > > If the pool would boot without GELI, it still will with GELI, however, > if you use any of the newer features not supported by the boot loader, > then it will not be able to read the kernel from the boot (encrypted or not) My use case requires unattended booting and never storing the keyfiles on the disks to which they correspond so that, in the event of a disk failure, it can be recycled or sent back to the OEM safely. AFAIK the userkey files have to be on the same filesystem as the loader, which, for this use case, requires /boot be separate?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?895bf7c8-d154-8f80-b0a3-50b54919d6f1>