Hi! I recreated a similar setup in VirtualBox, and I can confirm: GELI won't try to attach a provider if there's no BOOT flag, and will ask for a passphrase if there is. You can report it as a bug, I suppose. Meanwhile, however, there's an easy workaround.
You can set up a passphrase, then add the following lines to your loader.conf: kern.geom.eli.passphrase="< passphrase goes here >" kern.geom.eli.boot_passcache=1 And geom_eli.ko will not ask you for a passphrase, taking it from kern.geom.eli.passphrase instead. Here *boot_passcache is invented to make it possible to reuse single passphrase for several providers, and *passphrase is where it is cached (it is cleared afterwards). So this way we can make GELI to act as if passphrase is already typed. Alternatively, you can try to play with root in RAM, or rerooting (reboot -r): starting a script from unencrypted space which will attach a provider by executing "geli -p -k ...", and changing root to a pool inside of it. But my first suggestion is clearly the easiest way. You, I believe, know this perfectly, but just in case: exposing your passwords/keys in an unencrypted part near an encrypted part which those secrets can open is not a particularly safe configuration. It can make sense if your /boot is on a removable drive, but even in this case, a passphrase, even bad one, makes it way safer if it falls to wrong hands. Best, Alaksiej Carniajeu On Sat, Oct 27, 2018 at 2:59 AM Michael .. <mi...@usa.com> wrote: > Alaksiej, > > You are correct. > > I originally tried to configure this on an installation of pfSense (using > UEFI+GPT). The default AutoZFS installer with encryption for this does > appear to create an unencrypted /boot/ with an encryption.key keyfile used > along with passphrase. I tried to set the userkey using just the keyfile > to remove the use of passphrase. I can reset a userkey using both > passphrase and keyfile (located in /boot) and the system will boot > successfully. I think this proves /boot is accessible unencrypted for > reading the keyfile. > > loader.conf is (by default): > > geli_ada0p4_keyfile0_load="YES" > geli_ada0p4_keyfile0_type="ada0p4:geli_keyfile0" > geli_ada0p4_keyfile0_name="/boot/encryption.key" > aesni_load="YES" > geom_eli_load="YES" > kern.cam.boot_delay=10000 > kern.ipc.nmbclusters="1000000" > kern.ipc.nmbjumbop="524288" > kern.ipc.nmbjumbo9="524288" > vfs.root.mountfrom="zfs:zroot/ROOT/default" > kern.geom.label.disk_ident.enable="0" > kern.geom.label.gptid.enable="0" > zpool_cache_load="YES" > zpool_cache_type="/boot/zfs/zpool.cache" > zpool_cache_name="/boot/zfs/zpool.cache" > geom_eli_passphrase_prompt="YES" > zfs_load="YES" > autoboot_delay="3" > hw.usb.no_pf="1" > > Using geli configure -B /dev/ada0p4 as you suggested results in: > > Mounting from zfs:zroot/ROOT/default failed with error 2 > > Loader variables: > vfs.root.mountfrom=zfs:zroot/ROOT/default > > When I couldn't get it working, I switched to a virtual machine running > straight FreeBSD 11.2 (albeit BIOS+GPT). I realised this evening that the > default disk partitioning is not the same - and a keyfile is not used by > default when selecting encryption under AutoZFS installer option - just a > passphrase. I guess the installer is customised for pfsense. > > Regards, > > Michael. > > _______________________________________________ > freebsd-geom@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-geom > To unsubscribe, send any mail to "freebsd-geom-unsubscr...@freebsd.org" > _______________________________________________ freebsd-geom@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-geom To unsubscribe, send any mail to "freebsd-geom-unsubscr...@freebsd.org"
