Comment 6 for bug 244808

Excerpts from ceg's message of Thu Apr 28 10:01:29 UTC 2011:
> I'm sorry I won't be able to test 11.04 soon.
>
> > - A clear way we can attempt to confirm this behavior (i.e. break an
> array and then attempt to activate it?)
>
> Most of the issues should be covered by the overview in ReliableRaid and the test cases.
> https://wiki.ubuntu.com/ReliableRaid and
> http://testcases.qa.ubuntu.com/Install/AlternateRaidMirror with all three partitoning schemes.
>
> ReliableRaid says this about the bug at hand:
> Using the legacy method to start degraded raids selectively (mdadm --assemble --run -uuid) will break later --incremental (re)additions by udev/hotplugging. (The initramfs currently uses "mdadm --assemble --scan --run" and starts *all* arrays available degraded! 497186. The corresponding command "mdadm --incremental --scan --run" to start *all remaining* hotplugable raids degraded (something still to execute only manually if at all!) does not start anything. 244808)
>
> > - What you expect the system to do (assemble all inactive arrays?)
> By default, it should assemble all raid partitions that are connected with --incremental and run them only when they are complete (as defined by the state of their superblocks) to ensure no arrays are never started partially.
>
> > - What it actually does (??)
> On boot, ubuntu starts ALL arrays in degraded mode, if the rootfs is still incomplete after a timeout. It should only start the raids necessary for the rootfs in degraded mode. (how this could be done: see ReliableRaid Wiki)

Alright, I haven't seen this behavior with BOOT_DEGRADED=false. Quite
the opposite, the system stops and asks you what to do, then gives you
a chance to re-assemble the arrays. But maybe I'm missing something in
your description.

I've proposed a blueprint to suggest these fixes at UDS-O in Budapest.

https://blueprints.launchpad.net/ubuntu/+spec/server-o-software-raid

It would be helpful if you could register for uds-o as a virtual attendee
(or even better, a physical attendee!), subscribe as participation
essential (I went ahead and subscribed you but making you participation
essential just helps the scheduler if you are in fact registered),
and join us via IRC/Streaming for the discussion if the blueprint is
approved for a session at the summit.

I've linked this bug report to the blueprint. If you could link all of
the others that you feel should be grouped around this, that would be
quite helpful.