On 02/22/12 06:10, Roberto Waltman wrote:
2011-08-23.23:48:35 zfs set
keysource=passphrase,file:///root/passphrases/slice_2_passphrase
slice_2/base/bitsavers
That should have failed because the keysource property is inherited from
slice_2/base. So you have found a bug and I can reproduce it.
On 02/21/12 01:58, Roberto Waltman wrote:
First, I did the 2nd. (Change location only)
I believe I tried the first form also *after*
things were already broken, but I'm sure the
passphrases were identical: slice_08, slice_18
and slice_28 for each pools 0/1/2. - The '8'
to bring the length to the
On Tue, Feb 21, 2012 at 11:12:14AM +, Darren J Moffat wrote:
Did you ever do a send|recv of these filesystems ? There was a bug with
send|recv in 151a that has since been fixed that could cause the salt to
be zero'd out in some cases.
Ah, so that's what that was.
I hit this problem
Darren J Moffat wrote:
...
Can you send the 'zpool history slice_2' output so I can see what
commands have been run.
Pasted at the end - My recollection of the events was
wrong, I started with keysource=passphrase,file...
not prompt. (Used prompt in earlier experiments and
mixed things up)
On 02/18/12 05:12, Roberto Waltman wrote:
Solaris 11 Express 1010.11/snv_151a
I strongly suggest upgrading to Solaris 11 there have been some
important ZFS and specifically ZFS encryption related bug fixes.
They were created with encryption
on, forcing all others to be encrypted.
The
Darren J Moffat wrote:
Thanks for the reply,
I strongly suggest upgrading to Solaris 11 there have been some
important ZFS and specifically ZFS encryption related bug fixes.
Will do. (At least temporarily, until this
problem is solved. Long term plan is
switching to FreeNAS, even if that
