raid setups fail due to mdadm.conf with explicit ARRAY statements and HOMEHOST !=any

[ceg]

Binary package hint: debian-installer

On systems that are set up statically mdadm.conf is often used to list the md devices that should be set up and the startup script just calls mdadm --assemble --scan.

But on systems oriented towards hotplug ability this prevents arrays from being assembled by the hotplug system.

Ubuntu has switched to set up complete (non-degraded) arrays automatically with udev rules. But any ARRAY line in mdadm.conf created during (package) installation prevents the hotplugging to work with other arrays.

As in general only complete (non-degraded) arrays should be run automatically, the automatic assembly will leave partial arrays that may be plugged in untouched, thus the system shoud be save even without the ARRAY restriction.

(The --no-degraded and --increamental options have been implemented with this hotplugging in mind.)

The installer should not create the ARRAY lines on udev+mdadm systems because this breaks further raid setups.

[tricky1 (tricky1)]

On Hardy all distros (including server!) do not correctly implement Raid 1 together with crypted partitions or lvm.

The whole installation process requires a well thought out strategy taking into consideration that the initramfs of a degraded system might be inappropriate and that it is not possible to create a new image before the system is up again...

With degraded arrays it all depends on the type of raid.

For raid 1 (mirroring) the user might well decide to continue booting (automatically or after manual confirmation?).

For other raid types this is high risk, but in some special cases might be necessary.

See also bug Bug 33649 pending for more than 2 years.

[ceg (ceg)]

Well, the issue filed here, is

autocreated mdadm.conf prevents autodetection of cold- and hotplugging.

I found out not only the ARRAY lines, but also the homehost prevents autotection of arrays.

The homehost feature may have been good to prevent systems with global "mdadm --assemble --scan" booting from unsyncing partly pluged in arrays and device name switchtichg in the old days.

With UUID checking in mdadm, udev and dynamic device names working, we need a way to unset the homehost, to set it to "any" or some other way so "mdadm --incremental /dev/%k" will really setup all completed arrays that are attatched when it is called from udev rules.

Something like: HOMEHOST "" in mdadm.conf or --homehost=any on the comandline.

[Martin Mai (mrkanister-deactivatedaccount-deactivatedaccount)]

 Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue for you. Can you try with the latest Ubuntu release? Thanks in advance.

[ceg (ceg)]

Two external drives containig a raid1 (storage for digicam) do not get detected and mounted when connected to another machine.

[ceg (ceg)]

Current state of ubuntu systems with md raid: https://wiki.ubuntu.com/ReliableRaid

[ceg (ceg)]

This behaviour actually not only breaks the autodetection of (complete) hot plugged md arrays from another systems, but breaks every array newly created on ubuntu systems (as ubuntu uses the hotplug scheme) .

 For instructions on updating the initramfs refer to: http://ubuntuforums.org/showthread.php?p=8407182

[ceg (ceg)]

The following will recreate a static mdadm.conf (a workaround) but is not a fix to the issue (disfunctional hotpluging):

# /usr/share/mdadm/mkconf force-generate /etc/mdadm/mdadm.conf
# update-initramfs -k all -u

[ceg (ceg)]

Well the initramfs boot process needs to be (a state machine) capable of assembling the base system from devices appearing in any order and starting necessary raids degraded if they are not complete after some time.

Bug #491463 upstart init within initramfs
Bug #251164 boot impossible due to missing initramfs failure hook integration
Bug #247153 encrypted root initialisation races/fails on hotplug devices (does not wait)

[ceg (ceg)]

Oh, no. Sorry made last comment #8 in wrong tab.