No worries about the reply
We honestly prefer to be explicit in our solution that to rely on what mdadm puts together automatically because it does not know what to do…
Can you elaborate on this? Regardless of whether the array is assembled automatically by the kernel, or using mdadm to manually scan for arrays, the metadata is read from the members of the array in order to assemble it. It’s the same process,
mdadm.conf simply allows for keeping a record of the desired arrays, and overriding defaults, which is to automatically assemble available arrays from the on-disk metadata.
Can Balena add a label that allows to import that mdadm.conf into the containers to be written and have a single file for this?
It may be possible to bind mount this configuration to an overlay, which could allow user applications to configure arrays on boot, but this remains to be tested. I suspect, after reviewing the merge that added this feature for all balenaOS devices, that modifying this config on the host OS will not have any effect, as mdadm isn’t being used to assemble arrays there. Rather, the kernel is finding and assembling them at boot without any help from userspace. However, this can also be done inside a container by stopping and reassembling an array with your configuration, as you’re doing now. Is there a reason this approach is currently deficient?
Can Balena add a way of disabling mdadm in the HostOS via a Device Configuration variable like the firewall or delta updates one?
I’m not 100% on this one, but I believe mdadm is currently unused in the host OS, as it’s simply a userspace utility for managing and monitoring software RAID devices, and the existing functionality is all kernel side. Even if we removed it, arrays would still be assembled on boot, as
CONFIG_MD_AUTODETECT is enabled. This was also enabled in v2.58.6, as seen below.
root@balena:~# cat /etc/os-release
root@balena:~# uname -a
Linux balena 5.2.10-yocto-standard #1 SMP Fri Oct 23 09:05:55 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
root@balena:~# zcat /proc/config.gz | grep _MD
# CONFIG_SCTP_DEFAULT_COOKIE_HMAC_MD5 is not set
This explains why this array was assembled in this previous OS release as well. The above referenced merge simply enables this for all kernels and device types, even if their kernel was previously configured to have this not enabled. For the generic x86_64 image, this PR has no effect, as these configs were already enabled, and mdadm is unused. As far as mdadm goes, the presence of this utility simply allows for managing and monitoring arrays directly from the host OS shell, though this could also be done from a container, using, e.g.:
balena run --privileged alpine /bin/sh -c "apk add --update mdadm && mdadm ..."
The change from assembling the array at
/dev/md127 was likely the result of an upstream kernel change, and is not unexpected, as these device names are not static. The upstream recommended way of finding the appropriate device is to use the partition or filesystem label or UUID.
Let me know what you think, and if this helps clarify anything.