On 27/10/2021 17:33, Wol wrote:
On 26/10/2021 10:45, John Atkins wrote:
Thanks for the suggestions.
No partition ever on these disks.
BAD IDEA ... it *should* be okay, but there are too many rogue
programs/utilities out there that think stomping all over a
partition-free disk is acceptable behaviour ...
It's bad enough when a GPT or MBR gets trashed, which sadly is not
unusual in your scenario, but without partitions you're inviting
disaster... :-(
Ah confirmation from what I read in a 2017 post *sigh*, naivete on my
part thinking that with out partitions there was less to go wrong.
I will try the dd method but as there was never a partition on the
drive I don't think that will return results.
Why not? it may return traces of the array ...
Thought this was to look for partition headers, I was assuming wrong
again. I will try this.
The busy drive is not part of an active md array nor mounted so still
a bit bemused by that.
When mdadm attempts to start an array (which it does by default at
boot), if the attempt fails it usually leaves a broken inactive array
in an unusable state. You need to "kill" this mess before you can do
anything with it!
Ah ha that explains that. I will kill what I can find.
I know the order, after my first few muckups I number them to make
sure if I have to move them it will work. If I use assume clean, if
it does not work I can just try another order I assume. I do have a
backup but 14T will take time to replicate.
If you haven't yet tried to force the array, and possibly corrupted
where the headers should be, you could try a plain force-assemble,
which *might* work (very long shot ...)
I will try giving this ago, I was under the assumption as there is only
one drive with a super block it would not, I will check the Wiki again
to explore this and how to specify the drives.
Otherwise, read the wiki and try with overlays until something
"strikes gold". Then I'd be inclined to fail each drive in turn,
re-adding it as a partition, to try and avoid a similar screw-up in
future.
Yes from now on it is partitions not raw drives haha.
That, or disconnect all the raid drives before an upgrade, and
re-connect them afterwards - though that's been known to cause grief,
too :-(
I was just a machine reboot not even upgrades so bit lost on what caused
the OS to scramble its self and prevent the OS from booting.
(Of course, if you've used all available space, partitioning will
shrink the raid and cause more grief elsewhere ...)
Luckily not yet
Hopefully, you've never resized the array, and the mdadm defaults
haven't changed, so you'll strike gold first attempt. Otherwise it
could be a long hard slog with all the possible options.
https://raid.wiki.kernel.org/index.php/Linux_Raid
Cheers,
Wol
.
Thank you very much for the advice!
John
