Hi Daniel,
{ Convention on all kernel.org lists is to avoid top-posting and to trim
unnecessary quoted material. Please do so going forward. }
On 3/30/20 8:51 PM, Daniel Jones wrote:
Greetings Wol,
Don't even THINK of --create until the experts have chimed in !!!
Unfortunately, your new motherboard or your distro appears to have
reacted to the presence of whole-disk raid members by establishing Gnu
Partition Tables on them, blowing away those drives' superblocks.
Personally, I like the idea of whole-disk raid members, and did so for a
while, until reports like yours made me change my ways. Sorry.
You absolutely will need to use --create in this situation. Much of the
data necessary is available from the one remaining superblock, which you
nicely included in your original report.
Since a --create will be needed, I recommend adjusting offsets to work
with new partitions on each drive that start at a 1MB offset.
Yes, I have had impure thoughts, but fortunately (?) I've done nothing
yet to intentionally write to the drives.
Thank you. This makes it much easier to help you.
[trim /]
The lsdrv information is crucial - that recovers pretty much all the config information that is available
Attached.
$ ./lsdrv
PCI [pata_marvell] 02:00.0 IDE interface: Marvell Technology Group
Ltd. 88SE6101/6102 single-port PATA133 interface (rev b2)
└scsi 0:x:x:x [Empty]
PCI [ahci] 00:1f.2 SATA controller: Intel Corporation 82801JI (ICH10
Family) SATA AHCI Controller
├scsi 2:0:0:0 ATA M4-CT256M4SSD2 {0000000012050904283E}
│└sda 238.47g [8:0] Partitioned (dos)
│ ├sda1 500.00m [8:1] xfs {8ed274ce-4cf6-4804-88f8-0213c002a716}
│ │└Mounted as /dev/sda1 @ /boot
│ └sda2 237.99g [8:2] PV LVM2_member 237.92g used, 64.00m free
{kn8lMS-0Cy8-xpsR-QRTk-CTRG-Eh1J-lmtfws}
│ └VG centos_hulk 237.98g 64.00m free {P5MVrD-UMGG-0IO9-zFNq-8zd2-lycX-oYqe5L}
│ ├dm-2 185.92g [253:2] LV home xfs {39075ece-de0a-4ace-b291-cc22aff5a4b2}
│ │└Mounted as /dev/mapper/centos_hulk-home @ /home
│ ├dm-0 50.00g [253:0] LV root xfs {68ffae87-7b51-4392-b3b8-59a7aa13ea68}
│ │└Mounted as /dev/mapper/centos_hulk-root @ /
│ └dm-1 2.00g [253:1] LV swap swap {f2da9893-93f0-42a1-ba86-5f3b3a72cc9b}
├scsi 3:0:0:0 ATA WDC WD100EMAZ-00 {1DGVH01Z}
│└sdb 9.10t [8:16] Partitioned (gpt)
├scsi 4:0:0:0 ATA WDC WD100EMAZ-00 {2YJ2XMPD}
│└sdc 9.10t [8:32] MD raid5 (4) inactive 'hulk:0'
{423d9a8e-636a-5f08-56ec-bd90282e478b}
├scsi 5:0:0:0 ATA WDC WD100EMAZ-00 {2YJDR8LD}
│└sdd 9.10t [8:48] Partitioned (gpt)
└scsi 6:0:0:0 ATA WDC WD100EMAZ-00 {JEHRKH2Z}
└sde 9.10t [8:64] Partitioned (gpt)
No shocks here. But due to the incomplete array, useful details are
missing. In particular, knowledge of the filesystem or nested structure
(LVM?) present on the array will be needed to identify the real data
offsets of the three mangled members. (lsdrv is really intended to
document critical details of a healthy system to minimize this kind of
uncertainty when it eventually breaks.)
Please tell us what you can. If it was another LVM volume group, please
look for backups of the LVM metadata, typically in /etc/lvm/backup/.
Or we can make educated guesses until read-only access presents working
or near-working content.
Cheers,
DJ
Regards,
Phil
