Thank you for your comments and I'm sorry me slowly commenting overlapped with your updated patches. (Of course you just worked to fast ;-), and fixed things beforehand, perfect. :)

It's good to see that happen, and I've seen the merrit of the while loop in intrepid now. It looks much better than in hardy.

Yes, lets fix things avoiding immeadiate pittfalls.
Lets think crucial things like initramfs through while we are at it. I'll try to shake the ends over here that together we'll get those bugs thoroughly out of our puppy.

>> This means of course we need to know the required array in initramfs. 

>Well, that part is doable for the root filesystem at least. It's
 ${ROOT} within the initramfs scripts.

${ROOT} may be the md device that needs to be run degraded in the corner case of a non-partitionable, non-crypted, non-lvm, md device.


>What you're talking about is going to be more complicated, and can be handled at a later time, by subsequent patches.

Yes, initramfs setup doesn't seem to be easy to me. I'd like to make much later work unneccesary.

> How about opening a separate bug for independently allowing/disallowing each array to be started in degraded mode?

It's more than that. For example the --incremental option is neccessary, because there is this nasty Bug #244792 waiting, (For that reason I have gathered all that in the BootDegradedRaid comments.)

---

I tested the changes and a crypted root does not yet come up degraded. 

The init-premount/mdadm script is responsible to set up arrays. (the local script depends on it) With udev+mdadm init-premount/mdadm doesn't have to do more then register its mountfail hook and degrade arrays if they are not available after a while, if requested. 

init-premount/mdadm needs to degrade the array before local-top/cryptroot.

I see two changes for package mdadm.
-> in init-premount/mdadm:mountroot_fail() run the array degraded imediately (implemented by ppa9). This will start degraded arrays that are made of several _crypt devices, after the rootdelay.
-> Regular degraded arrays should be run degraded directly in init-premount/mdadm, if a "while array not active" slumber loop timed out. (not yet implemented in ppa9)

Here is why:
With the second change local-top/cryptroot can find its source device.

Cryptsetup is not triggered by udev (and can not be, because non-luks partitions can not trigger events), its run by local-top/cryptroot. It doesn't make much sence to enter local-top/cryptroot with an inactive array, only to let it fail and then wait rootdelay to see that mounting the rootfs also fails and then try to recover with another rootdelay.

The rootdelay is there to wait for removable root devices. But encrypted root devices won't show up.

(Its another bug 251164, but serves the understanding:
 local-top/cryptroot  fails even with full array present when the disk has not triggerd an udev event. This is because cryptroot does not have its own checking loop, just as mdadm does not have its own checking loop yet. Only mounting root has its checking loop. Mixing one into another is not such a good idea because dependencies get lost and no while condition is adequate for all waiting involved.)

If a missing encrypted array member shows up 1 second into the rootdelay, cryptroot can't set up the root device before the failure hooks kick in, the root device won't show up for sure.
(And maybe we don't want the cryptsetup to be part of a loop with unlimited trys.)
When instad mdadm waits for the raid device to become active, local-top/cryptroot will start to set the root device up a second later and rootdelay would exit immediately.

On my testing system (8.04) local-top/cryptroot is not run at all after the array is degraded, and the root mounting fails. (cryptroot has no failure hooks) Ok, cryptsetup is a different package producing the issue at hand, but we are not yet done with package mdadm.

With manual cryptsetup and mounting of the rootfilesystem, the system still did not come up degraded. The /home raid isn't set up. Of course this part of "cannot boot raid1 with only one disk"  can be dealt with in /etc/init.d/mdadm-raid with a "while array inactive" delay loop.


---
When the confusion sets in, orchestred or not, recall.
Do stay on top. Fix the system, not the numberd bugs.
Orientation is your mastership.