Date: Wed, 13 Jun 2018 16:46:35 -0400 From: Michael Jung <mikej@mikej.com> To: Ian Lepore <ian@freebsd.org> Cc: freebsd-current@freebsd.org, owner-freebsd-current@freebsd.org Subject: Re: GELI attach issue from r326073 -> r334996 Message-ID: <174be0c8f126d47300df51392655d028@mikej.com> In-Reply-To: <1528918051.12122.70.camel@freebsd.org> References: <1aa4ba2a8313f602bd0b0445987c18ec@mikej.com> <1528918051.12122.70.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?174be0c8f126d47300df51392655d028>