On Sat, Dec 18, 2021 at 11:31:39PM -0500, Tony Bush wrote: > I forgot that this new-to-this-system SSD had Windows 10 OS on > it and I believe it tried to boot while I was working on hooking up my > monitor. So I think that it saw my raid drives and tried to fdisk > them. I did mdadm directly to drive and not to a partition(big > mistake I know now). So I think the drives were seen as corrupted and > fdisk corrected the formatting. Windows is known to do this but it can just as well happen within Linux. Hopefully no filesystem formatting took place... > To fix, I have been leaning toward making the drives ready only and > using an overlay file. Like here: > https://raid.wiki.kernel.org/index.php/Recovering_a_failed_software_RAID#Making_the_harddisks_read-only_using_an_overlay_file This method is so useful there should be standard command in Linux to create and manage overlays; but there is none so you have to make do with the 'overlay manipulation functions' as shown in the wiki. > But i dont understand all the commands well enough to work this for my > situation. Seems like since I don't know the original drive > arrangement that may be adding an additional level of complexity. If > I can figure out the read only and overlay, I still don't know exactly > the right way to proceed on the mdadm front. Please anyone who has a > handle on a situation like this, let me know what I should do. Thanks I summarized `mdadm --create` for data recovery here: https://unix.stackexchange.com/a/131927/30851 In addition you should remove the bogus GPT and MBR partition headers. You can use 'wipefs' for this task. (Test it with overlays first...) wipefs --all --types pmbr,gpt,dos /dev/... You are lucky to have all the relevant `mdadm --examine` output, so you already know the correct data offset and only need to guess the correct order of drives. Regards Andreas Klauer
