On Sat, 20 Jun 2026 18:01:15 +0200
Paul Leiber <[email protected]> wrote:
> Somehow, I missed to include the RAID1 information for md0 to the
> configuration file (e. g. by entering root@localhost:~# mdadm
> --detail --scan /dev/md0 >> /etc/mdadm/mdadm.conf). I am not sure if
> this actually is the cause and adding that information would solve
> the issue.
> My questions are the following:
>
> 1. Is my analysis valid in principle? Especially: Could the root
> cause for this issue be that mdadm.conf is missing the information
> for md0, and could adding that information prevent data loss or
> inconsistencies in the future?
I doubt that this is the culprit. the man page for mdadm says, in part:
Assemble
Assemble the components of a previously created array
into an active array. Components can be explicitly given or can
be searched for. mdadm checks that the components do form a
bona fide array, and can, on request, fiddle superblock
information so as to assemble a faulty array.
So mdadm *should* find both devices. But it might not be. And adding
that line will not hurt. I have a similar line in my mdadm.conf.
I built my RAID array up a bit differently that you did yours. You made
your partitions, put LUKS on the partitions, then the RAID on top of
that. I have the partitions, then the RAID array, LUKS on top of that,
then LVM, with file systems on top of the LVs. But I know of no reason
your setup shouldn't work.
I have found that when I have multiple LUKS partitions, giving them
all the same passphrase means I need give only one passphrase to
decrypt on boot.
> 2. Can I (re)create the RAID1 md0 or (re-)add the missing partition
> in an easy way that no or at least not all information is lost? If
> yes, how?
Yes. For the gory details see
https://oneuptime.com/blog/post/2026-03-02-how-to-replace-a-failed-disk-in-mdadm-raid-on-ubuntu/view.
In short,
* Fail the offending disk. It looks like this has already happened, but
it shouldn't hurt to do it again.
* Remove the disk from the array.
* Add the disk back in again. This should trigger rebuilding, which
takes a while. During the rebuild, the data should be both readable
and writable. You may monitor with:
cat /proc/mdstat
--
Does anybody read signatures any more?
https://charlescurley.com
https://charlescurley.com/blog/
