Hi all, 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? Bye Marc
On Sun, 19 Jul 2015 17:34:32 +0200 Marc "UBM" Bocklet <ubm.freebsd at gmail.com> wrote:> Hi all, > > 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? > > Bye > MarcI forgot to add that the system is running: FreeBSD xxx 10.1-BETA1 FreeBSD 10.1-BETA1 #27 r271633: Mon Sep 15 22:34:05 CEST 2014 Bye Marc
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."