Re: problem with geli and LSI controller
On 20/07/2015 5:56 PM, Marc UBM Bocklet wrote: On Sun, 19 Jul 2015 09:16:51 -0700 John-Mark Gurney j...@funkthat.com 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=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 40960 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 40960 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)) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: problem with geli and LSI controller
Hello, Replying to myself again, it appears that the safest way is to get a Rocket Raid controller identical to the one we had, put it in another system, connect the disks, import the old pool and move the data to the new pool on the the LSI controller. Am I overlooking anything? No, that's the way to do it. There are issues with RAID controllers and the way they store the config data. Some store it in the controller, some in some proprietary way on the disks involved. Most of the time, the config data is non-interchangeable between different manufacturers and sometime even between the same manufacturer and different models. It's a mess. -- p...@opsec.eu+49 171 3101372 5 years to go ! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: problem with geli and LSI controller
Marc UBM Bocklet wrote this message on Mon, Jul 20, 2015 at 15:29 +0200: On Mon, 20 Jul 2015 14:56:46 +0200 Marc UBM Bocklet u...@u-boot-man.de wrote: 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.. And one more question, directed at the list: even if geli manages to move the metadata via resize, the gpart metadata is probably still lost? It depends.. did you gpart it first and the geli it? or the other way around? If you gpart'd it first, you should be able to see your partitions, if you can't then getting a replacement controller card makes the most sense, as it's likely that the RAID card meta data is at the begining of the drive... gpart also supports the resize command... Replying to myself again, it appears that the safest way is to get a Rocket Raid controller identical to the one we had, put it in another system, connect the disks, import the old pool and move the data to the new pool on the the LSI controller. Am I overlooking anything? Nope... As someone else said, this is the dangers of RAID cards... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
problem with geli and LSI controller
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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: problem with geli and LSI controller
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 40960 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. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
