Big Endian RAID discovery problem (metadata 1!)

* Big Endian RAID discovery problem (metadata 1!)
@ 2017-06-28 16:46 Rolf Eike Beer
       [not found] ` <AE3DE84B-9DF9-40DD-8DE2-1DD3D3CE3650@athompso.net>
  0 siblings, 1 reply; 4+ messages in thread
From: Rolf Eike Beer @ 2017-06-28 16:46 UTC (permalink / raw)
  To: linux-raid

[-- Attachment #1.1: Type: text/plain, Size: 3693 bytes --]

=2D-nextPart23791692.RIh9smj9x1
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

I have an issue with a RAID1 array on my Sparc T5120. The superblocks of 3 
partitions are attached. The array was created as degraded RAID1 on sda2, then 
extended to sdb2 and sdc2, and then sda2 was removed from the array. I'm not 
entirely sure about the mdadm version used to extend the array, but it is 
likely 3.4 (current Gentoo stable).

From=20what I see the super_offset is written in big endian, which is consistent 
with the error message about super_offset being wrong when I run "mdadm -Asv". 
My luck is that the system on sda2 is still valid, so after reboot I ended up 
in an old copy of my data.

My plan is to change the GUID on sda2 and fix the super_offset on sd[bc]2, then 
reboot and hope the array(s) come up correctly.

Any thoughts on this, anything you want to test me, anything to make my life 
easier instead of poking with a hexeditor on the raw partitions?

Eike
=2D-nextPart23791692.RIh9smj9x1
Content-Disposition: attachment; filename="sda.dump"
Content-Transfer-Encoding: base64
Content-Type: application/octet-stream; name="sda.dump"

/E4rqQEAAAAAAAAAAAAAAIl7+wBEXquogtrHH1RpEEljYXN0b3I6MAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAExVo1gAAAAAAQAAAAAAAAAAUDM6AAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAQAAAAAAD1RMzoAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcv6l
b1V39rRpfuAbH/0XagAAAAAAAAAADK46WQAAAABJ1AgAAAAAAP//////////8ar9MIAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v/+//7//v/+//7//v/+//7//v/+//7//v/+
//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7/
/v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+
//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7/
/v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v8=

=2D-nextPart23791692.RIh9smj9x1
Content-Disposition: attachment; filename="sdb.dump"
Content-Transfer-Encoding: base64
Content-Type: application/octet-stream; name="sdb.dump"

/E4rqQEAAAAAAAAAAAAAAIl7+wBEXquogtrHH1RpEEljYXN0b3I6MAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAExVo1gAAAAAAQAAAAAAAAD8H2t0AAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAQAAAAAAPwfa3QAAAAAAAAAAAAAAAgAAAAAAAAAAAIAAAAAAAAATLg0
bUBbJv9cB5JOvTEzrQAACABIAAAAGj8kWQAAAACj0wgAAAAAAP//////////rTXsaoAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7//v8BAAAA/v/+//7//v/+//7//v/+//7//v/+
//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7/
/v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+
//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7/
/v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v8=

=2D-nextPart23791692.RIh9smj9x1
Content-Disposition: attachment; filename="sdc.dump"
Content-Transfer-Encoding: base64
Content-Type: application/octet-stream; name="sdc.dump"

/E4rqQEAAAAAAAAAAAAAAIl7+wBEXquogtrHH1RpEEljYXN0b3I6MAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAExVo1gAAAAAAQAAAAAAAAD8H2t0AAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAQAAAAAAPwfa3QAAAAAAAAAAAAAAAgAAAAAAAAAAAMAAAAAAAAAXNSO
ZCX2AWhlEKuNODfLrQAACABIAAAAGj8kWQAAAACj0wgAAAAAAP//////////J/vSCoAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7//v8BAAAA/v/+//7//v/+//7//v/+//7//v/+
//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7/
/v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+
//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7/
/v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v8=

=2D-nextPart23791692.RIh9smj9x1--
This is a multi-part message in MIME format.

[-- Attachment #1.2: Type: text/plain, Size: 891 bytes --]

I have an issue with a RAID1 array on my Sparc T5120. The superblocks of 3 
partitions are attached. The array was created as degraded RAID1 on sda2, then 
extended to sdb2 and sdc2, and then sda2 was removed from the array. I'm not 
entirely sure about the mdadm version used to extend the array, but it is 
likely 3.4 (current Gentoo stable).

From what I see the super_offset is written in big endian, which is consistent 
with the error message about super_offset being wrong when I run "mdadm -Asv". 
My luck is that the system on sda2 is still valid, so after reboot I ended up 
in an old copy of my data.

My plan is to change the GUID on sda2 and fix the super_offset on sd[bc]2, then 
reboot and hope the array(s) come up correctly.

Any thoughts on this, anything you want to test me, anything to make my life 
easier instead of poking with a hexeditor on the raw partitions?

Eike

[-- Attachment #1.3: sda.dump --]
[-- Type: application/octet-stream, Size: 512 bytes --]

[-- Attachment #1.4: sdb.dump --]
[-- Type: application/octet-stream, Size: 512 bytes --]

[-- Attachment #1.5: sdc.dump --]
[-- Type: application/octet-stream, Size: 512 bytes --]

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread