On 2/10/2019 11:50, Ian Lepore wrote: > On Sun, 2019-02-10 at 11:37 -0600, Karl Denninger wrote: >> On 2/10/2019 09:28, Allan Jude wrote: >>> Are you sure it is non-UEFI? As the instructions you followed, >>> overwriting da0p1 with gptzfsboot, will make quite a mess if that >>> happens to be the EFI system partition, rather than the freebsd- >>> boot >>> partition. >> [...] >> >> BTW am I correct that gptzfsboot did *not* get the ability to read >> geli-encrypted pools in 12.0? The UEFI loader does know how (which I'm >> using on my laptop) but I was under the impression that for non-UEFI >> systems you still needed the unencrypted boot partition from which to >> load the kernel. >> > Nope, that's not correct. GELI support was added to the boot and loader > programs for both ufs and zfs in freebsd 12. You must set the geli '-g' > option to be prompted for the passphrase while booting (this is > separate from the '-b' flag that enables mounting the encrypted > partition as the rootfs). You can use "geli configure -g" to turn on > the flag on any existing geli partition. > > -- Ian
Excellent - this will eliminate the need for me to run down the foot-shooting that occurred in my update script since the unencrypted kernel partition is no longer needed at all. That also significantly reduces the attack surface on such a machine (although you could still tamper with the contents of freebsd-boot of course.) The "-g" flag I knew about from experience in putting 12 on my X1 Carbon (which works really well incidentally; the only issue I'm aware of is that there's no 5Ghz WiFi support.) -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/
smime.p7s
Description: S/MIME Cryptographic Signature
