GELI attach issue from r326073 -> r334996

[Michael Jung]

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!

[Ian Lepore]

Post by Michael Jung
Hi!
I just tried updating current from r326073 -> r334996 and when
# 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

[Michael Jung]

Post by Ian Lepore

Post by Michael Jung
Hi!
I just tried updating current from r326073 -> r334996 and when
# 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
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to

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

[Julian Elischer]

Post by Michael Jung

Post by Ian Lepore

Post by Michael Jung
Hi!
I just tried updating current from r326073 -> r334996 and when
# 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
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to

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.

Yes that is the prescribed method. if it doesn't work then whoever
changed the
geli code should fix it to handle this.
You should be able to run older code on newer kernels with very few
exceptions.
I don't know if this also affects upgrades form 11. Have you tested that?

Post by Michael Jung
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
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to