Taken from rc.conf():
IMO the most significant advantage this has over loader.conf()'s undocumented geli_<name>_keyfile is (other then obviously to be documented) the ability to attach a large number of disks (with potentially differing secrets) at once from an encrypted root partition without compromising the secret (keyfiles) on the non-encrypted boot medium.
However, in large disk environments it would be straightforward to use geom labels to identify disks rather then scan-order dependend names. Therefore <device> would be something like label/somename, i.e. contain the slash character which is AFAIK not valid to be contained in a shell variable name.
Is there any workaround to this?
And when I'm asking here already, can I somehow have the root partition unmounted and replaced by an zraid root one after geli attached it's vdev members?
Code:
geli_default_flags
(str) Default flags to use by geli(8) when configuring disk
encryption. Flags can be configured for every device sepaâ€
rately by defining geli_⟨device⟩_flags variable.IMO the most significant advantage this has over loader.conf()'s undocumented geli_<name>_keyfile is (other then obviously to be documented) the ability to attach a large number of disks (with potentially differing secrets) at once from an encrypted root partition without compromising the secret (keyfiles) on the non-encrypted boot medium.
However, in large disk environments it would be straightforward to use geom labels to identify disks rather then scan-order dependend names. Therefore <device> would be something like label/somename, i.e. contain the slash character which is AFAIK not valid to be contained in a shell variable name.
Is there any workaround to this?
And when I'm asking here already, can I somehow have the root partition unmounted and replaced by an zraid root one after geli attached it's vdev members?