Hi,
I already asked this in PR 206600 but got no reply till now. This is a very generic thing and I am wondering that I shall be the first stepping in. I going to move over from Debian to FreeBSD because ZFSonLinux drives me mad with systemd boot but at least I trusted LUKS/dm-crypt...
The conditions:
I have a FreeBSD installation in a VMWarePlayer created with installer-dvd 10.2.
It's all result of FreeBSD's "auto zfs root" installation with encryption flag set to "yes"... that is what FreeBSD defines as baseline for ZFS. I have not played around with manual activities (mainly because the installer's navigation is buggy).
Symptom:
I define an additional pwd in slot 1, while slot 0 is used from geli init:
System reboots normal and is rejecting the new pwd (which very short and simple and very independent from default us-keyboardlayout => asdfg).
It asks first generically for geli pwd... later 3 times explicitly for /dev/da0pa4 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 any more.
Steps to reproduce this:
- Adding a new password in slot 1 is successful with:
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
- A non-root ZFS in a geli container behaves like the it should.. I can create a da1p1.eli and change password by using
=> It has to do with ongoing boot process maybe sdout is pushed to pwd as well?
Any ideas?
Marc
I already asked this in PR 206600 but got no reply till now. This is a very generic thing and I am wondering that I shall be the first stepping in. I going to move over from Debian to FreeBSD because ZFSonLinux drives me mad with systemd boot but at least I trusted LUKS/dm-crypt...
The conditions:
I have a FreeBSD installation in a VMWarePlayer created with installer-dvd 10.2.
zpool status shows a root-pool in /dev/da0p4.eli => encrypted blockdevice and a bootpoolIt's all result of FreeBSD's "auto zfs root" installation with encryption flag set to "yes"... that is what FreeBSD defines as baseline for ZFS. I have not played around with manual activities (mainly because the installer's navigation is buggy).
Symptom:
I define an additional pwd in slot 1, while slot 0 is used from geli init:
System reboots normal and is rejecting the new pwd (which very short and simple and very independent from default us-keyboardlayout => asdfg).
It asks first generically for geli pwd... later 3 times explicitly for /dev/da0pa4 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 any more.
Steps to reproduce this:
- Adding a new password in slot 1 is successful with:
Code:
root# geli setkey -n 1 /dev/da0p4
[...blabla] may exist old metadata in /var/backups [...blabla]
root# rebootSome 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 successfully but will end up in rejecting this pwd 4 times later again...- A non-root ZFS in a geli container behaves like the it should.
geli setkey -n 1 /dev/da1p1...=> It has to do with ongoing boot process maybe sdout is pushed to pwd as well?
Any ideas?
Marc