Created a GELI-setup using only a keyfile, partition to be mounted at boot. When trying to set the secondary-key (key 1) using a passphrase incase the keyfile is lost, the following happens: ------------------------------------------------ 42-gw# geli setkey -v -n 1 /dev/mirror/world Enter new passphrase: Reenter new passphrase: Calculating number of iterations... Done, using 138302 iterations. geli: Only already defined key can be changed when '-i' option is used. ------------------------------------------------ Note that the provider was attached at the time. Fix: Workaround: Setting the first key (key 0) that was used for attaching the provider with a keyfile, works: ------------------------------------------------ 42-gw# geli setkey -v -n 0 /dev/mirror/world Enter new passphrase: Reenter new passphrase: Calculating number of iterations... Done, using 80194 iterations. Done. ------------------------------------------------ After that, setting the secondary key also works: ------------------------------------------------ 42-gw# geli setkey -v -n 1 /dev/mirror/world Enter new passphrase: Reenter new passphrase: Done. 42-gw# ------------------------------------------------ After that, I can set the primary key back to the keyfile. How-To-Repeat: Create a GELI slice with only a keyfile, no password, to be mounted on boot, then try to set secondary key while the provider is attached.
Responsible Changed From-To: freebsd-bugs->freebsd-geom Over to maintainer(s).
I can confirm that this pr applies to 8.0RC2 as well. Is anyone working on this? I am happy to test patches. Riggs
By design, geli only stores one iteration count on disk and as a result, some key combinations are not supported. Setting both keys to passphrase+keyfile is fine and so is using a passphrase for one key and passphrase+keyfile for the other one. Letting only one of two keys use a passphrase is not supported because this would require different iteration values which can't be stored on disk. Your "workaround" does not actually work around this limitation because it does not require two different iteration counts. It could be argued that the error message is a bit cryptic and that geli.8 should document this limitation more explicitly, but the fact that you get an error message itself is not a bug.
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
I stumbled across this while searching for related information. As indicated in comment 3, this is not a bug it's by design, so I'm closing this.