Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 19 Jul 2015 09:16:51 -0700
From:      John-Mark Gurney <jmg@funkthat.com>
To:        Marc UBM <ubm.freebsd@googlemail.com>
Cc:        freebsd-stable <freebsd-stable@freebsd.org>
Subject:   Re: problem with geli and LSI controller
Message-ID:  <20150719161651.GQ8523@funkthat.com>
In-Reply-To: <20150719173432.16bfa3be6d110571cbc8fe2a@gmail.com>
References:  <20150719173432.16bfa3be6d110571cbc8fe2a@gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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=<disk> bs=1m iseek=<location> 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...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150719161651.GQ8523>