I have a test installation in a vmware and zpool status shows a root-pool in /dev/da0p4.eli => encrypted blockdevice
Its result of bsd's "auto zfs root" installation with encryption flag set to "yes"
System reboots and is rejecting the new pwd (which very short and simple and very independent from keyboardlayout => asdfg)
It asks first generically for geli pwd... later 3 times explicitly for /dev/da0pa while counting down "free tries". At the end it asks for /gpz/zfs0.eli pwd and is booting with asdfg string as pwd
After reboot zpool status shows the rootpool to be located at gpt/zfs0.eli not dev/da0p4 anymore
Steps to reproduce this:
- Adding a new password in slot 1 is succesfull with
root# geli setkey -n 1 /dev/da0p4
[...blabla] may exist old metadata in /var/backups [...blabla]
Some tests I made:
- Using initial pwd from init "qwert" works still fine and I can start system with one keyboard action qwert-Enter
- Using setkey -n 0 will overwrite first key succesfully but will end up in rejecting pwd 4 times later again.
- By the way I opened another ticket because restoring the metadata to a working pwd is "not permitted" as well.
I tested it in a booted system and attached a new virtual disk.
In a shell I can
create a new eli device,
deploy a zpool,
change eli pwd in slot 1
detach eli device
attach eli device with NEW password at first try
by the way restoring the metadada is still possible
Before you re-keyed, did you have a keyfile?
Check your /boot/loader.conf for lines that load a GELI key file for each disk, by name. This is likely why the new correct passphrase doesn't work with the device name (because the old keyfile is being loaded and mixed with the passphrase). When GELI then seeing the device by an alternative label, and attempts to attach, there are not keyfiles loaded via /boot/loader.conf, and the correct passphrase succeeds in attaching.