* 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
end of thread, other threads:[~2017-06-30 10:23 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-06-28 16:46 Big Endian RAID discovery problem (metadata 1!) Rolf Eike Beer
[not found] ` <AE3DE84B-9DF9-40DD-8DE2-1DD3D3CE3650@athompso.net>
2017-06-28 20:14 ` Rolf Eike Beer
2017-06-29 21:54 ` Shaohua Li
2017-06-30 10:23 ` Rolf Eike Beer
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.