From owner-freebsd-stable@freebsd.org Sun Jul 19 22:00:11 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F23D29A4140 for ; Sun, 19 Jul 2015 22:00:11 +0000 (UTC) (envelope-from ubm@u-boot-man.de) Received: from mail.server41.configcenter.info (mail.server41.configcenter.info [31.47.242.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B986F1C32 for ; Sun, 19 Jul 2015 22:00:11 +0000 (UTC) (envelope-from ubm@u-boot-man.de) Received: from ubm.strangled.net (ipbcc16d85.dynamic.kabel-deutschland.de [188.193.109.133]) (Authenticated sender: web4) by mail.server41.configcenter.info (Postfix) with ESMTP id F27A4142A0B7 for ; Sun, 19 Jul 2015 23:32:09 +0200 (CEST) Date: Sun, 19 Jul 2015 23:32:10 +0200 From: Marc "UBM" Bocklet To: freebsd-stable Subject: Re: problem with geli and LSI controller Message-Id: <20150719233210.9d08c786050491ab37e7cc01@u-boot-man.de> In-Reply-To: <20150719161651.GQ8523@funkthat.com> References: <20150719173432.16bfa3be6d110571cbc8fe2a@gmail.com> <20150719161651.GQ8523@funkthat.com> X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.27; amd64-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (mail.server41.configcenter.info [0.0.0.0]); Sun, 19 Jul 2015 23:32:10 +0200 (CEST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 22:00:12 -0000 On Sun, 19 Jul 2015 09:16:51 -0700 John-Mark Gurney wrote: > Marc UBM via freebsd-stable wrote this message on Sun, Jul 19, 2015 at 17:34 +0200: > > a few weeks ago our Highpoint Rocket Raid controller (hptrr) started > > biting the dust (spurious channel resets). We bought a LSI 9201-16i > > (mps) to replace it. Connected to the hptrr were 4 external e-sata > > enclosures, configured in JBOD mode. Together with two disks connected > > to the onboard SATA controller, this formed a geli encrypted raidz-2 > > zpool. > > Just now, I connected the disks to the mps controller. They show > > up fine in dmesg. The problem is, when trying to attach the disks > > formerly connected to the hptrr controller, geli is unable to find the > > metadata on the disks and errors out with: > > > > "geli: Cannot read metadata from /dev/da4: Invalid argument" > > > > gpart show says "gpart: No such geom: da4" > > > > Trying to restore the geli metadata gives: > > "geli: Provider size mismatch: wrong backup file?" > > > > Is it possible that the hptrr controller handled the disks in some > > special way and it's only possible to read them there? > > This sounds like the drives were in raid0 mode, and not raw disk > mode... You might be able to recover the disk w/ geli resize, > assuming only space was added at the end, not at the begining, but > I have never personally tried that myself... I'd recommend trying > on a copy of the drive so you don't loose data if that is possible.. > > You can also try to find the old geli label w/ a command like: > dd if= bs=1m iseek= count=5 | strings -n 9 -td > > And get current disk size using diskinfo... > > Something like: > #diskinfo /dev/ada0 > /dev/ada0 512 3000592982016 5860533168 4096 0 5814021 16 63 > #dd if=/dev/ada0 iseek=$((3000592982016/1024/1024-1)) bs=1m 2>/dev/null | strings -n 6 -td | grep GEOM:: > 1530880 GEOM::ELI > 1531392 GEOM::LABEL > > You might have to go farther back than 1 MB... > > Good luck... Thanks a lot for the input - I'll be trying that as soon as possible and will report back here! Cheers, Marc