Date: Mon, 18 Jun 2018 11:24:08 +0800 From: Julian Elischer <julian@freebsd.org> To: freebsd-current@freebsd.org, mikej@mikej.com Subject: Re: GELI attach issue from r326073 -> r334996 Message-ID: <0398d5c9-5da0-3fab-38a0-2e0a60ae460b@freebsd.org> In-Reply-To: <174be0c8f126d47300df51392655d028@mikej.com> References: <1aa4ba2a8313f602bd0b0445987c18ec@mikej.com> <1528918051.12122.70.camel@freebsd.org> <174be0c8f126d47300df51392655d028@mikej.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 14/6/18 4:46 am, Michael Jung wrote: > 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@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@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. 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? > > 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 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0398d5c9-5da0-3fab-38a0-2e0a60ae460b>