GELI attach issue from r326073 -> r334996

[Michael Jung]

On 2018-06-13 15:27, Ian Lepore wrote:
> On Wed, 2018-06-13 at 14:29 -0400, Michael Jung wrote:
>> Hi!
>> 
>> I just tried updating current from r326073 -> r334996 and when
>> I try 'geli attach' I get the following error:
>> 
>> # geli attach -p -k mykey.key /dev/gpt/da14
>> geli: Missing keyno argument
>> #
>> 
>> If I boot the old kernel GELI attaches just fine.
>> 
>> I ran into this once before but can not find the thread.  I recall
>> it being a bug... with no resolution.
>> 
>> I mount zfs partitions over GELI - my painful solution was to
>> nuke each GPT partition in the zpool, resilver, repeat and
>> rinse until everything was non-encrypted and repeat the cycle
>> to re-encrypt.  NOT FUN.
>> 
>> Looking for suggestions to supply additional information to debug
>> and resolve.
>> 
>> dmesg attached from working kernel.
>> 
>> Thanks!
> 
> r333439 added a '-n keyno' parameter to geli attach, but it's supposed
> to default to trying all keys if you don't use -n. Is it possible
> you're running a newer kernel (or geom_eli module) than your userland
> or vice versa?
> 
> -- Ian
> 
> 
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to 
> "freebsd-current-unsubscribe at freebsd.org"

Ian:

Yes you are correct.... Maybe not the best method but I normally 
installkernel -
boot into single user mode - GELI attach, zfs mount -av, then 
installworld.

My boot volume is UFS, but many of the mount points are on zpools.

What would be the best way to test a new kernel without a full 
installworld
with new userland geli bits?

I currently don't have a way to backup my 35TB of data :-( and don't 
want to
lose anything..... and I need a back out method should a full 
installworld fail.

Thanks for you quick reply.

--mikej