From owner-freebsd-stable@freebsd.org Mon Jul 20 13:48:35 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 60FB59A5094 for ; Mon, 20 Jul 2015 13:48:35 +0000 (UTC) (envelope-from dewayne.geraghty@consciuminternational.com.au) Received: from hermes.heuristicsystems.com.au (hermes.heuristicsystems.com.au [203.41.22.115]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "hermes.heuristicsystems.com.au", Issuer "Heuristic Systems Type 4 Host CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DAD50A32 for ; Mon, 20 Jul 2015 13:48:34 +0000 (UTC) (envelope-from dewayne.geraghty@consciuminternational.com.au) Received: from [10.0.5.3] (ewsw01.hs [10.0.5.3]) (authenticated bits=0) by hermes.heuristicsystems.com.au (8.14.6/8.13.6) with ESMTP id t6KDlCCc042490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=FAIL); Mon, 20 Jul 2015 23:47:24 +1000 (EST) (envelope-from dewayne.geraghty@consciuminternational.com.au) Subject: Re: problem with geli and LSI controller To: Marc UBM Bocklet References: <20150719173432.16bfa3be6d110571cbc8fe2a@gmail.com> <20150719161651.GQ8523@funkthat.com> <20150720095650.869f85a7f04abf5ade364be3@u-boot-man.de> From: Dewayne Geraghty X-Enigmail-Draft-Status: N1110 Cc: freebsd-stable Message-ID: <55ACFBED.5040408@consciuminternational.com.au> Date: Mon, 20 Jul 2015 23:47:25 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <20150720095650.869f85a7f04abf5ade364be3@u-boot-man.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: Mon, 20 Jul 2015 13:48:35 -0000 On 20/07/2015 5:56 PM, Marc UBM Bocklet wrote: > 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... > No luck so far, diskinfo gives me: > > #diskinfo da4 > da4 512 2000398934016 3907029168 4096 0 243201 255 63 > > but > #dd if=/dev/da4 iseek=$((2000398934016/1024/1024-1)) bs=1m 2>/dev/null | strings -n 6 -td | grep GEOM:: > yields nothing. Marc, Sometimes shell scripts calculations can be daunting. Refer to this $((2000398934016/1024/1024-1)) Now the following portion which converts bytes to MB 2000398934016/1024/1024 that is, dividing bytes by 1M (first by 1KB=1024 then again, means its effectively 1Meg) and you have then subtracted 1 MB from it. To step further back from the end of the hard-disk, you could, for example go back 2MB $((2000398934016/1024/1024-2))