View previous topic :: View next topic |
Author |
Message |
theraginggeek n00b
Joined: 30 May 2022 Posts: 18
|
Posted: Sun May 12, 2024 5:33 pm Post subject: migrated raid disks to a new platform. trying to rebuild... |
|
|
Hello forum, I have a challenging situation and all my google-fu has lead me not very far. let me set the stage.
I have been running Gentoo happily on on old Phenom II Black platform for the better part of the decade with little issues, here and there a drive failure etc. most recently my SSD Root drive died which left me with the need to throw another drive into the machine, except this time I wanted to do something a bit more bold. I figured I had recently done a number of upgrades on my newer main PC, and had enough parts laying around to build a new server using a Ryzen 7 2700X and 32gigs of ram as the core instead of the Phenom II with 12Gigs of Ram. quite a performance upgrade.
So I undertook the effort of migrating all of the hardware last week, prior to shutting down the old machine for good I did take a snapshot of the /etc directory into my cold-storage drive, which is a USB HP Storage Drive about 6TB.
Last night I installed Gentoo onto the new 500Gb SSD, got it to a place where it could boot on it's own, and left it. today I updated world, installed some of my favorite tools as well as mdadm, lvm2 etc in order to support my restore of the raid. From what I recall of the raid this is the configuration as I had it:
4 1.8 TB WD Red Drives, partitioned with 1 partition per drive.
I believe I had them in pairs of raid 1, then raided together as a raid 0 to allow redundancy and striping(RAID10).
on top of this I had LVM running and split the space across 2 usable disk areas mounted to /home and a /shares mountpoint for use as a file server space.
on the new machine when I run lsblk I see:
Code: |
odin / # lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 1.8T 0 disk
sdb 8:16 0 1.8T 0 disk
sdc 8:32 0 1.8T 0 disk
sdd 8:48 0 5.5T 0 disk
`-sdd1 8:49 0 5.5T 0 part /mnt/coldstorage
sde 8:64 0 1.8T 0 disk
sdf 8:80 0 465.8G 0 disk
|-sdf1 8:81 0 1G 0 part /efi
|-sdf2 8:82 0 8G 0 part [SWAP]
`-sdf3 8:83 0 456.8G 0 part / |
which seems to indicate it can't see the partitions for the raid ready drives.
I run gdisk on them and I see:
Code: | odin / # gdisk -l /dev/sda
GPT fdisk (gdisk) version 1.0.9
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 3907029168 sectors, 1.8 TiB
Model: WDC WD20EFRX-68E
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): 295210CA-B647-C641-8E07-367401454428
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 2048, last usable sector is 3907029134
Partitions will be aligned on 2048-sector boundaries
Total free space is 3907027087 sectors (1.8 TiB)
Number Start (sector) End (sector) Size Code Name |
this is the same across all drives, so by my reckoning I imagine I have 4 disks, with GPT partitions, which I would expect if recognized would give me sda1, sdb1, sdc1 and sde1 but are not, and as such mdadm has nothing to assemble as it can't recognize the disks to reassemble to raid. is there a tool or something I can do to allow my new gentoo server to recognize these drives partitions and unlock my ability to re-raid these or am I lost and have to rebuild and restore from my backups? I hope you can help me achieve the first option as the other probably presents some data loss potential.
Thanks in advance!
Code tags added by NeddySeagoon |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54453 Location: 56N 3W
|
Posted: Sun May 12, 2024 6:23 pm Post subject: |
|
|
theraginggeek,
Check your kernel for CONFIG_EFI_PARTITION.
Without that, the partition tools will work but the kernel will not be able to read the GPT to find your raid partitions.
Code: | sdd 8:48 0 5.5T 0 disk
`-sdd1 8:49 0 5.5T 0 part /mnt/coldstorage |
... but that has to be working GPT.
It rather looks as if your partition tables were not saved after you made the partitions.
It should all work as you expect. The underlying partition is hidden from mdadm.
mdadm works with files attached to loopback devices. That's something that you only need for salvage operations though. :) _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
theraginggeek n00b
Joined: 30 May 2022 Posts: 18
|
Posted: Sun May 12, 2024 6:44 pm Post subject: |
|
|
checked my kernel config and I see:
odin /usr/src/linux # cat .config | grep EFI | grep PARTITION
CONFIG_EFI_PARTITION=y
so it looks like it should support it. the partitions were made probably over a year ago on the older machine so they should've been saved somewhere
if anyone has any additional ideas I'd appreciate it, else I might have to start building a new raid cluster tonight and see how stale my previous backups were. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54453 Location: 56N 3W
|
Posted: Sun May 12, 2024 7:11 pm Post subject: |
|
|
theraginggeek,
A partition table is a collection of pointers to the parttions.
Wiping the partition table looks scary but your data is unharmed.
Writing a GPT in place og an MSDOS table, destroys the data at the end of the volume, as the backup GPT will be written there.
Use testdisk to scan for partitions. Do not let is write any new partition table yet. Make a note of what it finds as you want to exclude false positives.
It would be best to rebuild the partition table by hand, using the testdisk output for hints.
I missed that sda was a part of your old raid set.
Are you sure you used GPT orignally?
1.8TB fits inside the MSDOS hard 2.0TiB limit. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
theraginggeek n00b
Joined: 30 May 2022 Posts: 18
|
Posted: Mon May 13, 2024 1:01 am Post subject: |
|
|
I think I made some headway with testdisk, handy tool that. scanning the drives gives me this:
Code: | /dev/sda
Linux Raid 2048 524027911 524025864 [odin:128]
Mac HFS 542409840 542498191 88352
Linux filesys. data 732787840 734747703 1959864 [Android-x86]
Mac HFS 737145704 820359959 83214256
Linux filesys. data 847184574 863956365 16771792 [Android-x86]
/dev/sdb
Linux RAID 0 32 33 32619 58 23 524025864 [odin:128]
/dev/sdc
Linux RAID 0 32 33 32619 58 23 524025864 [odin:1]
Linux 32447 227 37 162924 75 31 2096103424
Linux RAID 163177 153 49 215377 211 10 838596616 [odin:5]
/dev/sde
Linux 0 32 33 32635 139 16 524288000
Linux 32447 227 37 162924 75 31 2096103424
Linux RAID 163177 153 49 215377 211 10 838596616 [odin:5] |
which makes sense I believe /dev/sde and /dev/sdc were paired with the last partitions and then those were striped to the sda and sdb partitions which would be replicated pairs.
I'm guessing the next step would be to use fdisk to mirror the start and stop points based on the above and then start mdadm scans to see if it can rebuild?
Thanks for the help.
Code tags added to preserve formatting -- Neddyseagoon |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54453 Location: 56N 3W
|
Posted: Mon May 13, 2024 8:48 am Post subject: |
|
|
theraginggeek,
The next step is to make images of those drives, so that you have an undo function. Unless you have validated backups already
See my signature :)
It looks like
Code: | /dev/sda
Linux Raid 2048 524027911 524025864 [odin:128]
/dev/sdb
Linux RAID 0 32 33 32619 58 23 524025864 [odin:128] | as they both have 524025864 blocks.
If you have a backup, or want to proceed at risk, the next step is to read
When you understand the following, try it
Code: | losetup -f -o 1024K /dev/sda
mdadm -E /dev/loop0 |
This is supposed to set up a loopback device starting at 1024kiB from the start of sda, then, assuming that the loopback device --found is loop0, read and display the raid metadata from the raid element that we think starts there.
Post the output,
Code: | Linux Raid 2048 524027911 524025864 |
The numbers are start, end and size ... in sectors.
That's 524025864 512b sectors. Does that look right?
I would have expected another drive to match that. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|