You are not logged in.
I'm a beginner with RAID and I'm testing RAID1 on qemu-kvm, attaching two raw disk images which contain the arrays. In the arch wiki [1] it says
Note: Every time when you make changes to /etc/mdadm.conf, the initramfs needs to be regenerated.
However, during my installation I didn't update /etc/mdadm.conf with
mdadm --detail --scan >> /mnt/etc/mdadm.conf
but it still seems to work. I verified after booting the guest images and logging in that /etc/mdadm.conf is still untouched. The only thing I did was insert the mkinitcpio hook
HOOKS=(base udev autodetect keyboard modconf block mdadm_udev filesystems fsck)
I use systemd-boot, is this relevant? Since everything seems to work, does this mean that modifying /etc/mdadm.conf is not necessary at all? Like *never*?
I don't understand how the early boot system assembles the arrays, but I noticed that on my host system (no arrays listed in /etc/mdadm.conf either, just like in the guest vm), the mdadm "system" automatically detects when I attach one of the raw qemu images to a loop device (losetup --find --partscan), and waits for the second image to be attached to automatically configure the arrays. Does the early boot system do it like this, without needing a /etc/mdadm.conf?
[1] https://wiki.archlinux.org/title/RAID#C … mkinitcpio
Last edited by stri (2022-09-09 15:49:11)
Offline
With no mdadm.conf present, it falls back to auto detection. So yes it can work fine without... but I'd still use a mdadm.conf as it can help make sure the md devices always have the same name. also normally you'd want mdadm to send you notifications on raid failure.
mdadm also has udev rules to auto assemble arrays as they appear in the system, probably responsible for your qemu image. An mdadm.conf which does not define these arrays should also help prevent auto-assembly of these unwanted arrays. (You can still assemble them manually if need be)
Offline
I see, thanks for the clarification!
Offline